Rivet launches agentOS beta with 6.1 ms cold starts
Rivet introduced agentOS, an embedded agent runtime built on WASM and V8 isolates with backend embedding, mounted filesystems, and built-in orchestration. If you run agents in production, compare it against separate sandbox infrastructure.

TL;DR
- Rivet launched agentOS, an open source agent runtime that runs inside your backend process instead of a separate VM or container layer, built on WebAssembly and V8 isolates launch thread embedded runtime.
- Rivet says agentOS hits 6.1 ms p99 cold starts, about 131 MB per coding agent, and $0.00000058 per execution-second on AWS on-demand, with benchmark methodology published alongside the claims benchmark claims.
- The core abstraction is filesystem mounting: agents can work against S3, SQLite, Google Drive, and the host filesystem as directories, while the host keeps credential scoping out of the agent runtime filesystem mounts.
- Rivet is packaging security and orchestration into the runtime itself, including CPU and memory limits, network allowlists, isolated network namespaces, webhooks, queues, retries, and agent-to-agent delegation security model orchestration.
- The beta is already framed as a portability play: one npm package, open source on GitHub, and a product page that lists Pi support now with Claude Code, Codex, OpenCode, and Amp marked coming soon portability GitHub link.
You can read the product page, browse the repo, and Rivet even published separate docs for Security & Auth and Persistence & Sleep. The oddest reveal is how much of the pitch is about deleting infrastructure: no sidecar, no Kubernetes operator, and no per-agent credentials for mounted systems embedded runtime filesystem mounts.
In-process runtime
Rivet's main bet is architectural, not cosmetic. agentOS runs agents inside the host process, using WebAssembly and V8 isolates instead of booting full sandboxes for each run.
The GitHub README and product page describe the same trade: near-zero startup time and direct access to host functions, without the network hops and duplicate auth layers that come with external sandbox infrastructure.
Benchmark numbers
Rivet published three headline numbers in the launch thread, then linked a dedicated benchmarks page for methodology.
- Cold start, p99: 6.1 ms versus 3,150 ms for the fastest compared sandbox
- Memory per coding agent: about 131 MB versus about 1,024 MB minimum
- Cost per execution-second: $0.00000058 versus $0.000018 for the cheapest mainstream sandbox
The docs say these figures come from the same data source used on the marketing page, and point readers to ComputeSDK benchmarks for an independent comparison set.
Filesystems and host tools
The strongest product idea here is filesystem-first access. Instead of teaching agents a different integration shape for every data source, Rivet mounts systems as directories and lets the host handle secrets.
That model bundles a few concrete claims:
- S3 buckets can be mounted as filesystems
- SQLite databases can be mounted the same way
- Google Drive and the host filesystem fit the same interface
- Agents read and write files, while the host owns credential scoping
The agentOS page pairs that with host tools, Git access, and session APIs. The result looks less like a hosted coding sandbox and more like a local runtime abstraction you can wire straight into an existing backend.
Security and orchestration
Rivet is also shipping the control plane inside the runtime. The launch thread lists the guardrails and coordination features as first-party primitives, not bolt-ons.
Security controls called out in the thread and Security & Auth docs include:
- Per-agent CPU and memory caps
- Programmatic network allowlists
- Isolated network namespaces
- Bring-your-own auth, including API keys, OAuth, and JWTs
- Deny-by-default filesystem and network permissions, according to the docs
Orchestration features listed in the thread:
- Webhooks for external events
- Multiplayer sessions, where multiple clients observe one agent
- Agent-to-agent delegation
- Durable workflows with retries
- Queues for backpressure
- Persistent SQLite for structured state
The docs go a step further than the tweet thread and show agent-to-agent communication as a host-tool pattern, not a magic built-in protocol, in the Agent-to-Agent Communication guide.
Persistence and portability
The launch thread ends with portability, but the more interesting documentation detail is lifecycle. Rivet's Persistence & Sleep page says /home/user is backed by a persistent filesystem, session transcripts are stored with sequence numbers for replay, and sleeping sessions get a 15-minute grace period by default before the VM kernel state is dropped.
According to the docs, these survive sleep: files in /home/user, session records, session event history, preview URL tokens, and cron definitions. Running processes, active shells, and in-memory mounts do not. Wake-up can happen automatically when a client reconnects or a cron job fires, which makes agentOS look less like a stateless sandbox and more like a resumable agent host.