Skip to content

Sandboxes

The compute ledger behind runtimes, evaluations, and worlds — where compute state, billing, and provider identity live.

Every time the platform reserves compute, it creates or updates a sandbox record. Interactive runtimes, evaluation environments, evaluation agent loops, Worlds backends — they all write to the same ledger. The sandbox tells you what ran, for how long, under which provider, and what it cost.

Higher-level surfaces decide why the compute exists; sandboxes just record that it exists.

KindPurpose
runtimeBacks an interactive runtime or an evaluation agent loop.
taskRuns task-style compute: evaluation environments, training, and optimization jobs.
worldRuns a Worlds backend for manifest and trajectory generation.
StateMeaning
runningThe provider instance is active and consuming credits.
pausedThe provider instance is suspended; credits stop accruing.
killedThe provider instance has been terminated. Final state.

A sandbox transitions to killed when you delete it explicitly or when it times out. Records persist after termination — the row stays for audit and billing.

When a sandbox is paused, the record carries a pause_reason:

ReasonCause
userSomeone paused the runtime or sandbox explicitly.
timeoutThe sandbox hit its expiry window and was auto-paused.
insufficient_creditsThe org’s credit balance reached zero; running sandboxes were auto-paused.
member_limit_exceededWorkspace membership limit was hit and compute was auto-paused.

Credit accrual is settled from the sandbox record.

FieldMeaning
billed_creditsCredits already deducted, persisted on the sandbox row.
running_creditsDerived from runtime duration since the last deduction.
estimated_total_creditsbilled_credits + running_credits — the projected total cost.

Deduction is atomic — the platform updates the balance and row in a single SQL operation, so concurrent agents can’t overdraw.

ProviderWhere it runsNotes
e2bSaaS and stagingPrimary hosted provider with custom sandbox templates.
dockerLocal / self-hostedUses the local Docker daemon.
opensandboxSelf-hostedDreadnode’s open sandbox runtime for self-hosted clusters.

Two IDs are worth keeping straight:

  • the Dreadnode sandbox UUID on runtime and evaluation records
  • the provider sandbox ID used for logs and provider-level operations

dn sandbox commands take the provider sandbox ID.

An interactive runtime points at one sandbox at a time. Starting a runtime provisions one; resetting terminates and unlinks it. The sandbox record survives termination — the runtime stays, the compute is gone.

For the interactive control surface, start from the runtime. Use the sandbox ledger when the question is “what compute existed, and what did it cost?”