Hubs

A hub is your assistant: the thing your phone, your speakers and your apps talk to. Ask it for the weather from the kitchen, set a timer from the couch, check the news from your phone, and it is the same assistant answering every time. One hub, every room.

A hub isn’t the same thing as a client. The hub is the assistant. A client is one of the things that talk to it: a phone, a speaker, an app. Access rules decide what each client can do after it connects.

Use this page when a hub is missing, unavailable, not visible, or hard to recognize in Dashboard, Clients, Access rules, or Topology.

For owned hub creation, use Create a Hub. For shared discovery, use Public Hubs. For hub update questions, use Manage Updates. For connection issues, move next to Clients or Topology.

What A Hub Is

A hub is what a client connects to. Your workspace creates hubs when the plan allows owned ones; Billing shows the limit. A hub runs a skill set with runtime defaults. Standard capacity is fixed, and Autoscaling, where the plan includes it, adds whole workers under load. Clients connect to it, and narrow access rules per client are what keep it safe.

The Hubs page is the fleet view: one card per hub with its state, its tags, a starter prompt and its clients.

What a Hub Owns

Name

The friendly label you use to recognize the hub.

Address

The hub address clients use when they connect.

Public or private

Private hubs stay inside the workspace. Public hubs appear in discovery.

Skills

The abilities available to the hub.

Runtime

The shared working setup behind the hub’s skill set.

What Depends on a Hub

Many other items point back to a hub:

• Clients connect to one hub.
• Access rules are set for a client on a hub.
• Skills define what the hub can do.
• Runtime defines shared settings for the hub’s skill set.
• Dashboard shows hub status and attention items.
• Topology shows hubs and their clients.

Because hubs sit in the middle, choose the hub before creating clients and access rules.

Private and Public Hubs

PrivatePublicCertifiedCommunity

Private hubs are for your workspace. Use them when the hub should only be available inside your account area.

Public hubs are for discovery. They can publish a description, tags, audience guidance, age guidance, quality label, and starter prompts. Public hubs are useful for demos, shared experiences, and Free-path exploration.

An active public hub can also offer browser preview. Changing a private hub to public starts a normal hub refresh while the preview becomes ready. The hub does not report ready preview access until that refresh finishes. Changing it back to private removes preview access and its dedicated credentials.

If preview configuration is unavailable, the hub reports attention instead of silently publishing a broken preview. Private, inactive, missing, or invalid visibility never enables public preview.

When you use a public hub, you don’t manage that hub’s runtime. You create your own client for the public hub and keep access rules narrow.

When you create your own hub, you choose whether it uses the workspace default skill set or a separate skill set. Runtime config belongs to the skill set, not the client.

Hub, Skills, and Runtime

Clients connect to a hub. What the hub can do is its skills; the shared defaults those skills run with are its runtime; which clients may use it is decided by access rules. Four words, four pages, and this one is about the first.

Standard and Autoscaling Capacity

Capacity controls how the hub runs; it doesn’t change the hub address or its client identities.

• Standard is the default fixed-capacity profile and uses the runtime owned by the selected skill set.
• Autoscaling keeps two workers ready and can add capacity up to the ceiling shown in Billing.
• Autoscaling answers through installed skills. Persona and general LLM replies aren’t available in this profile.
• An Autoscaling hub reserves a plan slot even while inactive. Changing it back to Standard releases that slot.

Team includes one Autoscaling hub with a maximum of eight workers. Enterprise capacity is contract-defined, with a platform maximum of 32 workers per hub. Existing hubs remain Standard unless an authorized workspace member explicitly changes the capacity profile.

Hub Health

Hub cards and inspectors show:

• current state, such as ready, pending, failed, or unknown;
• live status when available;
• connected and known clients;
• warnings;
• recent activity;
• available hub updates;
• extra status details when the hub has them.
• separate preview readiness for public hubs.
• the saved capacity profile and autoscaling worker ceiling when applicable.

Tip

A hub can exist before every live update is available. Use the status badge and detail panel together: one tells you the current state, the other explains what changed or what is missing.

Hub Updates

Hub updates upgrade connections and browser previews to the selected version. The Hubs page can show Hub update available, Update requested, or a ready state after sync finishes.

If the hub says the backing runtime needs attention, update or fix the runtime first. Then return to the hub update.

Use Update a skill, a runtime, or a hub when you need to decide which of the three you actually want to change.

Public Discovery Details

When you publish a hub publicly, make the listing useful:

• write a short description in plain language;
• add lowercase tags like assistant, education, or support;
• choose the audience category;
• add an age guidance value if needed;
• publish starter prompts users can copy or try.

Good public hub listings make it obvious what the hub is for before anyone creates a client.

When to Create a Separate Hub

Create another hub when you need a different public/private setting, different skills, a different address, or a separate group of clients and access rules. Keep one hub when the same setup still makes sense.

Hub Is Ready When

A hub is ready for a first client when:

• the name explains the hub purpose;
• the public or private setting is correct;
• the skill set choice is intentional;
• the address is visible when needed;
• any expected hub update is complete;
• the hub status has no unexpected warning;
• you know which client should connect next.