agentOS
254× cheaper sandbox alternative, powered by WebAssembly
179 followers
254× cheaper sandbox alternative, powered by WebAssembly
179 followers
Give agents a Linux operating system as a library – no sandboxes, VMs, or SaaS. Built on WebAssembly, the same tech powering Cloudflare Workers and Chrome. Support Claude Code, Codex, OpenCode, Pi, Eve, and Flue.
Free
Launch Team
AWS Startup AdvisorPersonalized AWS guidance that meets you where you’re already building
Promoted
Hey PH, we built agentOS because every time we shipped agents to production we ended up rebuilding the same stack: code execution, file storage, orchestration, permissions, state that survives restarts. That usually means a sandbox provider, object storage, a workflow engine, and a lot of glue code.
agentOS packages this as a single library. Each agent gets its own lightweight virtual operating system running inside your existing backend process:
Execution: Node.js on native V8 (full JIT, not JS compiled to WASM), Python, Bash, and subprocesses with Linux-like semantics. The agent writes one program instead of chaining tool calls.
Filesystem: persistent POSIX filesystem. Mount S3, Google Drive, or host directories at normal paths and use regular files and shell tools.
Orchestration: durable workflows, crons, shared sessions, human-in-the-loop approvals, agent-to-agent. Written as normal application code, checkpointed automatically.
Control: expose typed backend functions to agents without handing over credentials, review permission requests in your own UI, cap resources per VM.
It runs on WebAssembly so it's small: ~4.8ms cold starts and ~22MB per agent instead of a dedicated VM per agent. If a workload needs something more, you can mount a sandbox.
Works with Claude Code, Codex, OpenCode, and Pi, or bring your own agent. Apache 2.0, one npm install, deploys wherever your backend already runs.
Happy to answer questions about the architecture.
@nicholas_kissel What does an approval actually authorize in agentOS? The exact function call and arguments, or a capability the agent can reuse later?
@nicholas_kissel @flavio_riper Flavio's question is the one I'd want answered before trusting the approval model. A capability the agent can reuse quietly turns one review into standing access, which is a very different thing to sign off on than a single call with fixed arguments. Exact call plus arguments only, re-approved every time, seems like the only version that keeps "approved" meaning what the human reviewing it actually thought they were agreeing to.
254x is doing a lot of work in that tagline and the number isn't anywhere in your comment, so say against what. Firecracker per agent-hour at list price is a different claim to a per-request one. Some of that saving is also the isolation boundary you removed, since in-process WASM means a bug in the host bridge lands inside my backend instead of in a VM I was already paying to throw away. I'd lead with 4.8ms and 22MB, those are checkable.
@asadmalik901 Hey! Appreciate the concern, happy to explain here:
The methodology is documented here and lines up with what devs using agentOS are seeing in production already.
This is not true, since agentOS uses process isolation from your backend and communicates over UDS. Process jailing is coming soon for a 3rd layer of security (WASM -> process -> jail).
microVMs are still vulnerable to 0-days, too. Januscape (CVE-2026-53359) impacted microVMs, while WebAssembly has not had a vulnerability like this.
Chrome & Cloudflare Workers use the same security model as agentOS.
@nathanflurry Fair on the process isolation, I read the page as in-process and that's on me. I'd still push on the Chrome and Workers comparison, because neither treats WASM as the boundary, both put an OS sandbox underneath it, which is the jailing you say is still coming. And no CVEs yet reads as young rather than safe.
Sounds interesting. How easy is it to install? Can I do it myself, or do I need an administrator?
@natalia_iankovych Hey! You can install it with npm and runs anywhere Node.js can run.
@nathanflurry — the UDS process-isolation answer is a lot more convincing than "trust the sandbox," and +1 to @rabnoor_s 's compatibility-page idea below — that's the first thing I'd go looking for too.
Curious about the 22MB-per-agent number at real scale: for a single Node backend process, is there a practical ceiling on concurrent agents before something contends — CPU, syscall dispatch, memory — or does it scale close to linearly until you hit host RAM?
On checkpointing — if the host process itself restarts or redeploys mid-workflow, does the durable workflow resume exactly where it left off, and where does that state actually live: local disk, or something external?
And for the Claude Code / Codex integrations specifically — is agentOS exposed as an MCP server any client could drive, or does each one need its own adapter? 👌
The number I would want next to 254x cheaper is what I give up to get it.
WebAssembly buys you the cold start and the cost, but it is a different syscall surface from a real container. Most agent work is not clever, it is shelling out: git, package managers, native modules, something that wants to fork a process or open a socket the way it always has. The interesting question is not whether the sandbox is fast. It is which of those quietly fails, and whether it fails loudly or just behaves oddly.
A compatibility page would do more for adoption than another benchmark. Here is what runs, here is what does not, here is what runs but slower. People building agent harnesses have been burned by "mostly compatible" before, and the ones who have will look for that page first.
Genuine question: when something is unsupported, does the agent get a clean error it can reason about and route around, or does it get something confusing? That difference decides whether an agent can recover on its own or just loops.
Really exciting release! I'm a big fan of the Rivet team and everything y'all put out. Looking forward to trying this out because we keep scaling the number of background agents and tasks but performance and compute is a huge pain point!
PS this team is ahead of the curve and open source. I even had a contribution merged in a day or two!
@welldundun Thanks Daniel! Excited to see what you build.
agentOS is 8 months the making building what we believe to be the future of secure agent isolation in a lightweight library.
We're excited to finally share this with you all!