The Problem
AI agents need to execute untrusted, LLM-generated code, but existing sandbox options force a tradeoff. Docker containers share the host kernel, creating container-escape risk. Full VMs are safe but too slow to spin up per task. CubeSandbox targets that gap: hardware-level isolation with sub-60ms cold starts and under 5MB per-instance memory overhead, making per-agent VMs practical.
What This Does
CubeSandbox is a two-component system. CubeMaster/ is a Go-based control plane that manages the cluster, nodes, templates, and the gRPC API surface (api/services/cubebox/v1/cubebox.proto). It handles node discovery, image caching (pkg/localcache/), resource pooling, and a CLI (cmd/cubemastercli/) for operational tasks. CubeAPI/ is a Rust service that exposes an HTTP API compatible with the E2B SDK, so existing E2B clients work by changing a single URL environment variable.
The sandboxing itself runs on RustVMM and KVM with per-guest kernels, not shared-kernel namespaces. The README claims average cold start under 60ms via snapshot cloning and pre-provisioned resource pools. The repo includes a benchmark suite (CubeAPI/benchmark/main.go) and integration tests (CubeMaster/integration/) to validate these claims.
How To Use It
The repo provides CubeMaster/Makefile and CubeMaster/docker/Dockerfile for building the control plane, plus GitHub Actions workflows for CI. The README references a quickstart at docs/guide/quickstart.md, but that file is not present in the provided structure. The E2B-compatible API means a Python client can use the standard e2b SDK:
Point the E2B SDK at your CubeSandbox instance
import os os.environ["E2BAPIURL"] = "http://your-cubesandbox-host:8000" from e2b import Sandbox sandbox = Sandbox(template="my-template") sandbox.commands.run("pip install requests")
Setup requires building the Docker image and deploying CubeMaster; the exact commands are documented in the missing quickstart file, so follow the README's documentation links rather than inferring flags.
Real-World Use
A practical fit is RL training or agent evaluation pipelines, where you run thousands of isolated environments in parallel. Each agent step gets a fresh, kernel-isolated VM in tens of milliseconds, executes code, returns output, and the VM is destroyed. The SWE-Bench RL demo in the README shows exactly this pattern. The E2B compatibility means teams with existing E2B workloads can migrate without rewriting application code.
Code Health & Issues
High - No LICENSE file in root - The README badge claims Apache 2.0, but the license file is absent. This creates legal ambiguity for downstream use. Med - Missing quickstart documentation - docs/guide/quickstart.md is referenced but not present in the file listing. Core setup instructions are unavailable. Med - Go/Rust split adds operational complexity - Two runtimes, two build systems (go.mod, Cargo.toml), and two deployment units. Justified by the design, but increases maintenance surface. Low - Test coverage is uneven - CubeMaster has 31 test files with solid unit tests (pkg/base/, cmd/cubemastercli/), but CubeAPI has no visible test files, leaving the E2B-compatible API layer untested. Low - Typo in file name - CubeMaster/cmd/cubemaster/app/singal.go should be signal.go. Cosmetic, but a sign of review gaps.
The Bottom Line
CubeSandbox is a serious infrastructure project from Tencent Cloud with a real performance story: kernel isolation at VM-level security with container-level speed. The E2B compatibility is a pragmatic adoption path. The missing license file and quickstart docs are blockers for production use, and the unproven CubeAPI test coverage warrants scrutiny before depending on it. Best suited to teams already running agent workloads at scale who need stronger isolation than Docker provides.