Tencent Cloud has open-sourced CubeSandbox, a Rust-based sandbox runtime for AI agents that boots each instance in its own microVM via RustVMM and KVM. The project lives on GitHub under Apache 2.0 and is pitched as a drop-in replacement for E2B.
What's actually being shipped
CubeSandbox is structured as a small cluster of services: an API gateway, a master orchestrator, per-node Cubelets, an eBPF virtual switch, and the runtime itself. The repo includes single-node and multi-node deployment paths, and the codebase is roughly 52% Rust, 26% Go, 19% C.
That part is unremarkable. Another microVM sandbox in a crowded year for microVM sandboxes. The pitch is the numbers, and the numbers are loud.
The numbers, and how to read them
Tencent claims a cold start under 60 milliseconds for a fully serviceable sandbox, and less than 5 MB of memory overhead per instance. Under 50 concurrent creations, the README reports a 67ms average, 90ms at P95, 137ms at P99. These figures are measured on bare metal in Tencent's own lab, not independently. Worth holding in mind.
For comparison, the README pits CubeSandbox's sub-60ms number against Docker's roughly 200ms boot and notes that traditional VMs take minutes. Both benchmarks are their own, against unnamed configurations, so the framing does what you'd expect a GitHub README to do.
Still, the ballpark is consistent with what other rust-vmm-derived stacks achieve. E2B's Firecracker-backed sandboxes are routinely described at around 125ms, so sub-60ms is aggressive but not implausible. The sub-5MB claim is the harder one: it depends on how much you've stripped out of the guest, and that affects what your agent can actually do inside.
Why the E2B compatibility is the real story
The more interesting move is the positioning. CubeSandbox natively speaks the E2B SDK protocol. Tencent's quickstart shows you importing Sandbox from e2b_code_interpreter and pointing the API URL at a local Cube instance. No rewriting, no new SDK, no migration work. Swap one env var.
E2B has become something of a default for running LLM-generated code. Tencent aiming its compatibility squarely at that SDK is a clear signal: they don't want developers building on a new protocol. They want E2B users to have a free, self-hostable alternative with better numbers, and they've built the glue to make switching nearly trivial.
Whether the execution holds up in production workloads outside Tencent's bare-metal testbed is the next question.
Gaps
The README credits Cloud Hypervisor, Kata Containers, virtiofsd, and containerd-shim-rs as upstream influences, with modifications. An event-level snapshot rollback feature is listed as coming soon. No release tags exist on the repo yet. The project claims validation in Tencent Cloud production but doesn't specify which workloads or at what scale.
The repo is public on GitHub under Apache 2.0, with documentation at docs.cubesandbox.ai. For teams already running E2B-compatible workflows, testing a swap is a short exercise.
