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.
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.
254x cheaper sandbox is wild 🔥 does it hold up for long running agent jobs?
@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!
Sounds interesting. How easy is it to install? Can I do it myself, or do I need an administrator?
Nathan and team are creating something beautiful. Been keeping my eyes on AgentOS and super cool it works with Eve and/or Flue
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!
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.
About agentOS on Product Hunt
“254× cheaper sandbox alternative, powered by WebAssembly”
agentOS launched on Product Hunt on July 30th, 2026 and earned 158 upvotes and 16 comments, placing #10 on the daily leaderboard. 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.
agentOS was featured in Open Source (68.7k followers), Developer Tools (517k followers), Artificial Intelligence (475.2k followers) and GitHub (41.3k followers) on Product Hunt. Together, these topics include over 230k products, making this a competitive space to launch in.
Who hunted agentOS?
agentOS was hunted by Nicholas Kissel. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Want to see how agentOS stacked up against nearby launches in real time? Check out the live launch dashboard for upvote speed charts, proximity comparisons, and more analytics.
Nicholas Kissel
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.