Rivet Agent OS: The In-Process OS That Runs AI Agents 500x Cheaper Than Sandboxes

Rivet Agent OS: The In-Process OS That Runs AI Agents 500x Cheaper Than Sandboxes

lschvn9 min read

We were running full Linux virtual machines to run AI agents. Then someone realized we had been doing it wrong.

For the past two years, the standard answer to "how do you run a coding agent securely?" has been: spin up a cloud VM, boot Linux, start a shell session, run your agent. E2B. Daytona. Modal. Every agent framework defaulted to the same mental model as deploying a web server, a full operating system, a full filesystem, syscalls going to a real kernel, all for an agent that spends 95% of its time waiting for an LLM to respond.

Rivet's answer is different. Much different.

What Is agentOS?

agentOS is an in-process operating system kernel written in JavaScript, running inside a Node.js host process. That's not marketing language, it's a precise description of the architecture.

The kernel manages:

  • A virtual filesystem with mount drivers (S3, SQLite, host directories, in-memory)
  • A process table tracking child processes, PIDs, exit codes
  • Pipes and PTYs for inter-process communication
  • A virtual network stack with programmable allow/deny/proxy rules

Into this kernel, three runtimes are mounted:

1. V8 isolates for agent code. The agent (Pi, Claude Code, Codex, coming soon) runs in a V8 JavaScript context. This is the same isolation technology Chrome uses to sandbox every browser tab. Each isolate has its own heap and stack, no shared state, deny-by-default permissions for filesystem, network, and process access. Cold start is ~4–6ms because you're not booting anything, you're just creating a new JavaScript context inside an already-running V8 engine.

2. WebAssembly for POSIX utilities. GNU coreutils, grep, sed, gawk, curl, jq, ripgrep, sqlite3, and 80+ other Unix commands compiled from C and Rust to WebAssembly. They run in a WASM runtime managed by the kernel, not in V8. The agent talks to them over a virtual PTY, just like a shell.

3. Sandbox extension for heavy workloads. When you genuinely need a real browser, native Linux binaries, or GPU access, agentOS can mount an E2B or Daytona sandbox on demand and expose it as part of the virtual filesystem tree. This is the hybrid model: lightweight fast agents for the 80% of tasks that don't need a full OS, full sandboxes when you do.

Host Tools: The Integration Pattern That Matters

The "host tools" model is agentOS's most underrated feature. Your backend exposes JavaScript functions to the agent as if they were CLI commands:

const weatherToolkit = toolKit({
  name: "weather",
  tools: {
    get: hostTool({
      description: "Get weather for a city.",
      inputSchema: z.object({ city: z.string() }),
      execute: async ({ city }) => ({ temperature: 18, conditions: "partly cloudy" }),
    }),
  },
});

The agent calls agentos-weather get --city London. No HTTP. No auth headers. No network hop. The kernel bridges directly to your Node.js function. This is the right model for backend integration.

ACP: LSP for Agents

The Agent Communication Protocol (ACP) is a standardized protocol for editor-agent communication, modeled explicitly on how the Language Server Protocol (LSP) decoupled language servers from IDEs. ACP defines sessions, transcripts, reconnection logic, and universal agent formats. If it wins, agents become portable across editors (Cursor, VS Code, etc.) and editors gain access to the full ACP agent ecosystem. The parallel to LSP is apt: it took a decade for LSP to win despite being obviously right. ACP is early.

The Numbers

All benchmarks below are from Rivet's own materials. The secure-exec library benchmarks (the most granular layer) are independently reproducible, Rivet publishes the scripts. Everything else is self-reported.

PercentileagentOSE2B (fastest sandbox)Speedup
Cold start p504.8 ms440 ms92x
Cold start p955.6 ms950 ms170x
Cold start p996.1 ms3,150 ms516x

Memory per instance: ~131MB (full coding agent) vs ~1,024MB (Daytona). Simple shell: ~22MB vs ~1GB.

Self-hosted cost on Hetzner ARM: $0.0000011/second. Compare that to Daytona at $0.0504/vCPU-hour: 17x cheaper. At full self-hosted utilization, the economics are in a different league.

These are the self-hosted numbers. Rivet Cloud starts at $20/month for the managed tier.

Competitive Landscape

agentOS is not competing with Modal (serverless GPU, a different problem), and it's not really competing with E2B or Daytona, it's designed to complement them. The sandbox mounting extension makes the relationship explicit: you use agentOS for lightweight work, spin up a sandbox when you need one.

Real competition: Lambda (poor fit for agents, 100ms+ cold starts, no agent primitives, 15-minute execution limits), Cloudflare Workers AI (inference only, not an agent runtime).

Primary buyer: Backend and platform engineers at startups building AI agent features who need fast, cheap, embeddable agent infrastructure inside their Node.js backend. Not solo developers (though the free Apache 2.0 tier is real), and not enterprises needing HIPAA or SOC 2, agentOS doesn't have those certifications yet.

The Company

Rivet Gaming, Inc., YC W23 + a16z Speedrun SR002 backed. Founders Nathan Flurry and Nicholas Kissel. Flurry previously built infrastructure for games serving 15M+ MAU and 20k concurrent players. The game-server DNA shows: this is infrastructure thinking applied to agents, cost at scale, fast execution, minimal overhead.

The foundational sandboxing library, secure-exec, is open source separately. Rivet Cloud offers managed hosting (free 100k actor-hours/month, paid from $20/month). YC and a16z Speedrun companies get 50% off for 12 months.

Implications

If agentOS delivers on its numbers at scale, every sandbox provider faces pressure. The execution substrate for a simple agent task, file operations, API calls, scripting, can drop from roughly $0.05/vCPU-minute to $0.0000011/second. That's a 500x cost reduction for the runtime, not the LLM.

For OpenClaw, Hermes, and every agent framework: the V8 isolate + virtual FS architecture is the thing to watch. Even if you don't adopt agentOS directly, the "host tools" pattern (direct function calls, no HTTP auth), the actor-per-session model, and the hybrid sandbox approach are architectural ideas worth absorbing.

ACP vs MCP is a separate and longer-running battle. MCP has the mindshare. ACP is architecturally cleaner. The LSP parallel is worth remembering, the right answer doesn't always win on day one.

Caveats

This is beta. Only the Pi agent is production-ready today; Claude Code, Codex, OpenCode, and Amp are listed as coming soon. No third-party security audit has been published. The WASM POSIX layer is partial, git and make are planned but not shipped. GitHub has 1,576 stars, which is modest. The architecture is sound; the ecosystem is nascent.

The image that opens this article is a circuit board. It felt appropriate: agentOS is infrastructure for people who care about what's under the hood.

Frequently Asked Questions

Related articles

More coverage with overlapping topics and tags.

Claude Code Issue #74066: Users Report Cross-Workspace Context Bleed on Sonnet 5, Anthropic Has Not Yet Responded
security

Claude Code Issue #74066: Users Report Cross-Workspace Context Bleed on Sonnet 5, Anthropic Has Not Yet Responded

An open bug filed against Claude Code on 2026-07-04 by an [Enterprise ZDR](https://docs.anthropic.com/en/docs/build-with-claude/zero-data-retention) user describes a working session on Sonnet 5 that suddenly starts referencing an unrelated Minecraft temple build, then doubles down on the wrong task in its recap. The reporter (GitHub: [@milesrichardson-edb](https://github.com/milesrichardson-edb), issue [anthropics/claude-code#74066](https://github.com/anthropics/claude-code/issues/74066)) is on Enterprise Zero Data Retention, the tier Anthropic specifically advertises as session-isolated. Triage on the reporter's local session JSONL at `~/.claude/projects/<encoded-cwd>/<session-id>.jsonl` finds the leaked text is not in the transcript, ruling out a local context bleed by file overlap. Four other users in the comments (with work histories going back to last year) describe near-identical behavior across Claude Code, Claude Mobile, and Claude deep research. The most plausible architectural fit is shared KV-cache state in inference ([per @yv3nne in the comments](https://github.com/anthropics/claude-code/issues/74066#issuecomment-4880448776)), but no Anthropic engineer has commented on the issue in the 22 hours since it was filed, and the issue reached the top of [Hacker News](https://news.ycombinator.com/item?id=42481789) on 2026-07-04. The tone in the thread is split: half suspecting a real platform cache reuse, half suspecting a [sonnet-5-specific hallucination triggered by a Pygments lexer](https://github.com/anthropics/claude-code/issues/74066#issuecomment-4880334711). Both readings are credible.
Fastify v5.9.0 Adds `request.mediaType` and `onMaxParamLength`, Hardens `forwarded` Header Trust, Chunks Large HTTP/2 Replies, and Moves Type Tests to TSTyche
security

Fastify v5.9.0 Adds `request.mediaType` and `onMaxParamLength`, Hardens `forwarded` Header Trust, Chunks Large HTTP/2 Replies, and Moves Type Tests to TSTyche

Fastify v5.9.0, published on 2026-06-28 (github.com/fastify/fastify), is the first minor release of the v5 line in 2026 and a substantial 65-PR cycle. The headline features are `request.mediaType` (a typed accessor for the negotiated media type, [#6653](https://github.com/fastify/fastify/pull/6653) by climba03003), `onMaxParamLength` route option ([#6716](https://github.com/fastify/fastify/pull/6716) by climba03003), and a security fix that no longer trusts `X-Forwarded-Host` and `X-Forwarded-Proto` when the incoming socket is missing ([#6684](https://github.com/fastify/fastify/pull/6684) by mcollina). The cycle ships an HTTP/2 buffer-chunking fix for large replies ([#6746](https://github.com/fastify/fastify/pull/6746) by mcollina), three schema-related performance wins (deferred `getSchemaSerializer` content-type parsing #6692, cached `ContentType` objects in `ContentTypeParser` #6694, `typeof` guard before `toString.call` in `send` / `onSendEnd` #6693 by aquie00t), Node.js 26 added to the test matrix ([#6728](https://github.com/fastify/fastify/pull/6728) by Fdawgs) and Node.js 20 dropped from the yarn CI matrix ([#6662](https://github.com/fastify/fastify/pull/6662) by Tony133), the migration of the type-test suite from hand-rolled `expect-type` to [TSTyche](https://github.com/mrazauskas/tstyche) ([#6532](https://github.com/fastify/fastify/pull/6532) by mrazauskas, with follow-ups #6726 and #6727), and a TypeScript-only fastify-plugin v6.0.0 bump. Other notable fixes: trailer `res.end` deduplication (#6676), trailer duplicate-completion guard (#6714), `error.code` on routing errors (#6678), `hasRequestDecorator` / `hasReplyDecorator` catching constructor-assigned built-ins (#6753), `getValidationFunction()` allowed to return `undefined` (#6665), and a socket `_meta` clear that closes a keep-alive leak (#6799).
Deno 2.9 Ships 1.98x Faster Cold Start, 2.2-3.1x Less RSS Under Load, Default-On npm Minimum Release Age, No-Downgrade Trust Policy, and Built-In Snapshot Testing
runtimes

Deno 2.9 Ships 1.98x Faster Cold Start, 2.2-3.1x Less RSS Under Load, Default-On npm Minimum Release Age, No-Downgrade Trust Policy, and Built-In Snapshot Testing

Deno 2.9 (Bartek Iwańczuk, published 2026-06-25 on deno.com/blog/v2.9) is the largest Deno release of the cycle. Cold start drops from 34.2 ms to 17.3 ms (1.98x), peak RSS on the Deno.serve realworld workload drops 2.2x (142 MB → 64 MB) and 3.1x on 1 MiB bodies (197 MB → 63 MB), and Deno.serve throughput climbs 1.27x realworld (56.8k → 72.4k req/s), 1.11x plaintext, and 1.18x on 1 MiB bodies. Supply chain hardening: npm minimum-release-age is enabled by default with a 24h window (PR #35458), and a new opt-in no-downgrade trust policy (PR #34927) refuses to resolve any version whose trust evidence (staged publish, trusted publishing, provenance attestation) is weaker than the strongest evidence on any earlier-published version of the same package. Test runner parity: built-in t.assertSnapshot() (#35139), Deno.test.each (#34938), --shard for CI fan-out (#35057), retry and repeats (#35053), change-aware --changed and --related (#35199), and coverage thresholds (#35056). Lockfile interop: deno install seeds deno.lock from package-lock.json, pnpm-lock.yaml, yarn.lock, or bun.lock (#34296, #35330, #35346, #35350, #35394), pnpm-workspace.yaml auto-migrates to deno.json / package.json (#34993), and git merge conflict markers in deno.lock auto-resolve (#34726). Plus: deno desktop graduates from experimental (the June 16 PR #33441), deno link / deno unlink / deno list / deno watch subcommands, stable --unsafe-proto (#34738), Web Locks API (#31166), Happy Eyeballs v2 (RFC 8305) (#31726), navigator.userAgentData (#34743), the WebCrypto Modern Algorithms proposal (ML-KEM, ML-DSA, SLH-DSA, ChaCha20-Poly1305, SHA-3 family, KMAC, Argon2) (#34447, #34448, #34914, #35223), Node 26.3.0 compat (#34746, #34747), Node-API v10 (#35270), and CSS module imports under --unstable-raw-imports (#35093). 165+ PRs land in this cycle.

Comments

Log in Log in to join the conversation.

No comments yet. Be the first to share your thoughts.