Rivet launches agentOS beta with 6.1 ms cold starts and WASM agents

• Rivet's new agentOS launch thread positions runtime design as the real product: agents run inside your backend process with WebAssembly and V8 isolates, not as separate containers or remote sandboxes launch thread.
• The headline numbers are aggressive, and specific: 6.1 ms p99 cold starts, about 131 MB for a full coding agent, and 32x lower execution cost than the cheapest mainstream sandbox in Rivet's comparison set benchmark claims.
• The most useful engineering idea here is the file-system abstraction. agentOS mounts S3, SQLite, Google Drive, and host files as directories, while the host keeps credential scope and secrets outside the agent filesystem model.
• Rivet is also shipping more than a sandbox replacement. The beta bundles orchestration primitives like queues, webhooks, durable workflows, multiplayer sessions, and agent-to-agent delegation into the runtime itself orchestration list.
• The open-source angle matters because this is pitched as portable infrastructure, not a hosted control plane. Rivet says the same npm-based stack runs on laptops, Vercel, Lambda, Kubernetes, or a Raspberry Pi deployment claims.

The quick read: the product page and GitHub repo make agentOS look less like another agent framework and more like an attempt to collapse sandboxing, session management, storage mounts, and workflow plumbing into one local runtime. The weirdly important detail is that Rivet is targeting existing coding agents, including Pi first and Claude Code, Codex, Amp, and OpenCode next supported agents. The benchmark page is thin, but the repo adds the missing caveat: those comparisons are against the fastest or cheapest mainstream sandbox providers as of March 2026, not against every possible isolation strategy or every self-hosted setup benchmark methodology.

The biggest release here is not the cold start chart. It is the deployment model. Rivet wants agents to run where your application code already lives, so tools become direct function calls and auth stays inside your existing backend boundary.

That is a meaningful shift from the usual agent stack, where execution jumps over a network boundary into a sandbox product, then back again into app services. The repo quickstart shows exactly that posture: create an AgentOs instance, start a Pi session, stream events, prompt it, then read files back from the VM. For teams already fighting tool latency, auth sprawl, and cross-service tracing, that is the pitch that matters most.

The numbers are designed to make one point: traditional sandboxes make you pay for a lot of environment before the agent does useful work. Rivet says agentOS avoids that by booting a lightweight VM inside the host process rather than provisioning a full Linux environment.

The GitHub README adds a bit more context than the launch thread. It says the cold start benchmark used 10,000 runs on an Intel i7-12700KF, with E2B as the cold start baseline, and Daytona as the memory and price baseline for the cheapest mainstream sandbox comparison GitHub README. The benchmark page still needs more detail, especially if engineers want to compare apples to apples on noisy-neighbor behavior, persistence, and browser workloads. But the underlying argument is strong: if your agent mostly edits files, calls tools, and runs short commands, full sandbox environments can be expensive overkill.

The cleanest idea in this release is the storage interface. agentOS turns external systems into directories. That means agents can work with S3 objects, SQLite data, cloud drives, or host files using the same file-based patterns that coding agents already expect.

Rivet also claims the host owns credential scoping, so the agent reads and writes files without ever handling the raw API keys. That is a practical security improvement, not a marketing flourish. A lot of agent systems still hand credentials straight into the runtime and then hope tool wrappers behave.

The repo broadens this into a general host-tools model: JavaScript functions can appear to the agent as CLI commands inside the VM GitHub repo. Combined with mounted filesystems, that gives teams a way to expose internal capabilities without rebuilding their whole backend around agent-native protocols.

Rivet is leaning hard on the browser analogy. Chrome-style isolation, programmatic network allowlists, per-agent CPU and memory limits, isolated network namespaces, and bring-your-own auth are the security frame in both the launch thread and the product page.

The important extra detail is in the repo text: permissions are deny-by-default across filesystem, network, process, and environment access GitHub repo. That is the right default for agent infrastructure. Most agent failures in production come from broad capability surfaces, not from missing one more abstraction layer.

There is also a subtle product choice here. Rivet is not pretending lightweight agent VMs replace full sandboxes for every workload. The README explicitly says agentOS can pair with full sandboxes through an extension when you need browsers, native binaries, or heavier environments GitHub repo. That makes the launch more credible.

The beta is trying to absorb a pile of glue code that teams usually assemble themselves:

• webhooks for external triggers
• queues for backpressure
• durable workflows with retries
• persistent SQLite for structured state
• multiplayer sessions so multiple clients can observe one agent
• agent-to-agent delegation for task splitting

That bundle matters because most agent platforms still split execution, workflow state, event intake, and collaboration across separate products. Rivet is arguing those pieces belong together, closer to the runtime. If it works, teams get a smaller failure surface. If it does not, agentOS risks becoming too opinionated for shops that already standardized on Temporal, bespoke queues, or external orchestration stacks.

Rivet is clearly targeting adoption through compatibility rather than by asking developers to learn a new agent style from scratch. The launch page says Pi works now, with Claude Code, Codex, OpenCode, and Amp marked as coming soon product page. That is smart positioning. The distribution problem in agent tooling is getting developers to move their current workflows, not persuading them to start over.

Open source helps here too. The repository is under Apache 2.0, and the same codebase is pitched as runnable across local machines and mainstream cloud targets GitHub repo. The real story here is that agent infrastructure is starting to split into two camps: remote sandboxes that look like hosted dev environments, and local runtimes that look more like embedded operating systems for agents. agentOS is one of the clearest statements yet for the second model.