CubeSandbox (Tencent) — Summary

CubeSandbox is a high-performance microVM sandbox service from Tencent, built on RustVMM and KVM, that achieves sub-60ms cold start times through resource pool pre-provisioning and snapshot cloning — while keeping per-sandbox memory overhead below 5MB via Copy-on-Write and an aggressively trimmed Rust runtime. It is E2B SDK-compatible (drop-in replacement by changing one URL environment variable), supports both single-node and multi-node cluster deployment, and has been validated at scale in Tencent Cloud production. The architecture layers CubeAPI (E2B-compatible REST gateway) → CubeMaster (orchestration scheduler) → Cubelet (node-local lifecycle manager) → CubeHypervisor+CubeShim (KVM microVM virtualization layer), with CubeVS (eBPF) providing kernel-level inter-sandbox network isolation. CubeSandbox targets AI agent code execution use cases where Docker's shared-kernel (namespace) isolation is insufficient and traditional VM startup latency is unacceptable.

Differs from seeds: CubeSandbox has no counterpart among the 11 seeds — all seeds operate at the LLM agent-loop layer. CubeSandbox sits at the lowest infrastructure layer: it is the actual hardware-isolated execution environment that agents run inside. Its closest comparison within the batch is OpenSandbox (another enterprise Asian-origin sandbox platform) and AgentTier (K8s-native lifecycle), but CubeSandbox is distinguished by its microVM primitive (dedicated kernel per sandbox), E2B drop-in compatibility, and extreme performance metrics (sub-60ms startup, <5MB memory overhead).

CubeSandbox — Overview

Origin

Created by TencentCloud engineering, validated at scale in Tencent Cloud production environments. The project addresses the trilemma of sandbox security: Docker has fast startup but weak isolation (shared kernel); traditional VMs have strong isolation but slow startup and high overhead; CubeSandbox aims to achieve all three simultaneously via RustVMM + KVM + CoW + resource pools.

Core philosophy

From the README:

"Cube Sandbox is a high-performance, out-of-the-box secure sandbox service built on RustVMM and KVM. It supports both single-node deployment and easy scaling to multi-node clusters."

The three pillars stated in the README:

1. Blazing-fast cold start — resource pool pre-provisioning + snapshot cloning skip all initialization overhead
2. High-density deployment — CoW memory reuse + trimmed Rust runtime = thousands of instances per node
3. True kernel-level isolation — each sandbox gets its own dedicated Guest OS kernel (no container escape risk)

Performance benchmark claims (verbatim from README)

"Average end-to-end cold start time for a fully serviceable sandbox is < 60ms." "per-instance memory overhead below 5MB" "Under 50 concurrent creations, avg 67ms, P95 90ms, P99 137ms — consistently sub-150ms."

E2B compatibility philosophy

"Zero-cost migration (E2B drop-in replacement): Natively compatible with the E2B SDK interface. Just swap one URL environment variable — no business logic changes needed — to migrate from expensive closed-source sandboxes to free Cube Sandbox with better performance."

This is a deliberate market positioning choice: target the large existing base of E2B users with a self-hosted, high-performance, free alternative.

Production validation

"Cube Sandbox has been validated at scale in Tencent Cloud production environments, proven stable and reliable."

CubeSandbox — Architecture

Sandbox primitive

KVM microVM (hardware-virtualized) via RustVMM:

• Each sandbox gets a dedicated Guest OS kernel — no shared kernel, no container escape
• Copy-on-Write (CoW) memory for extreme density: < 5MB overhead per sandbox
• Snapshot cloning for cold start: skip all initialization, clone from pre-provisioned snapshot

Startup time (benchmarked):

• Single concurrency: < 60ms average end-to-end
• 50 concurrent: avg 67ms, P95 90ms, P99 137ms
• All sub-150ms

Performance comparison (from README)

Distribution

• One-click install (online):

  curl -sL https://github.com/tencentcloud/CubeSandbox/raw/master/deploy/one-click/online-install.sh | bash
  

• Source build: git clone + make
• Dev environment: QEMU-based VM via dev-env/prepare_image.sh + run_vm.sh

Directory tree (repo)

CubeSandbox/
├── CubeAPI/              # E2B-compatible REST API gateway (Go)
├── CubeMaster/           # Orchestration scheduler (Go)
├── CubeNet/              # Network management
├── CubeProxy/            # Reverse proxy (host-based + path-based routing)
├── CubeShim/             # containerd Shim v2 API implementation
├── Cubelet/              # Node-local sandbox lifecycle manager
├── agent/                # Internal agent components
├── configs/              # Configuration files
├── cubelog/              # Logging
├── deploy/
│   └── one-click/        # Install scripts
├── dev-env/              # Development environment (QEMU VM)
├── docker/               # Docker configs
├── docs/                 # Documentation
├── examples/             # Code execution, browser, network, RL examples
├── hypervisor/           # CubeHypervisor (RustVMM + KVM)
├── network-agent/        # CubeVS (eBPF network isolation)
├── openapi.yml           # OpenAPI spec
├── scripts/              # Setup scripts
├── sdk/                  # SDK components
└── web/                  # Web UI

Layered architecture

Client (E2B SDK or native) → CubeAPI (REST gateway)
    → CubeMaster (orchestration scheduler)
    → Cubelet (node-local lifecycle manager)
    → CubeHypervisor + CubeShim (RustVMM + KVM microVM)
    CubeVS (eBPF) for network isolation at all layers
    CubeProxy for request routing

Required runtime

• x86_64 Linux with KVM support (WSL2, Linux physical machine, cloud bare-metal, or cloud VM with PVM)
• NOT supported on Windows without WSL2, NOT on ARM, NOT in most cloud VMs without PVM

Host-OS posture

Strong isolation: each sandbox runs a dedicated Guest OS kernel. The host kernel is protected from sandbox workloads by the KVM hypervisor layer. CubeVS (eBPF) enforces inter-sandbox network isolation at the kernel level.

Config files

• conf.yaml (CubeMaster configuration)
• Template definitions (via cubemastercli tpl create-from-image)

CubeSandbox — Components

Core runtime services

CLI (cubemastercli)

E2B SDK compatibility

CubeSandbox transparently intercepts E2B SDK calls when E2B_API_URL is set to the CubeSandbox endpoint:

from e2b_code_interpreter import Sandbox  # Standard E2B SDK, unmodified

with Sandbox.create(template=os.environ["CUBE_TEMPLATE_ID"]) as sandbox:
    result = sandbox.run_code("print('Hello from Cube Sandbox!')")

No code changes required — only environment variable change.

Pre-built sandbox images

• cube-sandbox-int.tencentcloudcr.com/cube-sandbox/sandbox-code:latest (international)
• cube-sandbox-cn.tencentcloudcr.com/cube-sandbox/sandbox-code:latest (mainland China)

Claude Code integration

• .claude/ directory exists in repo root
• AGENTS.md for AI contributor guidance

Example scenarios (from examples/ directory)

• Code execution
• Shell commands
• File operations
• Browser automation
• Network policies
• Pause/resume
• OpenClaw integration
• RL training (SWE-Bench)

Roadmap components (not yet shipped)

• Event-level snapshot rollback — millisecond-granularity snapshots for fork-based exploration

CubeSandbox — Uniqueness & Positioning

Differs from seeds

CubeSandbox has no counterpart among the 11 seeds. All seeds operate at the LLM agent-loop layer (prompts, skills, hooks) while CubeSandbox is a KVM microVM infrastructure platform. Within this batch, it most resembles OpenSandbox (another enterprise Asian-origin sandbox) and AgentTier (K8s lifecycle), but CubeSandbox is unique in three ways: (1) KVM microVM isolation — the only platform in this batch using dedicated Guest OS kernels as the default (vs. container namespaces); (2) sub-60ms cold start via snapshot cloning + CoW — the fastest startup of any platform in the batch; (3) E2B drop-in compatibility — the only platform explicitly targeting E2B migration. The < 5MB memory overhead enabling thousands of sandboxes per node is also unique — no other platform in the batch claims this density.

Positioning

CubeSandbox targets AI agent platform teams who need production-grade security (no shared kernel, no container escape) with performance metrics competitive with containerized solutions. The E2B compatibility is a migration path for teams currently spending on E2B Cloud. The Tencent Cloud production validation is a credibility signal for enterprise customers in Asia-Pacific.

Key architectural bets

1. RustVMM + KVM — using the Rust-based VMM for security and performance (same tech as Firecracker, but in-house implementation)
2. Snapshot + CoW = density without compromise — pre-provisioned snapshots eliminate cold start latency; CoW memory sharing eliminates memory overhead
3. E2B API compatibility — the largest possible TAM for a new sandbox product is "everyone already using E2B"
4. eBPF network isolation (CubeVS) — kernel-level packet filtering exceeds what container network policies achieve

Observable failure modes

• x86_64 KVM requirement — does not run on ARM64 (contrast with CUA which runs on Apple Silicon), does not run in most cloud VMs without PVM host kernel installation
• PVM dependency — enabling KVM in standard cloud VMs requires installing the PVM host kernel, which is a non-standard step for most operators
• Large template images — "The image is fairly large — downloading, extracting, and building the template may take a while" (from README)
• Limited observability documentation — no explicit Prometheus/OTel integration described; operational monitoring in production may require custom instrumentation
• Chinese-first documentation — CONTRIBUTING_zh.md and China-specific mirror instructions suggest primary audience is mainland China; international documentation quality may lag

Cross-references

• E2B (named implicitly as the primary competitor in the compatibility claim)
• OpenClaw integration in examples
• SWE-Bench RL training demonstrated in video demos