Show HN: zeroboot Promises Sub-Millisecond KVM Sandboxes for AI Agents

What zeroboot is trying to fix for agent infrastructure

A March 17, 2026 Show HN post introduced zeroboot, a sandbox system aimed squarely at AI-agent workloads. The Hacker News thread reached 303 points and 69 comments at crawl time, which is notable for a low-level infrastructure project. The reason is practical: as code agents and tool-using assistants become more autonomous, the cost of spinning up isolated execution environments starts to matter as much as the model call itself.

Zeroboot’s pitch is unusually direct. Instead of offering “container-like” isolation, it says each sandbox is a real KVM virtual machine with hardware-enforced memory isolation. The project uses a Firecracker-based template VM, snapshots memory and CPU state once, then creates new sandboxes by mapping snapshot memory as copy-on-write and restoring the saved state. In the README, the reported result is around 0.79 ms p50 spawn latency, 1.74 ms p99, roughly 265 KB of memory per sandbox, and about 8 ms for a fork-plus-exec Python path.

Why the benchmark table matters

The benchmark comparisons in the README are the main attention hook. Zeroboot compares itself with E2B, microsandbox, and Daytona, claiming lower startup latency and much smaller memory overhead. It also reports completing 1,000 concurrent forks in 815 ms. Those numbers are project-reported and the repository explicitly says the system is still a working prototype rather than a production-hardened service, so they should be treated as directional. Still, even as directional numbers, they point to a real infrastructure problem: agent systems often need secure short-lived execution far more frequently than traditional VM workflows ever did.

How the design differs from simpler sandboxes

The interesting architectural point is the combination of speed and isolation model. Containers are fast but share a kernel. Full virtual machines isolate better but are usually slower to start. Zeroboot is arguing that snapshot forking can narrow that tradeoff enough for agent workloads, especially when the same language runtime needs to be reused repeatedly. The project also exposes Python and TypeScript SDKs, and it offers both self-hosting and a managed API path.

The limitations section is as important as the benchmarks. The README notes shared CSPRNG state unless userspace libraries reseed, a single-vCPU design, no networking inside forks, and a full re-snapshot requirement for template updates. Those caveats make it clear that this is not a drop-in replacement for every secure execution problem. But for code agents that mostly need quick, isolated local computation, the architecture is compelling enough to explain the HN interest.

Primary source: zeroboot README. Community discussion: Hacker News.