sandboxesL3 runtime

A microVM per task, next to the model.

Each sandbox is a Firecracker microVM restored from a snapshot of its template. Run commands, stream output, read and write files, open a terminal and share a port. Code inside a sandbox reaches every B3OS product at 127.0.0.1:7700 with no network hop, and only with the scopes you grant it.

API
/v1/sandboxes
CLI
b3os sandbox create · b3os sandbox exec · b3os sandbox shell
MCP tools
sandbox_*

[01/03] What it does

Templates

base (Ubuntu 24.04, Python 3.12, Node 24, git), code-interpreter (a Jupyter kernel behind run_code) and agent (Claude Agent SDK, OpenAI Agents SDK and LangGraph installed).

GET /v1/sandboxes/templates

Exec

Buffered, streamed as server-sent events, or in the background with logs you can follow.

POST /v1/sandboxes/{id}/exec

Files and a terminal

Read and write files by path, list directories, and attach a terminal over WebSocket.

/files · /pty

Port previews

Expose a port at usercontent.b3os.org/sbx/…. Ports are private by default and shared through expiring, signed URLs.

POST /v1/sandboxes/{id}/ports/{port}/url

Pause, resume, snapshot

Pause an idle sandbox instead of stopping it, and start new sandboxes from a snapshot of a running one.

/pause · /resume · /snapshot

Scoped API access

The api grant decides what code in the sandbox may call. It never exceeds the scopes or spend cap of the key that created the sandbox, and it ends with the sandbox.

api: {scopes, spend_cap_usd}

What happens before your first exec
  1. Template

    base, code-interpreter or agent, booted once and snapshotted.

  2. Warm slot

    Restored, warmed with one exec, paused and parked before anyone asks.

  3. Claim

    Fresh entropy and identity are bound to your sandbox, then it resumes.

  4. Exec

    Commands run through the guest agent's pre-forked process over vsock.

SBX=$(curl -sS https://beta-api.b3os.org/v1/sandboxes \
  -H "Authorization: Bearer $B3OS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"template":"base","timeout_s":900}' | jq -r .id)

curl -sS https://beta-api.b3os.org/v1/sandboxes/$SBX/exec \
  -H "Authorization: Bearer $B3OS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"cmd":["python3","-c","print(2 + 2)"]}'
  • Guests have no network interface. Outbound traffic goes through the egress guard over vsock: public internet only by default, with deny and allowlist modes.
  • Each restore gets fresh entropy, a new machine id and a reseeded PRNG before it runs.

[02/03] Measured

What we measure for sandboxes

Values appear here only from published benchmark runs, each with its raw data. A row that says measuring has no published run yet.

Claim to first exec

Create a sandbox and run its first command, end to end on the same host, at idle. Pool depth stated.

Measuringp50, client side

Claim to first exec, 100 at once

The same under a burst of 100 simultaneous claims.

Measuringp50, client side

Exec round trip

Run /bin/true in a running sandbox: b3osd to the guest agent, process spawn, exit status back.

Measuringp50, server side

Pause and resume

Each of pause and resume on a running sandbox.

Measuringp50, server side

Fork

One fork of a sandbox with up to 128 MiB of RAM and 64 MiB dirty. Larger sizes are published as a curve.

Measuringp50, server side

Time to interactive, ComputeSDK harness

Create a sandbox and run node -v, measured by ComputeSDK's own harness from their runners: the shape other sandbox providers are measured in.

Measuringp50, client side
How we measure, and what others publish

[03/03] Beta limits

Free during the beta, with caps

Caps per organization

Sandboxes running at once
10
vCPUs per sandbox
2 vCPU
Memory per sandbox
2 GiB
Sandbox lifetime
1 h

Metered units

Sandbox CPU
sandboxes.vcpu_ms
Sandbox memory
sandboxes.gib_ms
Pricing details