DEV Community: JerryLin

Cube Sandbox v0.3.0: A Time Machine and a Cloning Booth for Your AI Agents

JerryLin — Mon, 08 Jun 2026 16:07:28 +0000

In modern AI Agent stacks, the sandbox plays the role of a "secure runtime" — it is what actually executes the code and tool calls produced by the model. Cube Sandbox just shipped v0.3.0. Beyond the 82 commits from 22 contributors, this release is a foundational architecture upgrade targeted squarely at the pain points AI Agents hit at scale: runtime reuse and fault isolation under high concurrency, long task chains, and reinforcement-learning workloads.

1. Foundations: a more complete AI Infra story

Before diving into the headline snapshot work, here is what changed at the foundation. v0.3.0 iterates on three axes:

Engine internals (cubecow + incremental memory): a new copy-on-write (CoW) snapshot engine — cubecow — purpose-built for sandbox volumes; on the memory side, an incremental memory snapshot built on the Linux kernel's soft-dirty bitmap. In back-to-back snapshot scenarios, the system no longer has to flush full memory; it only persists the dirty pages produced since the last snapshot. As a result, both snapshot creation and restoration drop into the millisecond range per sandbox.
Developer ecosystem (Go SDK + WebUI): following the Python SDK, Go developers now get a native SDK that fully covers the sandbox and template lifecycle. For ops and management workflows, a built-in web console is now live, surfacing per-node resource load and per-sandbox runtime state at a glance.
Deploy & ops: the one-click installer has migrated to systemd + Docker Compose, with built-in pre-flight and diagnostic scripts (cgroup v2, etc.) that significantly improve out-of-the-box compatibility across cloud providers.

Among these foundational updates, the one that deserves the most attention is the snapshot / rollback / clone system around the sandbox's core state.

2. Snapshot / Clone / Rollback: a time machine for your Agent

This release introduces three SDK primitives — snapshot, clone, and rollback — that together form a complete state-management story for sandboxes.

2.1 What each primitive does

snapshot — freeze the current state

Dump the running sandbox's memory, runtime state, and disk to persistent storage as a standalone snapshot file. The snapshot's lifecycle is decoupled from the source sandbox: the snapshot survives the source's destruction, and the snapshot ID can itself act as a template for spinning up new sandboxes in bulk.

clone — fan one sandbox out into N

A single call derives N fully independent replicas from a running source sandbox. The key properties:

Inheritance: each replica starts from a state identical to the source — memory, files, connections.
Isolation: replicas are physically isolated from each other.
Continuity: the source sandbox is unaffected and keeps running.

The interface ships with a concurrency=C knob and an "abort-and-clean-up on any failure" policy, so large fan-outs never leave orphan sandboxes behind.

rollback — go back to a moment in one line

A sandbox can be restored in place to a previous snapshot's state — both memory and filesystem fully reverted. After rollback, the sandbox_id and the sandbox object stay the same; no reconnection or reconstruction needed.

2.2 Why Agents really need these

In a classic web service, a container is largely stateless: spin up, serve, throw away. AI Agents do not work that way — they are cultivated. Two recurring pain points fall out of that:

First: how do you replicate a sandbox you have already "trained up"?

When you need to run more tasks in parallel, or onboard a new teammate, replaying the setup script from scratch is both slow and unable to faithfully reproduce in-memory context, loaded model weights, or warm caches. With snapshot + clone, "thirty minutes × N" becomes "milliseconds × N", and every replica is a fully primed Agent environment.

Second: what happens when the environment gets wrecked?

Agents make mistakes — wrong dependencies, deleted files, infinite loops. The traditional answer is "kill the container, rebuild from the image, re-run pip install" — a few minutes lost. rollback collapses recovery from minutes to a few hundred milliseconds, with the same sandbox_id, so the Agent simply keeps going.

2.3 Four real-world scenarios these primitives unlock

1) Agentic RL training / SWE-Bench evaluation

Pain: you need a large number of independent runs from the same baseline, and every experiment must be reproducible.
Cube approach:

  # Prepare the baseline environment
  base = Sandbox.create(template=TEMPLATE_ID)
  base.run_code("# Install deps, download dataset ...")
  snap = base.create_snapshot()

  # Fan out 100 independent instances in parallel
  clones = Sandbox.create(template=snap.snapshot_id).clone(n=100, concurrency=10)

Value: the baseline is built once; every subsequent expansion is a millisecond-grade clone.

2) Parallel multi-strategy exploration

Pain: you want to try several solution paths against the same problem at the same time.
Cube approach: use clone(n=N) to fork the current state into N isolated sandboxes, run each strategy independently, then aggregate.
Value: linear scaling of exploration throughput, with strict experimental parity across runs.

3) Agent trial-and-retry loops

Pain: when one step fails mid-execution, the classic remedy is to kill the sandbox and start over.
Cube approach:

  checkpoint = sb.create_snapshot()
  sb.run_code("# Try approach A ...")
  if failed:
      sb.rollback(checkpoint.snapshot_id)   # Back to the moment before A
      sb.run_code("# Retry with a different approach ...")

Value: no environment rebuild — saves time and resources, and maps naturally onto the Agent's trial-and-error pattern.

4) Long-lived environment reuse

Pain: you have configured a complex dev environment (lots of dependencies) and don't want to set it up again every time.
Cube approach: take a snapshot once; create every future sandbox from that snapshot.
Value: cold start + environment init collapse into a single step.

3. How snapshots actually work under the hood

In traditional virtualization, snapshots are a heavy ops operation. Cube Sandbox's snapshot system uses reflink end-to-end at the storage layer, paired with copy-on-write (CoW) semantics, to deliver efficient snapshot creation and cloning.

Storage model: while a sandbox is running, its disk data is mounted in CoW mode, and its memory is similarly mmap'd from the snapshot file in CoW mode. Once a sandbox boots, all read-only memory pages map directly to the underlying snapshot file — multiple sandbox instances share one physical copy of the data with no duplication.
Taking a snapshot: when a new snapshot is taken for a running sandbox, the system writes only the dirty pages produced since the last snapshot into a new snapshot file — no full serialization, no full write-out. Since dirty pages are typically an order of magnitude smaller than total memory, snapshot I/O cost drops dramatically and end-to-end latency falls.
Booting from a snapshot: when creating a new sandbox from an existing snapshot, reflink lets the new instance reference the snapshot's metadata blocks directly — a true "logical copy" with no full data duplication. Filesystem-level reflink is roughly O(1), which makes cold-starting a sandbox from a snapshot extremely fast.

On top of this storage primitive, the SDK wraps clone and rollback as simple, single-line operations:

4. In practice: using snapshot and rollback

Scenario 1: error isolation and in-place rollback

Drop a checkpoint at any meaningful moment in the sandbox's lifecycle. No matter how badly the environment is later mangled, a single sb.rollback(checkpoint_id) restores it to that moment — and crucially, the sandbox_id and the sandbox object stay the same, so you can keep using them:

from cubesandbox import Sandbox
from env import TEMPLATE_ID

# Step 1: take a base snapshot in the v0 state
with Sandbox.create(template=TEMPLATE_ID) as src:
    src.run_code("open('/tmp/v.txt', 'w').write('v0')")
    base = src.create_snapshot()
    base_id = base.snapshot_id
    print(f"base snapshot (v0): {base_id}")

# Step 2: spin up a new sandbox from the base snapshot
sb = Sandbox.create(template=base_id)
print(f"derived sandbox: {sb.sandbox_id}")

# Step 3: write v1 and drop a checkpoint
sb.run_code("open('/tmp/v.txt', 'w').write('v1')")
checkpoint = sb.create_snapshot()
checkpoint_id = checkpoint.snapshot_id
print(f"checkpoint (v1): {checkpoint_id}")

# Step 4: write v2 and confirm it landed
sb.run_code("open('/tmp/v.txt', 'w').write('v2')")
before = sb.run_code("print(open('/tmp/v.txt').read())").logs.stdout
before = before[0].strip() if before else ""
print(f"before rollback: {before!r}")
assert before == "v2"

# Step 5: roll back to the v1 checkpoint
sb.rollback(checkpoint_id)
print(f"rolled back to checkpoint {checkpoint_id}")

# Step 6: verify state is restored to v1 (sandbox_id unchanged)
after = sb.run_code("print(open('/tmp/v.txt').read())").logs.stdout
after = after[0].strip() if after else ""
print(f"after rollback: {after!r}")
assert after == "v1", f"expected 'v1', got {after!r}"
print("OK: rollback restored state to checkpoint (v1)")

# Cleanup
sb.kill()
Sandbox.delete_snapshot(checkpoint_id)
Sandbox.delete_snapshot(base_id)
print("snapshots deleted")

Scenario 2: parallel exploration via efficient cloning

In reinforcement learning or multi-path decision making, clone can derive many environments from a single source sandbox in one call — each replica is physically isolated yet inherits the source's full runtime state. The example below clones N replicas and then verifies each one inherited a marker file written into the source:

import os
from cubesandbox import Sandbox
from env import TEMPLATE_ID

N = int(os.environ.get("FORK_N", "10"))
CONCURRENCY = int(os.environ.get("FORK_CONCURRENCY", "5"))

src = Sandbox.create(template=TEMPLATE_ID)
src.run_code("open('/tmp/origin.txt', 'w').write('I am from sandbox a')")
print(f"src sandbox: {src.sandbox_id}")

# ★ Concurrent clone — the SDK fan-outs Sandbox.create internally
clones = src.clone(n=N, concurrency=CONCURRENCY)
print(f"cloned {len(clones)} sandboxes (concurrency={CONCURRENCY})")

# Verify every clone inherited the source's state marker
expect = "I am from sandbox a"
ok = 0
for i, sb in enumerate(clones):
    r = sb.run_code("print(open('/tmp/origin.txt').read())")
    marker = r.logs.stdout[0].strip() if r.logs.stdout else ""
    if marker == expect:
        ok += 1
    print(f"  clone[{i:>2}] {sb.sandbox_id} marker={marker!r}")

print(f"\n{ok}/{N} clones inherited the origin marker")
assert ok == N, "some clones failed to inherit state"

# Cleanup
src.kill()
for sb in clones:
    sb.kill()
print("all sandboxes killed")

Cube Sandbox is deeply E2B-compatible at the protocol level, but these two primitives do not exist in E2B's native API. The Cube team bridges them at the application layer through the cubesandbox SDK — meaning developers can unlock these advanced state-management primitives without touching their existing E2B-compatible code.

5. A web console for snapshot / clone / rollback (preview), open-sourced alongside

In addition to the SDK-level snapshot / rollback / clone API, this release ships an open-source preview of a Cube-Sandbox-powered OpenClaw web console. Everything new in this release is now point-and-click: a real-time snapshot timeline per sandbox, one-click rollback to any checkpoint, on-demand fan-out to multiple OpenClaw replicas, and bulk lifecycle management.

What used to require scripting against the SDK — the "time machine" and the "cloning booth" — is now a few clicks in the browser.

Coming soon

In the next release we will push "sandbox security" one layer further — from "isolating where the Agent runs" to "controlling what the Agent can touch":

Built-in content-aware network control and audit: content-aware egress access control plus full audit trails at the sandbox network boundary, so "which external API the Agent called and what data it sent out" is fully traceable and interceptable.
Credential vault: API keys, database passwords, and cloud credentials managed centrally on the sandbox security side; the Agent only ever sees scoped, ephemeral credentials, keeping secrets out of the model context and out of logs.

If you are building anything in this space, follow Cube Sandbox — and consider opening an issue or PR to build with us.

GitHub repo: https://github.com/TencentCloud/CubeSandbox
Full release notes: https://github.com/TencentCloud/CubeSandbox/releases/tag/v0.3.0
Snapshot technical docs: https://github.com/TencentCloud/CubeSandbox/blob/master/docs/guide/snapshot-rollback-clone.md

CubeSandbox Core Operations Performance Benchmark Report (PVM Cloud Server)

JerryLin — Mon, 08 Jun 2026 15:59:19 +0000

1. Overview

CubeSandbox is designed for AI Agent code execution, where ultra-fast cold-start and high concurrency are the two most critical metrics. This post presents performance benchmark data measured on a Tencent Cloud standard CVM (running a PVM kernel), split into two parts:

Chapter 3: Create sandbox from Template — cold-start latency, concurrency scaling, single-host deployment density
Chapter 4: Snapshot operations — Snapshot creation, create-from-snapshot, Rollback, Clone

Every section includes the exact commands needed to reproduce the results on your own hardware.

Important: all benchmark numbers are highly dependent on the test environment and workload. Contributing factors include (but are not limited to) host CPU, memory, IO performance, and sandbox internal workload (e.g. the more complex the program running inside the sandbox and the more dirty pages generated, the longer snapshot creation takes). Please evaluate against your own hardware and workload when planning deployments.

Compared to the bare-metal benchmark report, this post uses a standard virtualized CVM (SA9.4XLARGE32) with fewer CPU cores and less memory, and can serve as a reference baseline for small-to-medium scale deployments.

2. Test Environment

2.1 Hardware

Item	Detail
Machine	Tencent Cloud Standard CVM SA9.4XLARGE32 (available for purchase from the Tencent Cloud console)
Availability Zone	—
OS	OpenCloudOS 9.4
Kernel	`6.6.69-cube.pvm.host.005.x`
CPU Model	AMD EPYC 9K65
CPU Config	1 Socket × 16 Core × 1 Thread = 16 logical cores
NUMA Nodes	1 (node0: 0-15)
Total Memory	32 GiB
System Disk	`/dev/vda` 200 GiB Enhanced SSD cloud disk, formatted as XFS, mounted at `/`

SA9.4XLARGE32 is a Tencent Cloud ninth-generation standard instance powered by AMD EPYC 9K65 processors, suited for general-purpose computing. This post runs a PVM (Parallel Virtual Machine) kernel that supports nested virtualization, enabling CubeSandbox to run on an ordinary cloud server. To reproduce the tests in this post, visit the Tencent Cloud CVM purchase page to select the same model.

To install CubeSandbox, refer to the Quick Start Guide.

2.2 Sandbox Spec and Template Creation

All tests use sandboxes with the following spec:

Item	Detail
Spec	2 vCPU / 2 GiB memory
Test Image	`cube-sandbox-cn.tencentcloudcr.com/cube-sandbox/sandbox-code:latest`
Storage	CoW reflink (XFS, `/data/cubelet/storage/`)
Memory Tracking	soft-dirty (`/proc/PID/clear_refs`)

Build the template before running any tests (use cn registry in China, int elsewhere):

cubemastercli tpl create-from-image \
  --image cube-sandbox-cn.tencentcloudcr.com/cube-sandbox/sandbox-code:latest \
  --writable-layer-size 1G \
  --expose-port 49999 \
  --expose-port 49983 \
  --probe 49999

After the build finishes, note the template ID:

# List templates and grab the first tpl- prefixed ID
cubemastercli tpl list

2.3 Metric Definitions

Metric	Meaning
avg	Mean across all rounds
min	Minimum observed
p95	95th percentile (95% of requests complete within this time)
max	Maximum observed
wall	End-to-end elapsed time for the entire batch (first request sent → last one done); used in concurrency scenarios
per	Amortized per-operation time (wall ÷ number of operations in the batch); used in concurrency scenarios

All times are in milliseconds (ms). A warm-up round is run before each scenario (results discarded) to eliminate page-cache cold-read noise. Concurrent test rounds run serially — no cross-round concurrency — to avoid mutual interference.

3. Create Sandbox from Template

This chapter measures the end-to-end time to start a ready-to-use sandbox — calling POST /sandboxes (with template_id) until the sandbox reaches running. This is the most common usage pattern.

3.1 Setup and Verification

Step 1: Install the Python SDK and set environment variables

pip install e2b-code-interpreter

export CUBE_API_URL=http://<your-server-ip>:3000
export E2B_API_KEY=e2b_000000           # any non-empty string for local deploys
export CUBE_TEMPLATE_ID=<your-template-id>  # from cubemastercli tpl list
export SSL_CERT_FILE=/root/.local/share/mkcert/rootCA.pem  # mkcert certificate path

Step 2: Run a Hello World to verify the environment

Before running any benchmarks, run the following script to confirm sandboxes can be created and execute code:

import os
from e2b_code_interpreter import Sandbox

with Sandbox.create(template=os.environ["CUBE_TEMPLATE_ID"]) as sandbox:
    result = sandbox.run_code("print('Hello from Cube Sandbox, safely isolated!')")
    print(result)
    print("✅ Environment verification passed — ready for benchmarking")

Save as hello.py and run:

python hello.py

If you see ✅ Environment verification passed, CubeSandbox is deployed correctly and you can proceed. If it errors, refer to the Quick Start to troubleshoot.

3.2 Cold-Start Latency and Concurrency Scaling

Use the cube-bench tool to measure sandbox creation latency at different concurrency levels. cube-bench drives CubeAPI via Go goroutines and reports full percentile statistics.

Build (requires Go 1.21+):

cd examples/cube-bench
make
# output: ./bin/cube-bench

Run:

# Set environment variables
export E2B_API_URL=http://<your-server-ip>:3000
export E2B_API_KEY=e2b_000000
export CUBE_TEMPLATE_ID=<your-template-id>

# 1-concurrent, 20 total (create then immediately delete)
./bin/cube-bench -c 1 -n 20 -w 3

# 10-concurrent, 200 total
./bin/cube-bench -c 10 -n 200 -w 3

# 20-concurrent, 300 total
./bin/cube-bench -c 20 -n 300 -w 3

-w 3 runs 3 warm-up rounds whose results are discarded before measurement.

Results (Tencent Cloud SA9.4XLARGE32 PVM, 2 vCPU / 2 GiB sandbox):

Concurrency	Requests	avg	min	P50	P90	P95	P99	max
1	20	66.7 ms	55.9 ms	64.5 ms	77.5 ms	78.2 ms	80.2 ms	80.2 ms
10	200	170.9 ms	85.4 ms	168.5 ms	206.4 ms	216.7 ms	286.1 ms	323.5 ms
20	300	364.6 ms	116.5 ms	356.2 ms	459.0 ms	521.4 ms	673.8 ms	744.0 ms

Each tier is tested independently — all sandboxes are cleaned up and the resource pool is given time to recover between tiers to avoid interference. 100% success rate across all tiers.

Key findings:

Serial creation latency ~67 ms (min 55.9 / P95 78.2), extremely low and stable
At 10-concurrent, avg 171 ms — amortized per-sandbox just 17.1 ms, showing strong concurrency scaling
At 20-concurrent, avg 365 ms — amortized per-sandbox 18.2 ms, P99 674 ms reflects minor tail latency under queue pressure

3.3 Single-Host Deployment Density (Memory Overhead)

CubeSandbox uses kernel sharing and Copy-on-Write (CoW) to compress its per-instance overhead to extremely low levels. This section measures net per-instance cost by "clearing the machine → launching sandboxes in batches → recording memory changes."

⚠️⚠️⚠️ Important Safety Warning

Before each batch, always run free -h to confirm sufficient remaining memory. Launch only a small batch at a time, observe memory after each batch, and only proceed when safe — never launch too many at once! Running out of memory triggers OOM Killer, which at minimum kills processes and at worst corrupts the running environment, requiring redeployment. Decide batch sizes based on your machine's actual available memory.

Step 1: Record the baseline (empty machine memory)

export E2B_API_URL=http://<your-server-ip>:3000
export E2B_API_KEY=e2b_000000
export CUBE_TEMPLATE_ID=<your-template-id>

# Ensure no leftover sandboxes
cubemastercli list

# Record empty-machine memory usage
free -h
# Also record shim process count (should be 0)
ps --no-headers -C containerd-shim-cube-rs | wc -l

Step 2: Launch sandboxes in batches, record memory with free -h after each batch

Use cube-bench in create-only mode to create sandboxes and keep them alive:

# Set environment variables (same as §3.2; re-export if you open a new terminal)
export E2B_API_URL=http://<your-server-ip>:3000
export E2B_API_KEY=e2b_000000              # any non-empty string for local deploys
export CUBE_TEMPLATE_ID=<your-template-id> # from cubemastercli tpl list

./bin/cube-bench -c 1  -n 1  -m create-only && free -m   # cumulative: 1
./bin/cube-bench -c 4  -n 4  -m create-only && free -m   # cumulative: 5
./bin/cube-bench -c 5  -n 5  -m create-only && free -m   # cumulative: 10
./bin/cube-bench -c 10 -n 10 -m create-only && free -m   # cumulative: 20

Step 3: Calculate per-instance overhead

Per-VM amortized overhead = (current used - baseline used) ÷ VM count

Results (Tencent Cloud SA9.4XLARGE32 PVM, 2 vCPU / 2 GiB sandbox):

Live Sandboxes	System Available (MB)	Per-VM Amortized Overhead
0 (baseline)	25570 MB	—
1	25536 MB	~34 MB
5	25436 MB	~27 MB
10	25252 MB	~32 MB
20	24990 MB	~29 MB

Measured per-VM amortized overhead is approximately 27–34 MB. CoW on-demand allocation is clearly effective — a 2 GiB sandbox at idle uses only ~30 MB in practice.

Estimated single-host capacity (SA9.4XLARGE32, 32 GiB memory):

Total memory:                     32768 MB
System baseline usage (measured): 7198 MB  (= 32768 - 25570, from empty-machine available)
Safety headroom reserved (10%):   3276 MB
Available for sandboxes:         22294 MB  (= 32768 - 7198 - 3276)

Idle/light-load scenario (CoW on-demand allocation, ~30 MB amortized per sandbox):
  22294 ÷ 30 ≈ 743 sandboxes

Full-load scenario (each sandbox writes the full 2 GiB):
  22294 ÷ (2048 + 30) ≈ 10 sandboxes

4. Snapshot Operations

Snapshot is a core CubeSandbox feature, supporting memory + filesystem snapshots on running sandboxes that can be restored near-instantly (Clone / Rollback).

Install dependencies:

cd examples/snapshot-rollback-clone
pip install -r requirements.txt   # installs the cubesandbox SDK

# The following environment variables are prerequisites for all 4.x benchmark scripts;
# export in each new shell (or write to env.sh and source it)
export E2B_API_URL=http://<your-server-ip>:3000
export CUBE_API_URL=http://<your-server-ip>:3000   # same as E2B_API_URL
export E2B_API_KEY=e2b_000000                       # any non-empty string for local deploys
export CUBE_TEMPLATE_ID=<your-template-id>          # from cubemastercli tpl list

Sections 4.1–4.5 below assume you have completed the above export in your current shell (scripts read these variables via env.py). Re-export if you open a new terminal.

4.1 Snapshot Creation vs Concurrency

How it works: calls POST /sandboxes/{id}/snapshots on a running sandbox. N concurrent requests target N independent sandboxes simultaneously, measuring wall time until all snapshots complete.

CubeSandbox serializes snapshot requests on a single sandbox internally, so the concurrency test targets N distinct sandboxes (one snapshot request per sandbox), and the actual success count equals the concurrency.

Run: (script: bench_snapshot_concurrency.py)

cd examples/snapshot-rollback-clone
export E2B_API_URL=http://<your-server-ip>:3000
export E2B_API_KEY=e2b_000000
export CUBE_TEMPLATE_ID=<your-template-id>

python bench_snapshot_concurrency.py -c 1  -n 5
python bench_snapshot_concurrency.py -c 5  -n 5 --no-header
python bench_snapshot_concurrency.py -c 10 -n 5 --no-header

Results (fresh sandboxes snapshotted as-is; measured dirty pages ~8 MB, confirmed by PagemapAnon snapshot saved in /data/log/CubeVmm/vmm.log; this is the sandbox baseline anonymous memory page size and is not a variable in this section):

Concurrency	Rounds	wall avg	wall min	wall p95	wall max	per-snapshot avg
1	5	41.4 ms	37.6 ms	48.7 ms	48.7 ms	41.4 ms
5	5	58.2 ms	51.0 ms	66.1 ms	66.1 ms	11.6 ms
10	5	114.1 ms	66.2 ms	285.2 ms	285.2 ms	11.4 ms

Serial snapshot ~41 ms; at 5-concurrent, batch wall ~58 ms, per-snapshot amortized drops to ~11.6 ms; at 10-concurrent, batch wall ~114 ms, amortized further drops to ~11.4 ms — significant concurrency amortization.

4.2 Snapshot Creation vs Dirty Page Size

Background: CubeSandbox uses the soft-dirty mechanism to save only memory pages modified since the last snapshot. Actual write volume = dirty page count × 4 KiB, typically far less than total sandbox memory (2 GiB).

The test precisely controls dirty page size by pre-writing data to /dev/shm (tmpfs). The "Dirty Page" column shows actual bytes written as read from /data/log/CubeVmm/vmm.log — it differs from the theoretical write size due to Guest OS background activity.

Run: (script: bench_snapshot_dirty.py)

cd examples/snapshot-rollback-clone
export E2B_API_URL=http://<your-server-ip>:3000
export E2B_API_KEY=e2b_000000
export CUBE_TEMPLATE_ID=<your-template-id>

python bench_snapshot_dirty.py -d 0    -n 3
python bench_snapshot_dirty.py -d 10   -n 3 --no-header
python bench_snapshot_dirty.py -d 50   -n 3 --no-header
python bench_snapshot_dirty.py -d 100  -n 3 --no-header
python bench_snapshot_dirty.py -d 200  -n 3 --no-header
python bench_snapshot_dirty.py -d 500  -n 3 --no-header
python bench_snapshot_dirty.py -d 800  -n 3 --no-header
python bench_snapshot_dirty.py -d 1024 -n 3 --no-header

Tests run in serial mode; one warm-up is discarded before each data point, then 3 measured runs are averaged. The "create sandbox avg" column shows the time to create a new sandbox from that snapshot, reflecting whether dirty page size affects restore speed.

Results:

Write Size	Dirty Page	snapshot avg	snapshot min	snapshot p95	snapshot max	create sandbox avg	create sandbox min	create sandbox p95	create sandbox max
0 MB	8.3 MB	42.1 ms	37.6 ms	45.9 ms	45.9 ms	71.6 ms	65.4 ms	77.7 ms	77.7 ms
10 MB	41.2 MB	55.3 ms	54.1 ms	56.6 ms	56.6 ms	73.1 ms	60.4 ms	82.5 ms	82.5 ms
50 MB	122.6 MB	67.7 ms	66.5 ms	69.6 ms	69.6 ms	70.3 ms	63.9 ms	81.4 ms	81.4 ms
100 MB	195.2 MB	85.7 ms	82.5 ms	88.7 ms	88.7 ms	68.3 ms	62.3 ms	71.6 ms	71.6 ms
200 MB	296.8 MB	100.9 ms	98.5 ms	102.6 ms	102.6 ms	65.9 ms	62.7 ms	71.2 ms	71.2 ms
500 MB	602.6 MB	168.6 ms	165.4 ms	172.9 ms	172.9 ms	68.1 ms	54.5 ms	75.7 ms	75.7 ms
800 MB	908.3 MB	215.8 ms	212.1 ms	217.6 ms	217.6 ms	68.1 ms	60.9 ms	79.1 ms	79.1 ms
1024 MB	1136.3 MB	257.5 ms	251.2 ms	267.6 ms	267.6 ms	62.3 ms	56.5 ms	69.6 ms	69.6 ms

Key findings:

Snapshot creation time scales near-linearly with dirty page size: baseline (8.3 MB dirty) ~42 ms, +~22 ms per 100 MB of additional dirty data, ~258 ms at 1024 MB
Create-from-snapshot time is independent of dirty page size: stable at 54–83 ms regardless of snapshot size, because restore uses CoW (copy-on-write) on-demand loading and does not depend on dirty page size

4.3 Create Sandbox from Snapshot

How it works: creates a snapshot first, then launches N sandboxes concurrently via POST /sandboxes (with snapshot_id), measuring end-to-end wall time until all sandboxes reach running.

Run: (script: bench_create_concurrency.py)

cd examples/snapshot-rollback-clone
export E2B_API_URL=http://<your-server-ip>:3000
export E2B_API_KEY=e2b_000000
export CUBE_TEMPLATE_ID=<your-template-id>

python bench_create_concurrency.py -c 1  -n 3
python bench_create_concurrency.py -c 10 -n 3 --no-header
python bench_create_concurrency.py -c 20 -n 3 --no-header

Results:

Concurrency	n total	Rounds	wall avg	wall min	wall p95	wall max	per-sandbox avg
1	1	3	66.7 ms	65.8 ms	68.3 ms	68.3 ms	66.7 ms
10	10	3	387.9 ms	364.4 ms	420.3 ms	420.3 ms	38.8 ms
20	20	3	701.3 ms	660.5 ms	742.4 ms	742.4 ms	35.1 ms

Single sandbox startup ~67 ms; at 10-concurrent, wall ~388 ms, amortized just 38.8 ms/sandbox; at 20-concurrent, wall ~701 ms, amortized just 35.1 ms/sandbox — demonstrating good concurrency scaling.

4.4 Rollback

How it works: calls POST /sandboxes/{id}/rollback on running sandboxes to restore memory and filesystem state in-place to the specified Snapshot, without recreating the sandbox.

Snapshot ownership constraint: CubeSandbox only allows a sandbox to roll back to a checkpoint it created itself. Therefore each concurrent sandbox must independently complete the full "snapshot + rollback" flow.

Run: (script: bench_rollback_concurrency.py)

cd examples/snapshot-rollback-clone
export E2B_API_URL=http://<your-server-ip>:3000
export E2B_API_KEY=e2b_000000
export CUBE_TEMPLATE_ID=<your-template-id>

python bench_rollback_concurrency.py -c 1  -n 5
python bench_rollback_concurrency.py -c 5  -n 5 --no-header
python bench_rollback_concurrency.py -c 10 -n 5 --no-header

Results:

Concurrency	Rounds	wall avg	wall min	wall p95	wall max	per-rollback avg
1	5	90.0 ms	82.0 ms	98.3 ms	98.3 ms	90.0 ms
5	5	325.5 ms	322.9 ms	329.4 ms	329.4 ms	65.1 ms
10	5	821.4 ms	778.7 ms	858.1 ms	858.1 ms	82.1 ms

Single Rollback flow ~90 ms; at 5-concurrent, batch wall ~326 ms, per-rollback amortized drops to ~65 ms; at 10-concurrent, batch wall ~821 ms, amortized ~82 ms/rollback.

Note: Because CubeSandbox requires sandboxes to roll back only to their own checkpoints, shared snapshots cannot be reused — each concurrent sandbox must independently complete the full "snapshot + rollback" flow.

4.5 Clone

How it works: calls POST /sandboxes/{id}/clone to fork N new sandboxes from a running source sandbox, fully preserving the source's memory and filesystem state (including dirty pages).

Note: disk files in this test were already in Page Cache; results exclude cold-read IO overhead.

Run: (script: bench_clone_concurrency.py)

cd examples/snapshot-rollback-clone
export E2B_API_URL=http://<your-server-ip>:3000
export E2B_API_KEY=e2b_000000
export CUBE_TEMPLATE_ID=<your-template-id>

python bench_clone_concurrency.py -n 1  -c 1  --rounds 5
python bench_clone_concurrency.py -n 10 -c 5  --rounds 3 --no-header
python bench_clone_concurrency.py -n 20 -c 10 --rounds 3 --no-header

Results (source sandbox dirty pages ~10 MB):

Scenario	n	Concurrency	Rounds	wall avg	wall min	wall p95	wall max	per-clone avg
1 sandbox, 1-concurrent	1	1	5	270.6 ms	260.8 ms	280.5 ms	280.5 ms	270.6 ms
10 sandboxes, 5-concurrent	10	5	3	541.6 ms	522.9 ms	557.7 ms	557.7 ms	54.2 ms
20 sandboxes, 10-concurrent	20	10	3	789.7 ms	757.2 ms	815.3 ms	815.3 ms	39.5 ms

Single sandbox clone ~271 ms; 10 sandboxes at 5-concurrent, batch wall ~542 ms, per-clone amortized drops to ~54 ms; 20 sandboxes at 10-concurrent, batch wall ~790 ms, amortized further drops to ~40 ms/sandbox — significant concurrency amortization.

4.6 Pause / Resume

How it works: Creates concurrency sandboxes, pauses all of them concurrently via POST /sandboxes/{id}/pause, then resumes all concurrently via POST /sandboxes/{id}/resume. Records wall time and per-sandbox amortized latency for both operations.

⚠️ Current implementation note: Pause currently uses full-memory-copy mode — on pause, all anonymous memory pages of the sandbox are written to persistent storage. Latency scales linearly with sandbox memory size (~371 ms per sandbox at 2 GiB on PVM). A future release will upgrade to soft-dirty incremental mode, which only saves pages dirtied since the last checkpoint. For an idle sandbox this is expected to reduce pause latency by 80–90% — significantly.

Run: (script: bench_pause_resume_concurrency.py)

cd examples/snapshot-rollback-clone
export E2B_API_URL=http://<your-server-ip>:3000
export E2B_API_KEY=e2b_000000
export CUBE_TEMPLATE_ID=<your-template-id>

python bench_pause_resume_concurrency.py -c 1  -n 5
python bench_pause_resume_concurrency.py -c 10 -n 5 --no-header

Pause results:

Concurrency	Rounds	wall avg	wall min	wall p95	wall max	per-pause avg
1	5	370.8 ms	351.0 ms	384.0 ms	384.0 ms	370.8 ms
10	5	1586.0 ms	1529.5 ms	1679.8 ms	1679.8 ms	158.6 ms

Resume results:

Concurrency	Rounds	wall avg	wall min	wall p95	wall max	per-resume avg
1	5	18.9 ms	9.5 ms	32.8 ms	32.8 ms	18.9 ms
10	5	26.6 ms	19.3 ms	39.9 ms	39.9 ms	2.7 ms

Key findings:

Resume is extremely fast with excellent concurrency scaling: single resume ~19 ms; at 10-concurrent, per-resume amortized just 2.7 ms/sandbox
Pause is the current bottleneck: in full-copy mode, single pause ~371 ms, 10-concurrent per-pause amortized 158.6 ms/sandbox
After soft-dirty mode lands: pause latency is expected to drop significantly, with 10-concurrent per-pause falling into single-digit milliseconds

full-copy → soft-dirty optimization: The current full-copy mode writes up to 2 GiB of VM anonymous memory to disk on every pause, creating high IO pressure. The soft-dirty incremental mode tracks dirty pages via /proc/PID/clear_refs since the last checkpoint; pause only writes actually modified pages (typically a few MB for an idle sandbox), reducing pause latency by 80–90% and significantly increasing high-concurrency throughput.

Appendix: Benchmark Script Index

All benchmark scripts used in this post are located in the repository directories:

examples/cube-bench/ — Template-based concurrent creation benchmark tool (Go)
examples/snapshot-rollback-clone/ — Snapshot / Rollback / Clone / Pause-Resume Python scripts

Cube Sandbox is Now Open Source: Why We Built a Fast and Secure Sandbox for AI Agents？

JerryLin — Thu, 30 Apr 2026 19:26:15 +0000

With the rapid advancement of LLM capabilities, AI Agent applications are experiencing explosive growth. Recently, Anthropic unveiled its latest Managed Agent architecture, which completely decouples Agents into three core components: Session, Harness, and Sandbox. This confirms a key industry consensus: the best practice for supporting complex tool calls and code execution in Agents is to isolate them in a fully independent sandbox environment.

However, as the critical component in the Agent architecture that carries code execution, a Sandbox must simultaneously meet two extremely demanding requirements: impenetrable security isolation and extreme concurrent elasticity for "spin up and tear down on demand".

Existing infrastructure faces a severe trade-off:

Containers: Fast startup, high concurrency, but the shared kernel mechanism cannot defend against malicious code escapes generated by LLMs, resulting in extremely poor multi-tenant security.
Traditional Virtual Machines: Hardware-level isolation is secure enough, but heavy OS overhead leads to minute-level cold starts and hundreds of MB memory usage, making them completely unsuitable for the transient, high-density scheduling demands of Agents.

To break this boundary between performance and security, we have built a high-performance open-source secure sandbox service from scratch based on RustVMM and KVM — Cube Sandbox. Today, the project is fully open-sourced on GitHub:

GitHub - TencentCloud/CubeSandbox: Instant, Concurrent, Secure & Lightweight Sandbox for AI Agents.

What is CubeSandbox?

Cube Sandbox is a high-performance, out-of-the-box secure sandbox service built on RustVMM and KVM. It supports both single-machine deployment and easy scaling to multi-machine cluster services. It is also the industry’s first open-source sandbox service that combines hardware-level isolation with sub-100ms startup.

Instead of wrapping Docker with an extra layer, we developed Cube Sandbox based on CloudHypervisor. Through a series of innovations and tests, we have outperformed traditional industry solutions in multiple dimensions. A brief comparison is shown below:

Metric	Data	What it means
Cold Start	<60ms	2.5–50x faster than traditional solutions, faster than a blink of an eye
Memory per Instance	<5MB	6x lower overhead than traditional solutions
Isolation Level	KVM Hardware-level	Each sandbox has an independent Guest OS kernel, not sharing the host kernel
Concurrency Capacity	2000+ per machine	P95 remains within 137ms for 50 concurrent creations
E2B Compatibility	Native support	No business code changes required; just change one environment variable; OpenAI Python SDK also works seamlessly
Deployment Scenarios	Single-machine & Cluster	Can be experienced on a single machine as a personal Agent assistant, or easily scaled into a high-concurrency cluster service

Technical Principles: How to Achieve Speed, Lightweight, and Security?

Cube Sandbox follows a clear top-down layered architecture, divided into control plane and data plane. The core components are as follows:

CubeAPI: E2B-compatible REST API gateway. Switching from E2B Cloud to Cube Sandbox only requires changing environment variables such as URL.
CubeMaster: Orchestration scheduler that receives E2B API requests and distributes them to corresponding Cubelets, responsible for resource scheduling and cluster state maintenance.
CubeProxy: Reverse proxy and request routing component that forwards requests from SDK clients to corresponding sandbox instances by parsing the <port>-<sandbox_id>.<domain> format in the Host header.
Cubelet: Local scheduling component on compute nodes that manages the full lifecycle of all sandbox instances on a single node.
CubeVS: Kernel-level forwarding based on eBPF, providing complete network isolation mechanisms and security policy support at the network layer.
CubeHypervisor & CubeShim: Virtualization layer of Cube Sandbox. CubeHypervisor manages KVM MicroVMs, and CubeShim implements the containerd Shim v2 interface to integrate sandboxes into the container runtime.

Cube Sandbox Layered Architecture Diagram

Here are some core technical points in our self-developed Cube Sandbox:

1) Self-developed Lightweight VMM (CubeVM)

This is the core of the entire project. Instead of directly using Firecracker (AWS open-source MicroVM), we implemented a VMM from scratch in Rust, optimized specifically for AI Agent scenarios.

Why build our own? Because Firecracker is a general-purpose MicroVM, and its startup process includes many steps unnecessary for Agent sandbox scenarios. We performed full-link tailoring and optimization for this scenario:

Minimized device model: Only retain virtual devices essential for sandbox scenarios (virtio-net, virtio-blk, serial), removing all unnecessary peripheral simulations.
Customized Guest Kernel: A tailored Linux kernel that retains only the minimal feature set required for Agent execution, drastically shortening the kernel boot path.
User-space interrupt handling: Critical I/O paths are completed in user space, reducing kernel-mode switching overhead.

2) Resource Pool Pre-creation + Snapshot Cloning (Key to <60ms Cold Start)

Fast cold start is not achieved by “the VM itself starting quickly” (which only reaches hundreds of milliseconds), but through a complete resource pool + snapshot mechanism:

Specifically:

Resource pool pre-creation: A batch of already started “blank sandboxes” are maintained in the background. When a request arrives, it is directly taken from the pool, skipping the entire startup process.
Snapshot cloning: Based on Copy-on-Write (CoW) technology, new instances are cloned instantly from a template sandbox. Memory pages are allocated physical memory only when actually written.

This is why a single instance uses <5MB memory: most memory pages are shared with the template (read-only), and only pages actually written during Agent execution occupy additional memory.

3) Network Isolation and Security Control

Security is not just VM isolation; the network layer is also critical:

Each sandbox has an independent virtual network stack.
Kernel-level outbound traffic filtering is implemented based on eBPF, allowing fine-grained control over which external addresses each sandbox can access.
Supports dynamic delivery and updating of network policies without restarting the sandbox.

4) E2B Protocol Compatibility

E2B is currently the de facto standard protocol in the AI Agent sandbox field, used by products such as Manus, Perplexity, and Hugging Face. We natively compatible with the E2B protocol at the API layer, which means:

Projects already using the E2B SDK only need to change the endpoint to the CubeSandbox address, with no other code changes.
No need to learn a new SDK or modify business logic.
It provides an “open-source alternative” to E2B: better performance, fully open-source, and self-hostable.

Currently, Cube Sandbox is continuously expanding its ecosystem capabilities and building compatibility and integration solutions with mainstream Agent frameworks and the open-source community.

Event-level snapshot rollback capability is also coming soon — sub-100ms state rollback, providing additional protection for the unpredictable behavior of Agents.

For detailed technical principles, please refer to: https://km.woa.com/articles/show/657197

Case Studies

At present, Cube Sandbox has been verified by large-scale real workloads in Tencent Cloud’s internal production environments and external customers — it has supported tens of billions of calls, powering stable operation of hundreds-of-millions user products such as Tencent Yuanbao. In more complex scenarios, it has also enabled a leading domestic model application vendor to schedule hundreds of thousands of sandbox instances in minutes under Agentic RL training, effectively solving pain points such as malicious code execution, data leakage, and resource abuse caused by Agent autonomy. Here are several typical cases:

Case 1: Leading Domestic Model Application — Leap in Code Execution Experience

Pain Point: AI Agents need to execute code in real time and return results. Traditional solutions either use Docker (shared kernel, high security risks) or VMs (startup takes seconds, users wait). Moreover, sandboxes are not recycled in time after code execution, leading to serious resource waste during peak hours.

After accessing CubeSandbox: Each request is assigned an independent micro virtual machine with hardware-level isolation, maximizing security. Resource pool pre-creation + snapshot cloning reduce sandbox delivery to <60ms, and code running latency drops from seconds to hundreds of milliseconds — users feel “Agent responds instantly”. Meanwhile, on-demand creation and immediate destruction reduce resource usage by 95%.

Case 2: Leading Domestic Model Vendor — Qualitative Leap in RL Training Efficiency

Pain Point: Agentic RL training requires massive sandboxes for code execution experiments — each episode needs an independent isolated environment, which is destroyed and recreated after running. Traditional solutions are extremely slow to spin up training sandboxes; the cumulative waiting time for thousands of episodes is huge, causing massive GPU computing power idling.

After accessing CubeSandbox: <5MB memory per instance increases single-machine concurrency by dozens of times, and <60ms startup ensures almost zero waiting between episodes. Training sandboxes that previously took 30 minutes to spin up are now ready in 1 minute, greatly improving training efficiency. Each episode runs in a clean independent environment, eliminating the risk of residual files contaminating training results.

Case 3: Secure Agent Tool Invocation

Pain Point: In addition to running code, Agents also need to call various external APIs, search, and perform file operations. Preventing data leakage and unauthorized access is a critical security red line in enterprise scenarios.

CubeSandbox Solution: Each sandbox has an independent network stack, with no external network access by default. Fine-grained outbound whitelists are implemented through eBPF kernel-level traffic control — only domains required for business are allowed, others are blocked. Policies can be dynamically delivered without restarting sandboxes, and all outbound requests are fully auditable and traceable.

How to Deploy and Experience

Environment Requirements:

Linux system (KVM support required)
Recommended: OpenCloudOS 9
Hardware must support virtualization

Deployment Process:

We have simplified the deployment process to 4 steps, and users can achieve faster access and deployment through one-click deployment scripts:

Start development VM (skip if you already have an x86_64 bare-metal Linux server)

Clone the repository and start a disposable OpenCloudOS 9 development VM:

git clone https://github.com/tencentcloud/CubeSandbox.git

cd CubeSandbox/dev-env

./prepare\_image.sh

./run\_vm.sh

Open a new terminal:

cd CubeSandbox/dev-env && ./login.sh

Start Cube Sandbox Service

Execute inside the logged-in VM:

curl -sL https://cnb.cool/CubeSandbox/CubeSandbox/-/git/raw/master/deploy/one-click/online-install.sh | MIRROR=cn bash

Create Code Interpreter Sandbox Template

After installation, create a code interpreter template using the pre-built image:

cubemastercli tpl create-from-image \\

&#x20; \--image ccr.ccs.tencentyun.com/ags-image/sandbox-code:latest \\

&#x20; \--writable-layer-size 1G \\

&#x20; \--expose-port 49999 \\

&#x20; \--expose-port 49983 \\

&#x20; \--probe 49999

Wait for the command to complete, and the template status will become READY. Record the template_id from the output for the next step.

Run Your First Agent Code

Install Python SDK:

yum install -y python3 python3-pip

pip config set global.index-url https://mirrors.ustc.edu.cn/pypi/simple

pip install e2b-code-interpreter

Set environment variables:

export E2B\_API\_URL="http://127.0.0.1:3000"

export E2B\_API\_KEY="dummy"

export CUBE\_TEMPLATE\_ID="\<your-template-id>"

Run code in an isolated sandbox:

import os

from e2b\_code\_interpreter import Sandbox

with Sandbox.create(template=os.environ\["CUBE\_TEMPLATE\_ID"]) as sandbox:

&#x20;   result = sandbox.run\_code("print('Hello from Cube Sandbox, safely isolated!')")

&#x20;   print(result)

For more variable descriptions and examples, see Quick Start — Step 4.

Millisecond-level Startup

Want to explore more? Check out the examples/ directory, covering code execution, Shell commands, file operations, browser automation, network policies, pause/resume, OpenClaw integration, RL training, and other scenarios.

💡 Special Recommendation: Cube Sandbox has been perfectly adapted to OpenCloudOS 9 (OC9). We strongly recommend internal colleagues to build an ultra-fast, secure Agent execution environment based on the native OC9 + Cube combination.

Conclusion & Invitation to Collaborate

We open-source Cube Sandbox completely because we firmly believe: in the era of intelligent agents, high-performance, high-security underlying infrastructure should not be monopolized by closed-source commercial APIs — it should become an open, self-hostable industry cornerstone.

The project has just been released and is still in the early stage of rapid iteration. We sincerely welcome internal architects, R&D colleagues, and product colleagues to check out our code, put forward suggestions, share ideas, and build together with us.

👉 GitHub Open Source Repository: GitHub - TencentCloud/CubeSandbox

👉 Quick Start Guide: CubeSandbox/docs/zh/guide/quickstart.md

If this project inspires or helps your business, please light up a Star 🌟 on GitHub! If you have any Bug feedback or Feature requests during experience or integration, welcome to join our internal WeChat group below for feedback and communication, or submit Issue/PR in the repository. Let’s build the underlying secure cockpit foundation for the intelligent agent era together!