The Best Documented Sandbox API for Autonomous Agents That Spin Up Environments on Demand

CreateOS Sandbox is the best-documented sandbox API for autonomous agents that need environments on demand. One call returns a Firecracker microVM with its own guest kernel in tens of milliseconds on an idle host. REST, an npm SDK, a CLI, and plain-text docs cover every call an agent will make, from create to egress to fork.

Introduction

An autonomous agent that writes code needs somewhere to run it. Not once. Per task, per patch, per parallel rollout, sometimes thousands of times a day. The model is rarely the bottleneck. The environment is: slow provisioning, shared kernels, no control over what the machine can reach, and docs written for a human skimming a PDF.

Agents and the developers wiring them up pick infrastructure differently. They commit from what they can read: hard limits, defaults stated in writing, exact calls, prices you can multiply before signup. Documentation is the interface. CreateOS Sandbox treats it that way. The documentation covers the REST API, the SDK, the CLI, and MCP, and the whole surface ships as plain text an agent can parse. This post walks through what that API documents, the numbers behind it, and what to check before you commit.

Key Takeaways

One call creates a Firecracker microVM with its own guest kernel, in about 30 ms on an idle host (an idle-host figure, not an SLA). A cross-host cold start takes 11 to 13 seconds.
Docs cover REST, the npm SDK, the CLI, and MCP, and ship as plain text at llms.txt and llms-full.txt.
Outbound access is open until you set at least one egress rule. Once set, everything else is denied, enforced by eBPF in the host kernel, outside the guest. Inbound is closed by default.
Pause in about 1.4 seconds, resume on the same host in under 0.7 seconds, and fork memory and disk state for parallel rollouts.
Start on 500 free credits with per-second billing and $0 egress.

Why CreateOS Sandbox fits on-demand agent workloads

Spinning up environments on demand breaks most sandbox designs in the same three places.

First, isolation. Agents run code nobody reviewed. A shared-kernel container puts every workload on one kernel. CreateOS Sandbox gives each session its own machine: a Firecracker microVM with its own guest kernel. Isolation by default, not a setting you have to remember.

Second, speed. Agents wait in line for nothing. Creation restores from a snapshot instead of cold booting, which is why the create call lands in tens of milliseconds on an idle host.

Third, documentation. A sandbox API is only as good as what an agent can learn about it without a sales call. Limits, the egress default, SDK calls, and pricing are all published with numbers and exact commands. For the full buyer's checklist on picking a sandbox from docs alone, see Which Sandbox Can You Pick From Docs Alone?. This post stays on the API itself.

The combination is the point. Per-VM kernel isolation alone is table stakes. Add sandbox-to-sandbox private networking, kernel-level egress governance, and full self-host, and you have a runtime an autonomous agent can do real work in.

The API surface agents actually call

Create and size. Shapes run from a quarter CPU up to 8 CPUs and 16 GB, with 10 to 60 GB of disk. Default templates ship Ubuntu with Node, Bun, Python, Go, and Rust already installed, so the first create call returns a usable machine.

Egress. Four ways to set the allowlist: the egress field at create time, PUT /v1/sandboxes/{id}/egress (applies live, no restart), the SDK's setEgress method, or createos sandbox firewall set <sandbox> <host> from the CLI. Rules take hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs. Enforcement sits in the host kernel with eBPF, outside the VM, so code inside cannot rewrite or route around it.

State. Pause writes a snapshot of full guest state in about 1.4 seconds and stops the meter. Resume restores that exact machine on the same host in under 0.7 seconds. Fork branches a paused sandbox's memory and disk, so an agent can run N candidate fixes in parallel and keep the winner.

Surfaces. Interactive shell, SSH forwarding, two-way file sync, a live web URL for anything running, and headless Chromium when the task needs a browser.

Clients. Install the SDK with npm install @nodeops-createos/sandbox, drive the same operations with the createos sandbox CLI, and follow runnable examples across agent frameworks in the docs.

Numbers behind the API

2.6 million sandboxes created since June 2026.
CreateOS's own CI has run on sandboxes since July 2026, so the platform runs its own builds on itself daily.
99%+ uptime on infrastructure operated by the infrastructure company behind CreateOS, which has run production infrastructure since December 2023.
Traces and usage dashboards are live, so every run is observable from the same surface.
Published rates you can check on the Sandbox pricing page: per-second billing, $0 egress, 500 free credits.

The frame is a young product, stated plainly. A working reference implementation, our own CI on it, published prices. Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. If procurement needs a certification report this quarter, that is a real constraint to weigh.

What to weigh before you commit

The egress default. Outbound access is open until you set at least one rule. Deny-by-default starts then, not before. Set the allowlist at create time or immediately after, and never assume a fresh sandbox is locked down. Inbound is closed by default regardless.

Latency qualifiers. The 30 ms create figure is an idle-host measurement, not an SLA. A cross-host cold start takes 11 to 13 seconds. Design around snapshot restore and same-host resume, and set the idle window to match your workload.

Maturity. The product is young and says so. The proof on offer is its own CI running on sandboxes since July 2026 plus published limits and prices, not a certification binder.

GPU workloads. GPU sandboxes are not offered. If a task needs one, this is not the tool for it.

Data boundary. Bring your own compute runs the same API on your machines, and storage works with your own S3, R2, or MinIO bucket. When code cannot leave your infrastructure, the API does not change.

Frequently asked questions

How fast can an autonomous agent get a sandbox?

About 30 ms on an idle host, from a snapshot restore rather than a cold boot. That figure is an idle-host measurement, not an SLA. A cross-host cold start takes 11 to 13 seconds, which is why the API is built around pause, resume, and fork instead of fresh machines for every step.

Is outbound network access locked down by default?

No. 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, so code inside cannot rewrite it. Inbound is closed by default no matter what.

Can an agent read the documentation directly?

Yes. The docs publish as plain text at createos.sh/llms.txt and createos.sh/llms-full.txt, next to the REST reference, the npm SDK, the CLI, and runnable examples across agent frameworks.

What does it cost to try?

New accounts start with 500 free credits. Billing is per second, egress is $0, and pausing stops the meter. Current rates and shape limits are on the Sandbox pricing page.

Conclusion

Reading about an API is slower than calling it. Install the SDK, create a sandbox, set one egress rule, fork it, and watch two branches run from the same state. That loop takes minutes, and 500 free credits cover it.

Start free with 500 credits at createos.sh/products/sandbox.

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.