Running AI agent sandboxes at scale is expensive for a simple reason: every sandbox holds memory whether it is doing anything or not. Sandstorm v0.6, an open-source project by deeplethe, attacks that directly. By checkpointing idle sandboxes to disk and restoring them on demand, it fits 3,333 isolated environments on a single 2-core, 2 GB node — where plain gVisor containers fit only 96. Version 0.6.0, released this week, makes gVisor the default backend, adds Firecracker as an optional second tier, and ships everything as a single binary. Here is what changed, how it benchmarks, and how to run it.
The Problem: You Are Paying for Idle Time #
AI coding agents — Cursor, Claude Code plugins, internal tools — each need an isolated environment to run untrusted code. The managed sandbox market has matured fast: E2B, Daytona, and Render charge around $0.05 per vCPU-hour, billed by the second. That sounds cheap until you need 200 concurrent sandboxes, which runs to roughly $16,800 per month on E2B. The core issue is that most sandboxes spend the vast majority of their time idle between agent turns, yet they hold memory the entire time.
Sandstorm’s answer is to stop pretending sandboxes need to stay resident. If a sandbox has not received a request in a while, freeze it. If it stays frozen, checkpoint it to disk. When a new request arrives, restore it before the first packet lands.
Four Tiers, One Machine #
Sandstorm manages sandboxes across four tiers:
- Hot — running in memory, instant response
- Frozen — d with
cgroup.freeze, cold pages pushed to zswap; about 10 ms back to hot - Cold — memory reclaimed into zswap, process still alive but slower to restore
- Snapshot — checkpointed to disk, network namespace released, zero memory held; about 200 ms to restore
Sandboxes drop tiers automatically as they stay idle. Any incoming request promotes them straight back to hot. A gateway on the sandbox’s node handles the wake transparently — the caller sees slightly elevated first-response latency on a cold restore, not an error.
The density impact on a cluster of six 2-core, 2 GB nodes:
| Configuration | Sandboxes per node |
|---|---|
| Docker + gVisor (plain containers) | 96 |
| Sandstorm (all sandboxes awake) | 144 |
| Sandstorm (idle ones tiered to disk) | 3,333 |
The 1.5x gain from always-awake Sandstorm comes from eliminating the per-container daemon and shim overhead. The 34x gain comes from tiering — sandboxes on disk hold zero memory.
What Changed in v0.6.0 #
The headline change is that gVisor is now the default backend. gVisor needs no KVM — it intercepts syscalls in user space via its own kernel written in Go, which means Sandstorm now works on any cloud VM without nested virtualisation. Google donated gVisor to the CNCF at KubeCon North America this week, cementing it as the standard for Kubernetes-native sandboxing.
Firecracker, the KVM-based microVM backend, remains available for hosts with KVM support. Both backends can coexist in one fleet, each forming its own resource pool. The master places sandboxes on the right node type based on the template’s backend setting.
Architecturally, v0.6 ships as a single sandstormd binary that acts as master, node, and web console. For larger deployments, one master keeps desired state in SQLite and coordinates multiple node agents over mTLS.
Benchmarks Against Other Runtimes #
Sandstorm ran itself against Kata Containers, microsandbox, CubeSandbox, plain gVisor, and Docker containers on bare metal. Key numbers from the v0.6.0 release notes:
- Snapshot a running sandbox: Sandstorm 52 ms, CubeSandbox 252 ms
- Clone into 20 instances: Sandstorm 361 ms, CubeSandbox 1,064 ms
- Cold start from warm template (gVisor): ~168 ms; Firecracker: ~84 ms
- Kata Containers cold start: ~3,000 ms — impractical for agent workloads
Sandstorm is not the fastest cold-start runtime — CubeSandbox beats it on fresh start latency. But Sandstorm is the fastest at snapshot and clone, which is exactly what the tiering model depends on.
Quick Start #
Requirements: Linux with cgroup v2, runsc (the gVisor runtime binary) on your PATH, Rust, and Node 22.12 or later for the web console.
git clone https://github.com/deeplethe/sandstorm
cd sandstorm
npm run build # builds the web console
cargo build --release
./target/release/sandstormd serve --master --node
The console opens at https://127.0.0.1:8080. Authenticate with the token from /var/lib/sandstorm/pki/api-token. Create a template from any container image, then start sandboxes through the UI or the HTTP REST API — everything the console does is also available via API.
When to Use Sandstorm (and When Not To) #
Sandstorm makes sense if your agent workloads are bursty — requests arrive in waves with long idle gaps between turns. The tiering gains disappear if sandboxes are under constant load. For bursty workloads, the density gains are dramatic.
It is not the right choice if you need an SLA or prefer to avoid operational burden. E2B, Daytona, and other managed providers are still the right answer for teams that want to pay for someone else’s on-call. v0.6 is recent — if the sandbox layer is revenue-critical, test in staging first and keep the managed sandbox bill as your fallback.
Bottom Line #
Sandstorm v0.6 is the most credible open-source answer to AI agent sandbox costs so far. The 34x density gain is real and the mechanism — checkpoint idle sandboxes, restore on demand — is not a trick. If you are spending thousands per month on managed sandboxes and your workloads are bursty, it is worth a weekend to test on a spare node.