The Fastest Sandbox To Spin Up For Short Bursts Of AI-Generated Code

For short bursts of agent-written code, use a sandbox that restores from snapshot instead of booting cold. CreateOS Sandbox restores a paused Firecracker microVM on the same host in under 0.7 seconds, and creates a new one in about 30 ms on an idle host (not an SLA). Per-second billing means a 90-second burst costs 90 seconds.

Introduction

AI-generated code arrives in bursts. An agent writes a patch, needs a machine to run it, runs it for a minute, then never touches that environment again. The infrastructure question is not "how big is the VM." It is "how fast can I get one, and what does an idle minute cost me."

Most options make you pay for the wrong thing. Cold container starts look cheap until every run pays the boot tax. Always-on VMs are fast but bill around the clock for work that lasts seconds. CreateOS resolves this with snapshots: a paused sandbox is a Firecracker snapshot of full guest state, memory plus disk, and a new sandbox restores that image instead of booting a kernel from scratch.

Key Takeaways

Snapshot restore, not cold boot: creating a sandbox from a snapshot takes about 30 ms on an idle host (not an SLA), and resuming a paused sandbox on the same host takes under 0.7 seconds.
Pause stops the billing: pausing writes a snapshot of full guest state in about 1.4 seconds and compute billing stops until you resume.
A real machine, not a namespace: each sandbox is a Firecracker microVM with its own guest kernel, so agent-written code runs in isolation by default.
Per-second billing and $0 egress mean a short burst costs what the burst costs, nothing more.
Start free with 500 credits and run your first burst in minutes.

Why This Solution Fits

Burst workloads need machine-level isolation and millisecond starts in the same product, and that combination is rare. CreateOS Sandbox gets its speed from snapshots, not from weaker isolation: every session is a Firecracker microVM with its own guest kernel. Pause stops compute billing, resume restores the exact machine, and fork branches state for parallel attempts. For agent loops that spin up short-lived environments all day, this is the fit.

Key Capabilities

Snapshot-based creation. Sandboxes are created from a snapshot restore. On an idle host, that is about 30 ms (an idle-host measurement, not an SLA). Your agent's run loop stops waiting on infrastructure.

Pause, resume, fork. Pausing writes a full guest-state snapshot in about 1.4 seconds and stops compute billing. Resume restores that exact machine. Fork branches a paused sandbox's memory and working state, so you can run N candidate fixes in parallel and keep the winner. For bursty agent work, this is the difference between one attempt and a search.

Isolation by default, not a setting you have to remember. Every sandbox is a Firecracker microVM with its own guest kernel. Inbound access is closed by default. Outbound access is open until you set at least one egress rule; once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. Code inside cannot rewrite or route around it.

Per-second billing and $0 egress. A 40-second burst bills 40 seconds. Egress is free, so an agent that pulls packages or uploads artifacts does not run up a network bill. Shapes run from a quarter CPU up to 8 CPU / 16 GB with 10 to 60 GB of disk, so a short script and a heavier build both fit.

Bring your own compute. The same API runs on customer machines when sessions need to stay inside your own boundary. Bring your own bucket (S3, R2, MinIO) for snapshots and artifacts.

Proof & Evidence

Scale and runtime proof, dated: 2.6 million sandboxes created since June 2026 (as of 1 October 2026). CreateOS's own CI has run on sandboxes since July 2026, so the platform eats its own cooking on every build. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

Speed claims, with their qualifiers: about 30 ms sandbox creation on an idle host (not an SLA), pause in about 1.4 seconds, same-host resume under 0.7 seconds, cross-host cold start 11 to 13 seconds. These are the only latency figures we publish, and we publish the qualifier with each one because an idle-host p50 is not a promise about your p99.

You can verify the mechanics yourself: the Sandbox product page covers the architecture, the docs show the API and SDK, and pricing lists the shapes and the 500 free credits.

Buyer Considerations

Your burst profile. If sessions come back repeatedly, snapshot locality matters: same-host resume is sub-second, cross-host cold start is 11 to 13 seconds. If sessions are truly one-shot, creation speed matters more than resume.
Egress policy. Outbound is open until you set a rule. If your agent handles untrusted code, set the allowlist at create time via the egress field, the PUT /v1/sandboxes/{id}/egress endpoint, the SDK's setEgress, or the CLI. Rules take hosts, ports, wildcards, IPs and CIDRs.
Idle behavior. Pause on idle is on by default at thirty minutes. The tradeoff is direct: the first request after a pause waits for the resume. Do not set the idle window longer to avoid this; the resume is fast and the pause is what stops the billing.
Where the data lives. Bring your own bucket and bring your own compute cover teams with residency requirements. Wherever compliance comes up: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.
Maturity, stated plainly. This is a young product with real runtime proof: millions of sandboxes, our own CI on the platform, SDK examples across agent frameworks. We say what is young and what is proven rather than reaching for maturity labels.

Frequently Asked Questions

How fast can I actually create a sandbox?

About 30 ms on an idle host, from snapshot restore rather than a cold boot. That figure is an idle-host measurement, not an SLA. Cross-host cold starts run 11 to 13 seconds, and same-host resume of a paused sandbox takes under 0.7 seconds.

What does a short burst cost?

Billing is per second, and egress is $0. A burst that runs 45 seconds bills 45 seconds of compute at your shape's rate. Pausing stops compute billing entirely. Start free with 500 credits to measure your own pattern.

Is a fast sandbox still isolated enough for untrusted AI code?

Yes, because speed comes from snapshots, not from weaker isolation. Each sandbox is a Firecracker microVM with its own guest kernel. Inbound is closed by default, and once you set an egress rule, the allowlist is enforced in the host kernel with eBPF, outside the guest, where compromised code cannot touch it.

Can I fork a sandbox mid-run to try multiple fixes?

Fork works on a paused sandbox: it branches the memory and disk snapshot into parallel copies, each resuming independently. Run N candidate patches at once, keep the one that passes, and discard the rest without paying for them again.

Conclusion

Short bursts of AI-generated code need a machine that appears in milliseconds, isolates like a real VM, and bills only while it exists. Snapshot restore gets you the milliseconds. Firecracker gets you the isolation. Per-second billing and pause-on-idle get you the cost model. The combination is what CreateOS Sandbox ships, and 2.6 million sandboxes created since June 2026 (as of 1 October 2026) say it holds up at volume.

Start free with 500 credits at createos.sh/products/sandbox and time your first burst yourself.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.