Zeroboot

Overview

Zeroboot takes a radically different approach to AI agent sandboxes: instead of booting VMs or starting containers, it forks them. A Firecracker microVM boots once, pre-loads a runtime (Python, Node, etc.), and snapshots its entire memory and CPU state. Each new sandbox is created by mapping that snapshot as copy-on-write memory and restoring CPU state into a new KVM VM — in 0.79ms.

Key stats: 1,135 stars, Apache-2.0, Rust. Created March 15, 2026. Working prototype, not production-hardened.

Attribute	Value
Stars	1,135
License	Apache-2.0
Language	Rust
Created	March 2026
Spawn latency (p50)	0.79ms
Spawn latency (p99)	1.74ms
Memory per sandbox	~265KB
Isolation	KVM hardware-enforced
Category	AI Agent Sandboxes

---

How It Works

The architecture is elegantly simple:

1. Template (one-time, ~15s): Firecracker boots a VM, pre-loads your runtime and dependencies, snapshots memory + CPU state to disk
2. Fork (~0.8ms): Creates a new KVM VM, maps snapshot memory as MAP_PRIVATE (copy-on-write), restores all CPU registers
3. Execute: Fork runs agent code in complete isolation — separate KVM VM with hardware-enforced memory boundaries
4. Teardown: Fork is destroyed, CoW pages are freed

The key insight: most sandbox time is spent booting and loading runtimes. By snapshotting after boot and forking the result, Zeroboot eliminates that cost entirely. Each fork starts with a fully-initialized Python/Node environment ready to execute.

Benchmarks vs. Competitors

Metric	Zeroboot	E2B	microsandbox	Daytona
Spawn p50	0.79ms	~150ms	~200ms	~27ms
Spawn p99	1.74ms	~300ms	~400ms	~90ms
Memory/sandbox	~265KB	~128MB	~50MB	~50MB
Fork + exec (Python)	~8ms	—	—	—
1,000 concurrent forks	815ms	—	—	—

The memory numbers are the real story. At ~265KB per sandbox vs ~128MB for E2B, Zeroboot can run ~480x more sandboxes on the same hardware. This enables patterns that are economically impossible with traditional approaches — like forking a sandbox per function call or running thousands of concurrent agent evaluations.

---

SDKs

Python and TypeScript SDKs are available:

Python:

from zeroboot import Sandbox
sb = Sandbox("zb_live_your_key")
result = sb.run("print(1 + 1)")

TypeScript:

import { Sandbox } from "@zeroboot/sdk";
const result = await new Sandbox("zb_live_your_key").run("console.log(1+1)");

A managed API is available at api.zeroboot.dev with a demo key, plus early access signup for teams.

---

Known Limitations

The project is transparent about its constraints:

• CSPRNG reseeding: Forks share CSPRNG state from the snapshot. Kernel entropy is reseeded but userspace PRNGs (numpy, OpenSSL) need explicit reseeding per fork
• Single vCPU: Each fork gets one vCPU. Multi-vCPU is architecturally possible but not implemented
• No networking: Sandboxes communicate via serial I/O only — no outbound network access
• Template updates: Require full re-snapshot (~15s), no incremental patching
• Not production-hardened: Explicitly a working prototype

The no-networking constraint is notable — it makes Zeroboot ideal for pure computation (code execution, data processing) but unsuitable for agents that need to call APIs or fetch URLs from within the sandbox.

---

Competitive Position

Zeroboot enters the AI agent sandboxes market with a fundamentally different architecture. While E2B and Sprites use Firecracker for isolation, they still boot or restore full VMs. Zeroboot's CoW fork approach trades flexibility (no networking, single vCPU) for extreme speed and density.

The closest architectural parallel is Unix fork() — but applied to entire virtual machines instead of processes. This is a research-grade insight that could reshape how high-throughput agent workloads run.

Best for: Batch code execution, agent evaluation at scale, compute-heavy workloads that need massive concurrency with real isolation.

Not for: Agents that need network access, long-running sessions, or multi-core compute.

---

Strengths

• 190x faster spawns than the market leader (E2B) with real VM isolation
• ~480x memory density enables patterns impossible with traditional sandboxes
• Rust implementation with clean architecture and honest documentation
• Apache-2.0 license — fully open source, self-hostable
• Managed API available for teams that don't want to run infrastructure

Weaknesses

• No networking — major limitation for many agent use cases
• Single vCPU — can't parallelize within a sandbox
• Working prototype — not production-hardened, unclear roadmap
• 5 days old — extremely early, no production users disclosed
• Template re-snapshot takes ~15s, limiting rapid iteration on environments

---

Bottom Line

Zeroboot is the fastest sandbox runtime in the AI agent ecosystem by a wide margin — 0.79ms spawn latency with real KVM isolation is a genuine breakthrough. The CoW fork architecture is elegant and the benchmarks are impressive. But it is a week-old prototype with significant limitations (no networking, single vCPU). For teams running batch agent evaluations or high-throughput code execution where networking isn't needed, it is worth watching closely. For general-purpose agent sandboxing, E2B and Sprites remain the practical choices.