Runtimes in Chat
What the runtime cluster in the Chat header tells you, what each state costs, how to start, pause and reset, and where capabilities live.
The top-right of the thread is the compute and billing model, in two controls:
3 capabilities │ ● Running · 4m used ▾The left half opens the capability picker. The right half opens the runtime menu and says, in words, whether anything is costing you money right now.
What the states mean
Section titled “What the states mean”| The header reads | On hover | The sandbox | Costing you |
|---|---|---|---|
Checking | Checking runtime | Being looked up, on page load | Unchanged by the check |
No runtime | No runtime | None, and no runtime record in this project | Nothing |
Idle | Runtime idle | None; the record is there | Nothing |
Starting | Runtime starting | Coming up | From the moment it comes up |
Running | Runtime running | Up | Yes, continuously |
Paused | Runtime paused | Suspended | No |
Disconnected | Runtime disconnected | Up, but this browser holds no credential for it | Yes, it is still running |
Error | Runtime error | Unknown | Check the menu |
No runtime is the one state that keeps the noun: it is the only one describing something that is not there, so it names what is missing.
disconnected is the ordinary state after a reload, and it recovers on its own. It does not mean the sandbox stopped.
checking is what a page load shows for the moment it takes to resolve which runtime you hold.
The session list carries the settled half of this vocabulary (running, paused, idle, no runtime) on every row, so you can see which projects are warm before clicking into one. The transient states belong to the project you are already in.
Starting, pausing, resetting
Section titled “Starting, pausing, resetting”The runtime menu carries three actions and the figures behind them: time used and estimated credits, refreshed when you open it.
| Action | Effect |
|---|---|
| Start runtime | Provisions a sandbox. The label says what the click will actually do: Resume for a paused runtime, Reconnect for a disconnected one, Restart for one in an error state. |
| Pause runtime | Suspends the sandbox and stops the meter. The state inside it survives. |
| Reset runtime | Terminates the sandbox and returns the runtime to idle. Discards everything inside it. |
Cold starts
Section titled “Cold starts”A project whose runtime is idle has no sandbox, so the first message provisions one. That takes about 25 seconds, and the pane shows the wait: your message, what is being provisioned, and how long it has been. The message sends by itself when the runtime is ready.
Chat never provisions compute on its own. Loading a page attaches to a sandbox that is already running; if the platform finds that sandbox is gone, the runtime lands idle and waits for you rather than quietly starting a replacement.
Capabilities
Section titled “Capabilities”The left half of the cluster is the capability picker: what is installed on this runtime, what is available to install, and the install action itself. Installing puts a capability’s agents, tools, and skills into the running sandbox, where they show up in the agent picker and the / palette from the next turn on.
The runtime has to be running to manage capabilities. There is nowhere to install them otherwise, and the picker says so.
Capabilities are per runtime, so a capability installed in one project is not present in another. See Capabilities for what they contain and how to author one.
Where the rest of the model lives
Section titled “Where the rest of the model lives”Runtimes are workspace resources with their own lifecycle, ownership rules, and CLI. Runtimes covers the runtime-versus-sandbox split, and Managing runtimes covers dn runtime and the TUI’s runtime screen.
One rule worth knowing here: a runtime belongs to whoever created it. You can see a colleague’s runtimes in the CLI, but you cannot start, pause, or reset one, and Chat only ever attaches to your own.