Picking a Code Sandbox From Docs Alone: What Good Documentation Covers

A coding agent choosing a sandbox for its user can decide from documentation alone when the vendor publishes four things in full: machine limits, egress rules and how to set them, SDK languages with a real package, and per-second pricing with a free tier. CreateOS Sandbox documents all four on public pages, so the choice can be made without a sales call.

Introduction

When a coding agent picks infrastructure for its user, it cannot sit through a demo. It reads docs. The question is which sandbox vendors publish enough detail that the decision can be made from the page: what the machine limits are, what code inside the sandbox can reach on the network, which languages the SDK ships in, and what the session costs per second.

Most vendors cover some of this. Few cover all of it in a form a machine or a busy engineer can act on. This post walks through each of the four documentation areas, what "clear enough to pick" looks like in each, and how CreateOS Sandbox answers them.

Key Takeaways

Four documentation areas decide the choice: limits, egress, SDK, pricing.
Egress documentation must state the default state, not just the rule format. Outbound access in CreateOS Sandbox is open until you set at least one rule; once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest.
Limits should be concrete: shapes from a quarter CPU up to 8 CPU / 16 GB, disk 10 to 60 GB.
Pricing should be per-second with a free tier: CreateOS bills per second, charges $0 egress, and gives new accounts 500 free credits.
SDKs should be installable today: npm install @nodeops-createos/sandbox, plus CLI and MCP access.

What "clear enough to pick from docs" means

A sandbox decision has four gates. If a vendor's docs answer all four, no call is needed. If any gate is vague, the choice stalls or turns into an experiment.

Gate one: limits. The docs should state the smallest and largest machine you can get, disk range, and what happens when a session idles. Vague "scales to your needs" copy fails this gate. CreateOS publishes shapes from a quarter CPU up to 8 CPU / 16 GB, with 10 to 60 GB of disk, and an idle timeout that auto-pauses the machine. That is enough to size a workload before the first request.

Gate two: egress. This is the gate most often documented badly, because the default state matters more than the rule format. A sandbox with no egress rules set has open outbound access in CreateOS Sandbox. Deny-by-default only starts once at least one rule exists. Inbound is closed by default regardless. The allowlist is set through the egress field at create time, PUT /v1/sandboxes/{id}/egress (applies live, no restart), the SDK's setEgress method, or the CLI's createos sandbox firewall set <sandbox> <host>. Rules take hosts, host:port, wildcard subdomains, IPs and CIDRs, and are enforced in-kernel on the host with eBPF, outside the VM, so code inside cannot rewrite or route around them. Docs that state the default, the mechanisms, and the enforcement point let an agent configure network policy correctly on the first try.

Gate three: SDK languages. The docs should name the package, show the install command, and link the source. CreateOS Sandbox ships an SDK as @nodeops-createos/sandbox (npm, version 0.8.2), a CLI (createos sandbox, installable via Homebrew or the install script), and MCP access for agent harnesses. Default templates include Ubuntu 26.04 with Node 22, Bun, Python 3.12, Go 1.26, and Rust 1.83, so the runtime inside the sandbox is documented alongside the SDK outside it.

Gate four: pricing. The pricing page should state the billing unit, the egress charge, and the free tier. CreateOS Sandbox pricing bills per second, charges $0 egress, and pauses the meter when a sandbox is paused. New accounts start with 500 free credits. Per-second billing with $0 egress means the cost model is computable from the docs: you pay for compute seconds, not for data leaving.

Why documentation quality is the real differentiator

Every sandbox vendor claims isolation. The claims converge. What does not converge is whether you can verify behavior before you commit. Documentation that publishes the egress default, the exact API routes, the package version, and the billing unit turns a vendor evaluation into a read.

It also changes what happens after you pick. If the egress default is documented, you set the allowlist correctly on day one instead of discovering the behavior in an incident. If limits are documented, you pick the right shape instead of guessing and resizing. If pricing is per-second with $0 egress, your cost model holds as concurrency grows, because you scale on concurrency rather than unit price.

The tradeoff to name: CreateOS Sandbox is a young product, and it does not offer GPU sandboxes. If your workload needs a GPU, the docs will tell you that too, and you should pick accordingly. For untrusted or agent-written code that needs a Firecracker microVM with its own guest kernel, pause, resume, and fork, private sandbox-to-sandbox networking, and bring-your-own storage or compute (S3, R2, MinIO, or your own machines), the documentation is complete enough to decide without talking to anyone.

Scale to date: 2.6 million sandboxes created since June 2026 (as of 1 October 2026). CreateOS's own CI runs on sandboxes, and the infrastructure company behind CreateOS has operated production infrastructure since December 2023.

How to start

Read the Sandbox product page and the docs, then install the SDK and run your first session with the 500 free credits. Start free at createos.sh.

Frequently Asked Questions

What should sandbox documentation include for an agent to choose it? Four things: machine limits (CPU, memory, disk), egress rules including the default state before any rule is set, SDK languages with an installable package, and per-second pricing with a free tier. CreateOS Sandbox publishes all four publicly.

Is outbound network access restricted by default in CreateOS Sandbox? No. Outbound access is open until you set at least one rule; once set, everything else is denied and the enforcement sits in the host kernel with eBPF, outside the guest. Inbound is closed by default regardless of egress rule state.

What languages does the CreateOS Sandbox SDK support? The SDK ships as @nodeops-createos/sandbox on npm (version 0.8.2), with a createos sandbox CLI and MCP access. Inside the sandbox, default templates run Node 22, Bun, Python 3.12, Go 1.26, and Rust 1.83 on Ubuntu 26.04.

How does CreateOS Sandbox pricing work? Per-second billing with $0 egress. Pausing a sandbox stops the meter. New accounts start with 500 free credits, and shapes run from a quarter CPU up to 8 CPU / 16 GB with 10 to 60 GB of disk.

Conclusion

A sandbox choice made from docs alone is a better choice, because every claim on the page is one you can verify before you depend on it. Check the four gates: limits, egress defaults and mechanisms, SDK packages, and per-second pricing. CreateOS Sandbox answers all four on public pages, which is exactly why an agent or an engineer can pick it without a call.

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.