Preface¶

As the capabilities of large models continue to advance, AI Agents are evolving from “conversation assistants” to autonomous execution entities that can write code, call tools, and run scripts. The Managed Agent architecture proposed by vendors like Anthropic has also split Session, Harness, and Sandbox into independent components. The industry has gradually reached a consensus: Agent code execution must be placed in an isolated environment, otherwise the security risks in multi-tenant scenarios are difficult to control.

The problem is that existing infrastructure often forces a trade-off between “speed” and “security”: Docker containers start fast and have high density, but share the host kernel, making it difficult to defend against escapes from malicious code generated by LLMs; traditional virtual machines provide sufficient hardware isolation, but often have second-level cold start times and hundreds of MB of memory overhead, which cannot support the high-frequency “use-and-destroy” scheduling mode of Agents.

In April 2026, Tencent Cloud fully open-sourced its production-grade sandbox service CubeSandbox under the Apache 2.0 protocol (not SDK fragments, but the entire sandbox-as-a-service stack). Built on RustVMM + KVM MicroVM, the official claims that cold start can be as low as 60ms, the additional memory overhead per instance is <5MB, and it natively supports the E2B SDK. As of July 2026, CubeSandbox has continuously topped GitHub Trending, with over 10,000 stars, and is regarded by many developers as a key infrastructure for large-scale concurrent execution of Agents.

This article verifies key information based on the GitHub repository, official documentation, and Tencent Cloud press release, and sorts out its technical principles and onboarding methods.

The “Impossible Triangle” of Agent Execution Environments¶

When running code generated by users or models, a sandbox must meet at least three types of requirements:
1. Secure Isolation: Independent boundaries for each task to prevent kernel escapes, lateral penetration, and data exfiltration.
2. Elastic Concurrency: A single tool call may only take a few seconds, but the cluster may need to create and destroy tens of thousands of instances per minute.
3. Ecosystem Compatibility: Developers have already written business code on protocols like E2B and OpenAI Code Interpreter, and the lower the migration cost, the better.

CubeSandbox aims to use MicroVM-level hardware isolation to approach container-level startup speed and resource density. The official comparison data is as follows (measured in production environments, not ideal laboratory values):

Technical Foundation: Self-developed RustVMM Instead of Docker Wrapper¶

CubeSandbox did not choose to wrap another layer on top of Docker, nor did it directly use AWS Firecracker. Instead, it independently developed a lightweight VMM (CubeHypervisor) based on the CloudHypervisor route, implemented in Rust, and fully tailored for Agent scenarios. The core optimizations listed in the official documentation include:
- Simplified Device Model: Only retain virtual devices necessary for sandboxes such as virtio-net, virtio-blk, and serial.
- Customized Guest Kernel: Trimmed the Linux kernel function set to shorten the startup path.
- User-space Interrupt Handling: Complete key I/O paths in user space as much as possible to reduce kernel mode switches.

Each sandbox runs an independent Guest OS kernel through KVM hardware virtualization, completely avoiding the escape surface of container shared kernels. CubeShim implements the containerd Shim v2 interface, enabling MicroVMs to access the existing container runtime ecosystem.

The <60ms cold start is not just about “the VM itself starting extremely fast”, but relies on the combined mechanism of resource pool pre-creation + snapshot cloning (CoW):
1. Maintain a batch of pre-started “blank sandbox” resource pools in the background, and directly use them when requests arrive, skipping the complete boot process.
2. Clone new instances from the template sandbox based on Copy-on-Write, and physical memory pages are only allocated when written to — this is also the key reason for the <5MB additional memory overhead per instance: most read-only pages are shared with the template.

On a 96 vCPU host, the official claims that 2000+ sandboxes can be deployed; the platform-level burst scheduling can exceed 100,000 instances per minute. In customer cases like MiniMax, it is mentioned that in the Agentic RL training scenario, hundreds of thousands of heterogeneous sandboxes (Linux / Windows / Android) can be scheduled in minutes.

Layered Architecture and eBPF Network Security¶

CubeSandbox adopts a control plane / data plane layered design, with the main components as follows:

Security does not only rely on VM boundaries. CubeVS uses eBPF to implement outbound traffic filtering in the data plane, and rejects private network segments and link-local addresses by default; CubeEgress requires explicit approval for external domain names, and keys are injected through the control plane and never enter the sandbox, model context, or logs. Policies can be dynamically issued without restarting the sandbox.

Version v0.3.0 introduced the CubeCoW snapshot engine, supporting hundred-millisecond level checkpoint, cloning, and rollback; version v0.5.0 (2026-07-03) further added AutoPause/AutoResume, full ARM64 stack support, and network policy hardening. The event-level snapshot rollback capability mentioned in the press release will be open-sourced separately after development is completed.

E2B SDK Compatibility: Change One Environment Variable¶

E2B has become the de facto standard protocol in the Agent sandbox field, and products such as Manus and Perplexity have adopted it. CubeSandbox natively supports E2B at the API layer. Most existing migration projects only need to adjust the endpoint-related environment variables, and the business code does not need to be rewritten. The OpenAI Python SDK can also be used together.

The following examples are from the official Quick Start (need to run in a x86_64 Linux environment that supports KVM, OpenCloudOS 9 is recommended):

1. One-click install the service

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

2. Create a Code Interpreter template

cubemastercli tpl create-from-image \
  --image ccr.ccs.tencentyun.com/ags-image/sandbox-code:latest \
  --writable-layer-size 1G \
  --expose-port 49999 \
  --expose-port 49983 \
  --probe 49999

3. Run isolated code with the E2B Python SDK

pip install e2b-code-interpreter

export E2B_API_URL="http://127.0.0.1:3000"
export E2B_API_KEY="dummy"
export CUBE_TEMPLATE_ID="<your-template-id>"

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!')")
    print(result)

After installation, the web console listens on :12088 by default, where you can manage sandboxes, templates, and nodes. The examples/ directory of the repository also covers scenarios such as shell execution, browser automation, network policies, OpenClaw integration, and RL training.

Deployment Forms and Applicable Scenarios¶

CubeSandbox supports standalone bare metal, multi-node clusters, Helm deployment to Kubernetes, and one-click cluster deployment with Tencent Cloud Terraform. The Apache 2.0 license is business-friendly, suitable for private deployment and compliance audits.

Typical scenarios include:
- Basic Model Labs: Agentic RL training requires a huge number of short-lived sandboxes, and millisecond-level creation can significantly reduce GPU idle time.
- Agent Developers / SMEs: No need to build a K8s cluster, set up the environment in a few minutes with scripts, and access through MCP, API, SDK, or CLI.
- Enterprise Customers: Data does not leave the domain, and配合 with credential vaults and outbound audits meet compliance requirements such as equal protection and internal control.

Tencent Cloud stated that CubeSandbox has been verified in products with hundreds of millions of users such as Tencent Yuanbao, supporting a total of tens of billions of calls; it will also combine with the TACO AI acceleration engine and FlexKV caching system to form a full-stack Agent infrastructure of “secure sandbox + inference acceleration + cache optimization”.

Summary¶

CubeSandbox pushes Agent sandboxes from “making do with containers” or “too slow to afford VMs” to a third path: KVM hardware isolation + RustVMM extreme tailoring + E2B ecosystem compatibility. If the 60ms cold start and 5MB-level memory overhead can be reproduced in your workload, it can indeed significantly reduce the infrastructure cost of Agent concurrent execution.

The project is iterating rapidly (v0.5.0 already supports AutoPause and ARM64), and GitHub Issues and PRs are active. If you are evaluating a self-hosted Agent execution environment, you might as well pull the code on a test machine to test the P95 latency and density limit — after all, in the Agent era, sandboxes are not an option, but a default infrastructure.

• Repository: https://github.com/TencentCloud/CubeSandbox
• Documentation: https://cubesandbox.com
• License: Apache 2.0