Runtimes in Chat

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

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

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.

Reset discards the sandbox

Reset throws away the sandbox and whatever is in it: installed state, files the agent wrote, anything not persisted to the platform. Your sessions survive, because sessions are platform records. Reach for pause when you want the meter stopped and the state kept.

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

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.

If a capability is installed but its agent is missing, open the capability picker. Installed capabilities come first, with load status and available agent counts; search covers installed and available capabilities. Select an installed capability to inspect its health.

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.

Runtime health

Open Health beside the runtime controls to investigate a missing agent or failing tool. The header keeps a count of capabilities needing attention; Running describes the runtime itself and does not imply every capability is ready.

The inspector leads with capability load failures, then groups component diagnostics under each capability. Expand component issues for the reported cause and recovery guidance. Components still starting are neutral progress; idle workers and components disabled by flags do not count as issues. Unresolved issues remain discoverable until a later status read confirms recovery.

Chat reads health immediately when the runtime connects and every five seconds while it stays connected, even when the inspector is closed. These reads use the runtime snapshot and do not rerun health checks or reload the capability catalog. Automatic reads are silent: unchanged snapshots leave controls in place, and component updates preserve your agent selection and expanded diagnostics. The inspector shows when the runtime was last checked. If a read fails, Chat labels the retained information as the last known state. Pausing, resuming, or reconnecting preserves that snapshot and your selected agent; stopping the runtime or switching runtimes clears them.

Refresh status reads current health. Reconnect, Authenticate, and Restart worker act on the relevant component when supported. After fixing a load failure’s cause, use Reload capabilities to retry loading; refreshing alone does not repair missing dependencies or filesystem permissions. Copy diagnostics copies the runtime capability snapshot with its check time for investigation.

An installed capability records the saved installation, even if the runtime has not loaded its agents. If an install or removal is saved but its reload fails, Chat reports those outcomes separately.

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.