In-Process Agent VMs That Boot in 6ms

·https://github.com/rivet-dev/agent-os
repoaiinfrastructureagent-loopstypescriptwebassemblysandboxorchestration

Direct competition to joelclaw's Firecracker microVM substrate — same problem (cheap fast agent isolation) solved with V8 isolates + WASM instead of full VMs, directly relevant to the CascadiaJS talk on agent infrastructure

agentOS from Rivet is a portable, open-source operating system for AI agents built on V8 isolates and WebAssembly — no VMs, no containers, no cold start penalty. You install it as an npm package and agents start in ~6ms, compared to 440ms+ for something like E2B.

The architecture is genuinely interesting. Rather than spinning up a Linux environment, agentOS runs a JavaScript-implemented OS kernel inside your process. POSIX utilities (coreutils, grep, sed, curl) are compiled to WASM. Agent code runs in sandboxed V8 isolates. The kernel manages a virtual filesystem, process table, pipes, PTYs, and a virtual network stack. Nothing executes on the host — it’s all inside the kernel abstraction.

The memory numbers are what make this practically relevant. A full coding agent with Pi + MCP + filesystem uses ~131 MB vs ~1,024 MB for a Daytona sandbox minimum. At scale on Hetzner ARM, that works out to roughly $0.0000011/second — about 17x cheaper than sandbox providers. For workloads that need actual Linux environments (browsers, native compilation), they have a sandbox extension that pairs with E2B or Daytona on demand.

The multi-agent orchestration story is solid: agent-to-agent delegation through host-defined tools, multiplayer sessions where multiple clients observe the same agent, durable workflows with retries and resumable execution. It uses the Agent Communication Protocol (ACP) for session management. Supported agents right now: Pi and Claude Code, with Codex, Amp, and OpenCode listed as coming soon.

For the CascadiaJS talk — this is a direct point of comparison to the Firecracker microVM substrate in the joelclaw workload rig. Firecracker gets ~9ms snapshot restore; agentOS claims 4.8ms p50 cold starts. Different tradeoff surface (full Linux VM vs in-process WASM kernel), but the headline numbers are close enough to be worth explaining clearly to a conference audience about why you’d choose one vs the other.

Key Ideas

  • In-process kernel: No VMs, no containers — the OS primitives (filesystem, process table, pipes, network) are implemented in JavaScript and run inside your Node/Bun process
  • WASM for POSIX utilities: Coreutils, grep, sed, curl etc. compiled to WebAssembly and mounted into the kernel — no native binaries needed
  • V8 isolates for agent code: Same isolation technology browsers use; deny-by-default permissions for filesystem, network, and process access
  • Host tools: Define JS functions that agents call as CLI commands inside the VM — agents can call your backend directly with no network hop
  • 6ms cold starts vs 440ms: The benchmark gap between in-process isolates and full Linux sandboxes at p50; 516x faster at p99
  • ~131 MB per full agent: vs ~1,024 MB minimum for a sandbox — 8x smaller for a Pi + MCP + filesystem workload
  • Sandbox extension when needed: Pair with E2B or Daytona for workloads that genuinely need full Linux (browsers, native compilation)
  • Universal transcript format: One format across all supported agents for debugging and comparison
  • Durable workflows built in: Retries, branching, resumable execution — similar problem space to Restate but in the agent substrate layer
  • Apache 2.0, self-hostable: Or use Rivet Cloud for managed infrastructure
  • Turbo monorepo + Rust crates: The repo uses Turbo for the TypeScript packages and Cargo workspaces for the Rust/WASM compilation layer — same monorepo shape as joelclaw

Links

← All discoveries