CreateOS Sandbox: A Firecracker Micro-VM for Every AI Agent

CreateOS launched Sandbox on Product Hunt yesterday, a service that gives each AI agent its own Firecracker micro-VM with a dedicated Linux kernel. The pitch is simple: stop sharing kernels between trusted and untrusted code. Give every agent a computer of its own.

The CreateOS Sandbox launches a micro-VM in roughly 30 milliseconds at the 90th percentile. That is fast enough for an agent to provision its own compute through a tool call, run a command, read the output, and tear the whole thing down. The SDK ships for TypeScript, the CLI, and MCP, so agents can call sandboxes like they call any other tool.

This is not another shared-kernel container. The difference matters.

The isolation argument

Most code-execution sandboxes for AI agents run inside containers that share the host kernel. Docker, Podman, even gVisor’s application-layer kernel all share the same underlying Linux kernel with the host. A container escape is a kernel exploit away from the host. Firecracker, the open-source micro-VM manager that AWS built for Lambda and Fargate, runs each workload as its own minimal virtual machine with its own kernel. There is no shared kernel to escape.

CreateOS Sandbox doubles down on this. Each sandbox gets its own guest kernel. Egress is an allowlist enforced in the kernel via eBPF outside the VM. Ingress is blocked by default. The code inside a sandbox cannot rewrite or route around the egress policy because the policy lives in the host kernel, not the guest. If an agent’s model-generated code tries to phone home to a command-and-control server, the host kernel drops the packet before it leaves.

The company is explicit about what this means for regulated teams. SOC 2, HIPAA, GDPR, and ISO certifications are on the roadmap, not yet held. During alpha, self-hosting the control plane and storage in your own environment is the interim control. That is honest. Many sandbox providers wave certification logos but skip the discussion of what happens when a guest kernel is compromised. CreateOS publishes a page on failure modes: what happens when untrusted code OOMs, loops, or tries to phone home.

The economics of pause-to-zero

The pricing model is worth attention. Per-second billing at $0.0504 per vCPU-hour plus $0.0162 per GiB-RAM-hour. Networking is unmetered. Egress is free. Pause a sandbox and compute billing stops.

Pause is not a shutdown. It is a Firecracker snapshot: guest memory, vCPU registers, and device state serialized to disk. Resume restores that exact state into a fresh micro-VM. Processes, open file descriptors, and memory come back exactly as they were. An agent that was mid-task when it hit an inactivity timeout resumes in place with no cold boot and no setup to re-run.

This is the kind of billing model that makes sense for agentic workloads. Agents spend most of their time waiting: waiting for an API response, waiting for a user to approve an action, waiting for another agent in the swarm to finish its task. With pause-to-zero, those idle periods cost nothing. The state persists. The agent wakes up where it left off.

CreateOS publishes its pricing comparison with E2B, Daytona, and Modal. The reference rate is the same. The differentiator is the isolation model and the pause-to-zero mechanism, not the raw compute price.

What this means for AI builders

The agent ecosystem has a trust problem. Every framework that gives an agent a shell, a browser, or a file system is asking the developer to trust that the model will not generate catastrophic code. Models hallucinate. They write infinite loops. They try to exfiltrate data. They attempt privilege escalation. The standard response has been to run agents in containers and hope the container boundary holds.

CreateOS Sandbox replaces hope with hardware. The micro-VM boundary is not perfect — no isolation is — but it is a materially different threat model from shared-kernel containers. A kernel exploit inside the guest compromises only that guest. It does not reach the host or other tenants.

For teams building agentic systems that execute untrusted code, this changes the calculus. You can give an agent a full Linux environment, install dependencies, run arbitrary binaries, and tear it down without worrying about what the model might have left behind. The egress allowlist means you can restrict what the agent can reach on the network. The fork feature lets you branch a running sandbox into parallel rollouts and keep the winner.

The self-host option matters for enterprises. Regulated teams can run the control plane and storage in their own cloud, mount their own S3 or MinIO buckets, and keep code, snapshots, and data inside their own boundary. The certifications will come. The architecture is real now.

The open question

CreateOS Sandbox is in alpha. The architecture is working. The SDK, CLI, and MCP integration are live. The question is whether the developer experience can match the isolation story. A 30-millisecond micro-VM launch is impressive, but agent workflows often need dozens or hundreds of sandboxes. The control plane needs to scale. The snapshot storage needs to be fast. The networking between sandboxes needs to be reliable.

The company is hiring design partners. That is the right move. The teams that need hardware-level isolation for agentic code are the teams that will push the product to its limits. The ones running model-generated code in production, not just prototyping in a notebook.

Every agent gets its own computer. The question is whether the computer is fast enough, cheap enough, and reliable enough to run at scale. The alpha will tell.