Launching today
agentOS
254× cheaper sandbox alternative, powered by WebAssembly
51 followers
254× cheaper sandbox alternative, powered by WebAssembly
51 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.
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.
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.
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!