Sub-60ms hardware-isolated sandboxes with an E2B-compatible API just picked up cross-node pause/resume — CubeSandbox v0.7.0 is Tencent's answer to where agent code should actually run.
Tencent Cloud shipped CubeSandbox v0.7.0 on the project's public changelog — cross-node pause/resume, CubeOps control-plane separation, and faster sandbox networking. The repo sits at ~11.5k GitHub stars, ~1.1k forks, Apache 2.0, and CNCF Landscape listed — a credible self-hosted lane for teams outgrowing container-only agent isolation.
explainx.ai's read: if your agent harness runs untrusted model-generated code, MicroVM isolation beats namespace tricks — see local LLM sandboxing guidance. CubeSandbox targets that tier with E2B migration ergonomics.
TL;DR — what people are asking
| Question | Direct answer |
|---|---|
| v0.7 headline features? | Cross-node pause/resume (S3), CubeOps ops split, faster networking |
| Boot time? | <60ms cold start claimed; P99 137ms at 50 concurrent creates (bare metal) |
| Memory overhead? | <5MB base per sandbox (≤32GB spec configs) |
| E2B compatible? | Yes — swap API URL; roadmap closes remaining spec gaps |
| License? | Apache 2.0 |
| Requirements? | x86_64 Linux + KVM (ARM64 supported since v0.5) |
v0.7.0 — what changed
From docs/changelog/v0.7.0.md:
| Feature | Practitioner meaning |
|---|---|
| Cross-node pause/resume | Suspend on node A, resume on node B with S3-backed state — migrate long agent sessions without replaying setup |
| Snapshot sandboxes (preview) | Fork from checkpoints across the cluster |
| CubeOps separation | Node/ops management moves to CubeOps with multi-replica deploy + cubeopscli |
| Faster networking | Lower latency between sandbox and control plane — matters for tight agent tool loops |
Prior releases worth knowing: v0.6 Kubernetes deploy + volume framework; v0.5 AutoPause/AutoResume + Terraform; v0.4 credential vault via CubeEgress; v0.3 CubeCoW snapshots at hundred-ms granularity.
Architecture — why not Docker alone?
CubeSandbox's benchmark table (from README) frames the tradeoff:
| Metric | Docker | Traditional VM | CubeSandbox |
|---|---|---|---|
| Isolation | Shared kernel | Dedicated kernel | Dedicated kernel + eBPF |
| Boot | ~200ms | Seconds | <60ms |
| Memory overhead | Low shared | High | <5MB claimed |
| Density | High | Low | Thousands/node claimed |
| E2B SDK | — | — | Drop-in target |
Components map cleanly for operators:
- CubeAPI — Rust REST gateway (E2B-compatible)
- CubeMaster — scheduling / cluster state
- Cubelet — per-node lifecycle
- CubeEgress — L7 egress filter + credential injection (secrets never enter sandbox filesystem)
- CubeVS — eBPF virtual switch / policy
That egress model matters for agents calling paid APIs — same problem class as Cloudflare Wallets for agent spend, but at the network shim layer.
Quick start — four steps (no source build)
Docs recommend:
- Provision KVM-capable Linux (PVM cloud VM path is "recommended")
- Install CubeSandbox (Makefile / deploy scripts)
- Create a template from image
- Run first agent code via API or WebUI at
http://<control-node>:12088
Web console flow: Overview → Template Store → Sandboxes → + New sandbox → live logs.
Dev-env QEMU path exists but README warns poor performance — use for demos, not prod agent load.
E2B migration sketch
# Conceptual — set E2B-compatible endpoint to your CubeAPI URL
# See CubeSandbox docs/guide/tutorials/examples.md for SDK env vars
import os
os.environ["E2B_API_URL"] = "https://cube-api.yourdomain.example"
# Existing E2B client code often runs with URL swap only
from e2b_code_interpreter import Sandbox
with Sandbox() as sbx:
print(sbx.run_code("print('hello from MicroVM')"))
Validate volume, snapshot, and pause/resume calls against v0.7 preview flags before cutting over production evals.
Limitations — issue tracker reality
As of late August 2026, the repo shows 90+ open issues and 90+ open PRs — active but not finished. Roadmap items include faster cross-node resume, full E2B API parity, fault recovery, and scheduling enhancements.
Not a macOS native story — builders on Apple silicon still need remote Linux KVM nodes (same pattern as local agent sandboxing).
Tencent Cloud sponsorship — Terraform one-click targets Tencent; K8s path is broader but ops burden is yours.
Related on explainx.ai
- Fix local LLM looping — sandboxing options
- Claude Desktop restrict access sandbox guide
- What is an agent harness?
- DeepSeek harness — plugin sandbox warnings
- Sim / SimStudio — E2B in workflows
- Terminal Bench 2.0 — where isolated evals matter
CubeSandbox v0.7.0 features per Tencent Cloud GitHub docs, August 2026. Star counts and benchmarks from repository README — reproduce on your hardware before capacity planning.