Sub-millisecond VM sandboxes for AI agents via copy-on-write forking

curl -X POST https://api.zeroboot.dev/v1/exec \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer zb_demo_hn2026' \
  -d '{"code":"import numpy as np; print(np.random.rand(3))"}'

Each sandbox is a real KVM virtual machine with hardware-enforced memory isolation.

  Firecracker snapshot ──► mmap(MAP_PRIVATE) ──► KVM VM + restored CPU state
                              (copy-on-write)         (~0.8ms)

1. Template (one-time): Firecracker boots a VM, pre-loads your runtime, and snapshots memory + CPU state
2. Fork (~0.8ms): Creates a new KVM VM, maps snapshot memory as CoW, restores all CPU state
3. Isolation: Each fork is a separate KVM VM with hardware-enforced memory isolation

Python — sdk/python

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

TypeScript — sdk/node

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

• API Reference
• Deployment Guide
• Architecture

Zeroboot was created in March 2026 and is maintained by Adam Miribyan (@adammiribyan). Project site: zeroboot.dev.

If you use zeroboot in research, please cite it; see CITATION.cff or use the "Cite this repository" button.

• DeltaBox: Scaling Stateful AI Agents with Millisecond-Level Sandbox Checkpoint/Rollback, arXiv:2605.22781 (May 2026).
• Memory Compression for High-Fanout Agent Sandboxes (AgentZip), arXiv:2609.11294 (September 2026).

If your paper or project uses zeroboot, open an issue or pull request to add it here.

Working prototype. The fork primitive, benchmarks, and API are real, but not production-hardened yet. Open an issue if you're interested.

Zeroboot is open source. Self-host it on any Linux box with KVM, or use the managed API:

curl -X POST https://api.zeroboot.dev/v1/exec \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer zb_demo_hn2026' \
  -d '{"code":"import numpy as np; print(np.random.rand(3))"}'

Building the managed service for teams that don't want to run their own infra. Sign up for early access: https://tally.so/r/aQGkpb

• Forks share CSPRNG state from the snapshot. Kernel entropy is reseeded via RNDADDENTROPY but userspace PRNGs (numpy, OpenSSL) need explicit reseeding per fork. See Firecracker's guidance.
• Single vCPU per fork. Multi-vCPU is architecturally possible but not implemented.
• No networking inside forks. Sandboxes communicate via serial I/O only.
• Template updates require a full re-snapshot (~15s). No incremental patching.

Apache-2.0