The archive · Developer & Business Tools · Technical decision · 2026
Zeroboot bets AI agents get real KVM isolation at sub-millisecond fork cost
Zeroboot forks Firecracker VMs in ~0.8ms via copy-on-write, betting AI agents will treat sandboxed execution as a cheap function call
Zeroboot (zerobootdev)
What the business is
Zeroboot builds sandboxed code execution for AI agents: an open-source Rust engine that forks Firecracker microVMs from a copy-on-write memory snapshot (p50 spawn ~0.79ms, ~265KB per sandbox), plus a managed HTTP API that the author plans to run multi-region with usage-based pricing
How it started
Adam Miribyan built the engine as a working prototype in Rust on Firecracker and KVM, then posted Show HN on 2026-03-17. In the thread he described the fork engine as general purpose but aimed it at AI agents because that is where the demand is now: agent frameworks such as LangChain, CrewAI and OpenAI Assistants need sandboxed code execution as a tool call, and the existing options (E2B, Daytona, Modal) boot or restore a VM per execution.
What happened
The thread drew 311 points and 72 comments. Engineers compared the approach with CodeSandbox's microVM cloning and Cloud Hypervisor's userfaultfd work; Miribyan answered that single-node density is the near-term point — 1,000 concurrent sandboxes on one roughly $50 box — and that the API in the README was already live, with plans for a multi-region managed service, custom templates and usage-based pricing. The README benchmarks p50 spawn at 0.79ms against ~150ms (E2B), ~200ms (microsandbox) and ~27ms (Daytona), and lists honest limitations: single vCPU per fork, no networking inside forks (serial I/O only), snapshot-shared CSPRNG state, and a ~15s full re-snapshot for template updates.
No ending yet — it is still running.
Background
Zeroboot is an open-source infrastructure project, and early-stage startup, betting that AI agents will execute untrusted code in real virtual machines if doing so costs as little as a function call. Its Rust engine forks Firecracker microVMs from a copy-on-write memory snapshot: p50 spawn latency of 0.79ms and roughly 265KB of memory per sandbox, each a separate KVM VM with hardware-enforced memory isolation.
The mechanism is the bet: boot one template once, preload the runtime, snapshot memory and CPU state, then mmap(MAP_PRIVATE) to fork thousands of VMs. That makes speculative parallel execution practical — fork ten VMs, try ten approaches, keep the best — and turns code execution from an infrastructure decision into a cheap tool call, which is what agent frameworks such as LangChain, CrewAI and OpenAI Assistants need.
Show HN on 2026-03-17 drew 311 points and 72 comments, with engineers comparing the approach to CodeSandbox's microVM cloning and Cloud Hypervisor's userfaultfd work. The author answered that single-node density is the near-term point (1,000 concurrent sandboxes on one roughly $50 box) and that a managed API was already live, with plans for multi-region deployment, custom templates and usage-based pricing.
As of 2026-09-05 the repository shows 2.4k stars and 108 forks, and the README still labels the project a working prototype: the fork primitive, benchmarks and API are real but not production-hardened, with documented limits of one vCPU per fork, no in-fork networking, and a ~15s full re-snapshot on template updates.
What has to be true
- Existing agent sandboxes boot or restore a VM per execution at 100ms-plus, so treating code execution as a cheap call was impossible before the CoW fork made it ~0.8ms
- Aiming at AI agents despite a general-purpose engine rode the demand that exists now: every major agent framework needs sandboxed code execution as a tool call
- The mmap(MAP_PRIVATE) snapshot approach keeps hardware isolation while cutting memory per sandbox to ~265KB, making a thousand concurrent forks on one machine realistic
- Open-sourcing the core while building a managed API with usage-based pricing gives a wedge: developers try the fork primitive locally, then buy isolation as a service
What can be applied
A 100x latency drop changes the product category: when isolation costs less than a function call, the thing to sell is the behavior it unlocks — speculative parallel execution — not the benchmark
Aftermath
As of 2026-09-05 Zeroboot remains a working prototype: the README says the fork primitive, benchmarks and API are real but not production-hardened, and the managed service is in early access with a signup form rather than published pricing. The open-source repository (zerobootdev/zeroboot) shows 2.4k stars and 108 forks on the 2026-09-05 fetch. No funding, revenue, team size or customer names are disclosed in the sources.
Sources
spotted an error? The archive wants to know.
Your turn
You just read one. Describe what you are building, and see who is betting on the same thing.
Free account · 3 free questions · no card