zeroboot

Sub-Millisekunden-VM-Sandboxes für KI-Agenten mittels Copy-on-Write-Forking

---

Ausprobieren

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))"}'

Benchmarks

Metrik	Zeroboot	E2B	microsandbox	Daytona
Spawn-Latenz p50	0,79ms	~150ms	~200ms	~27ms
Spawn-Latenz p99	1,74ms	~300ms	~400ms	~90ms
Speicher pro Sandbox	~265KB	~128MB	~50MB	~50MB
Fork + exec (Python)	~8ms	-	-	-
1000 gleichzeitige Forks	815ms	-	-	-

Jede Sandbox ist eine echte KVM-virtuelle Maschine mit hardwaregestützter Speicherisolation.

Funktionsweise

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

1. Template (einmalig): Firecracker startet eine VM, lädt Ihre Runtime vor und erstellt einen Snapshot des Speicher- und CPU-Zustands
2. Fork (~0,8 ms): Erstellt eine neue KVM-VM, bildet den Snapshot-Speicher als CoW ab und stellt den gesamten CPU-Zustand wieder her
3. Isolation: Jeder Fork ist eine separate KVM-VM mit hardwaregestützter Speicherisolation

SDKs

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)");

Docs

• API-Referenz
• Bereitstellungsleitfaden
• Architektur

Autor

Zeroboot wurde im März 2026 erstellt und wird von Adam Miribyan (@adammiribyan) gepflegt. Projektseite: zeroboot.dev.

Wenn Sie zeroboot in der Forschung verwenden, zitieren Sie es bitte; siehe CITATION.cff oder verwenden Sie die Schaltfläche „Cite this repository“.

Zitiert von

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

Wenn Ihr Paper oder Projekt zeroboot verwendet, eröffnen Sie ein Issue oder einen Pull Request, um es hier hinzuzufügen.

Status

Funktionierender Prototyp. Das Fork-Primitiv, die Benchmarks und die API sind real, aber noch nicht für den Produktionseinsatz gehärtet. Eröffnen Sie ein Issue, wenn Sie interessiert sind.

Selbst hosten oder verwaltet

Zeroboot ist Open Source. Hosten Sie es selbst auf jeder Linux-Maschine mit KVM oder nutzen Sie die verwaltete 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))"}'

Wir bauen den verwalteten Dienst für Teams, die ihre eigene Infrastruktur nicht betreiben möchten. Melden Sie sich für Early Access an: https://tally.so/r/aQGkpb

Bekannte Einschränkungen

• Forks teilen den CSPRNG-Zustand aus dem Snapshot. Kernel-Entropie wird über RNDADDENTROPY neu geseedet, aber Userspace-PRNGs (numpy, OpenSSL) müssen pro Fork explizit neu geseedet werden. Siehe Firecrackers Anleitung.
• Eine vCPU pro Fork. Mehrere vCPUs sind architektonisch möglich, aber nicht implementiert.
• Kein Netzwerk innerhalb von Forks. Sandboxes kommunizieren ausschließlich über serielle E/A.
• Template-Aktualisierungen erfordern einen vollständigen neuen Snapshot (~15s). Kein inkrementelles Patchen.

Lizenz

Apache-2.0