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