Skip to content

Runtimes

Workspace-scoped resources that hold sessions, capability bindings, and project grouping across ephemeral sandbox compute.

A runtime is the durable thing you work with. The sandbox behind it is disposable.

When you open a session, install capabilities, and pick an agent, those choices live on the runtime. The compute underneath can be started, paused, resumed, or replaced — your sessions and bindings come back every time.

  • the runtime is the thing you control
  • the sandbox is the thing you pay for
  • the session is the thing you resume

If those were one object, every reset would discard conversation history and every compute failure would look like lost project state. Splitting them keeps the three lifecycles independent.

A runtime points at zero or one sandbox at a time. Sandbox provisioning is lazy — starting a runtime is what actually reserves compute.

Runtime statusSandboxMeaning
idlenoneNo compute is reserved. The runtime is clean or reset.
runningactiveA sandbox is provisioned and executing.
pausedsuspendedThe sandbox is paused. Credits stop accruing.
ActionEffectNeeds a sandbox?
startProvisions a sandbox. Injects any secrets declared in the runtime’s configuration.No
pauseSuspends the current sandbox. Credits stop.Yes
resumeRestores the paused sandbox.Yes
resetTerminates the sandbox and returns the runtime to idle.Yes
keepaliveExtends the sandbox expiry to prevent automatic timeout.Yes

start on a running runtime is still meaningful: if the durable configuration has changed since the sandbox was created, the old sandbox is replaced with a fresh one that matches.

See Managing runtimes for the workflows, and Configuration for what persists across sandbox replacement.

Capabilities you install on a runtime survive the full sandbox lifecycle. Pause, resume, reset, or reprovision — the bindings are there again when the next sandbox starts.

See Capabilities for how to author a bundle.