Runtime
Shared defaults for a skill set.
Runtime
Runtime is the working setup behind a skill set.
It keeps shared defaults for language, location, speech, blocked skills, and skill health.
Most users do not need runtime on day one. Start with the default. Change runtime only when one hub needs different behavior.
Use Runtime When
Section titled “Use Runtime When”- the wrong language appears;
- the wrong location or time zone affects a hub;
- a wrong timezone value appears in a client response;
- the wrong voice appears;
- a skill is unexpectedly blocked;
- a runtime or skill update is waiting.
At a Glance
Section titled “At a Glance”| Question | Simple answer |
|---|---|
| What is runtime? | Shared working settings behind a skill set. |
| What does it affect? | Hubs that use that skill set. |
| What settings live there? | Language, location, speech, blocked skills, live skill status, and update state. |
| How do I add capacity? | Standard hubs use a shared skill runtime. Plan-enabled Autoscaling hubs use their own workers; choose capacity on the hub. |
| Should I change it first? | Usually no. Start with the default. |
| Where do I change it? | Runtime config for the selected skill set. |
Runtime Is Not a Hub
Section titled “Runtime Is Not a Hub”Skill set
The collection of skills a hub can use.
Hub
The place clients connect to.
Client
The app, device, or agent that connects.
What Runtime Controls
Section titled “What Runtime Controls”Runtime settings choose behavior, not the number of workers. A Standard hub uses the shared worker for its skill set. An Autoscaling hub uses its own workers and the ceiling shown in Billing. Changing a legacy runtime replica setting does not enable autoscaling.
Runtime controls:
- primary language;
- secondary languages;
- location and time zone;
- speech-to-text and text-to-speech defaults;
- blocked skills;
- skill and runtime update state.
Default vs Separate Setup
Section titled “Default vs Separate Setup”Most workspaces start with workspace default skills. This keeps many hubs on the same simple setup.
Use a separate skill set when one hub needs different skills, different runtime settings, or a slower update pace.
| Choice | Best when | What to remember |
|---|---|---|
| Workspace default | Most hubs should behave the same way. | Changing it can affect every hub using it. |
| Separate skill set | One hub needs different skills or settings. | Changes stay limited to hubs assigned to that skill set. |
When to Open Runtime Config
Section titled “When to Open Runtime Config”Open runtime config when you need to:
- change the main language for a hub group;
- add secondary languages for a multilingual audience;
- set the location used by skills;
- choose speech-to-text or text-to-speech defaults;
- block a skill from loading in that skill set;
- understand why a runtime refresh is needed.
Runtime Is Ready When
Section titled “Runtime Is Ready When”Each skill set currently runs one effective runtime worker. This avoids inconsistent pod-local skill, intent-cache, and messagebus state. If an older configuration requests more than one worker, Thalovant continues with one and reports the requested and effective counts in runtime status.
Runtime is ready when:
- the selected skill set is the one used by the intended hub;
- shared defaults match the audience and location;
- secondary languages do not duplicate the primary language;
- blocked skills match the safety goal;
- live skill status has no unexpected warning;
- Dashboard and Live Map return to the expected state after any restart.