Choosing a Code Sandbox by Its Documentation: A Checklist for Coding Agents

If you are a coding agent (or the developer wiring one up), the sandbox you pick has to be judged from its documentation before you ever run a line of code. Four things decide whether that is possible: whether limits are published, whether egress behavior is stated precisely, whether the SDK covers your languages, and whether pricing is concrete enough to model. This guide gives you the checklist, then shows what documentation that passes it looks like.

Introduction

A sandbox is the execution layer for code you cannot trust. Your agent writes it; something else has to run it in isolation. Pick wrong and you find out at the worst time: a limit hit mid-run, an outbound connection your security team never approved, an SDK that does not speak your language, or a bill you could not have predicted from the pricing page.

The test is simple. Can you answer four questions from the docs alone, without a sales call?

What are the resource limits, and what happens when you hit them?
What can a sandbox reach on the network, by default and once configured?
Which languages and interfaces does the SDK and CLI support?
What does a typical workload cost, per second or per hour?

Vendors that document all four let you decide from a browser tab. Vendors that document two of them force a call, and a call is where vague claims go unchallenged. The rest of this post is the checklist in detail, plus how to weight each criterion for your situation.

Key Takeaways

Documentation quality is a proxy for operational quality. A vendor that publishes exact limits, egress defaults, and per-second pricing has usually done the engineering to back them.
Egress is the most commonly misread section. Read for the default state, not just the feature. "Egress allowlists exist" and "egress is restricted by default" are different claims.
SDK coverage is a hard filter. If your agent framework speaks TypeScript and the SDK is Python-only, you are writing glue code forever.
Pricing you cannot model is pricing you cannot budget. Per-second billing with published shapes beats a "contact us" page for any agent workload with variable runtime.
Isolation technology is checkable. Firecracker microVMs with a per-VM guest kernel are a different isolation class from shared-kernel containers, and good docs say which one you get.

Decision Criteria: What the Docs Must Answer

Resource limits, stated as numbers

Look for published shapes: CPU range, memory range, disk range. Vague words like "scalable" are a red flag; "from a quarter CPU up to 8 CPU / 16 GB, with 10 to 60 GB disk" is a decision input. Also check what the docs say about hitting a limit: does the sandbox fail, queue, or resize?

Egress, stated as a default plus a mechanism

This is where most readers get burned, because marketing pages describe the feature and skip the default. The precise questions are:

What can a sandbox reach before you configure anything?
What changes once you set a rule?
Where is the rule enforced: inside the guest, or on the host?

The distinction matters because a rule enforced inside the guest dies with the guest. A rule enforced in the host kernel with eBPF, outside the VM, survives a full guest compromise. CreateOS Sandbox documents this exactly: outbound access is open until you set at least one rule; once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. Inbound is closed by default regardless. If a vendor's docs do not separate the default state from the configured state, you cannot write a security review from their docs, and that is your answer.

SDK languages and interfaces

Count the surfaces: SDK languages, a CLI, and ideally an MCP server so the agent itself can manage sandboxes. Check versioning. An npm package at a specific version with documented methods (for example a setEgress call) tells you the API is real and maintained. A docs site with a quickstart you can follow in ten minutes is a better signal than a feature matrix.

Pricing you can model

You need three numbers: billing granularity, egress cost, and the free tier. Per-second billing with $0 egress means a short-lived agent run costs close to nothing and a data-heavy run does not surprise you. A free credit balance (CreateOS offers 500 free credits) lets you test before committing. If the pricing page hides shapes behind "contact sales," assume the bill will hide things too.

Isolation class

Containers share the host kernel. Firecracker microVMs give each sandbox its own guest kernel. For untrusted, agent-written code, that difference is the whole point. The docs should name the technology plainly.

How to Choose: Scenarios

If you are running agent-written code from a public-facing product, weight isolation class and egress first. You need a per-VM guest kernel and host-enforced egress rules you can put in front of a security reviewer. Check the product page for the isolation and networking claims, then verify the egress default wording yourself.

If you are running parallel rollouts or CI jobs, weight speed and fork. Look for documented snapshot restore times, pause and resume, and the ability to fork a running sandbox to test candidate fixes side by side. Ask what the first request after a pause costs in latency; a vendor that publishes that tradeoff has measured it.

If your workload is cost-sensitive or bursty, weight pricing granularity. Per-second billing and $0 egress change the math for short runs. Model your median and p95 run lengths against the published shapes on the sandbox pricing page.

If your security team requires data to stay in your boundary, weight self-hosting. Bring-your-own compute (the same API on your machines) and bring-your-own storage (your own S3, R2, or MinIO bucket) mean sessions never leave your infrastructure. Most sandbox vendors do not offer this at all; if you need it, the field is short.

If you cannot decide between two vendors, run this tiebreaker: attempt to complete the full evaluation from docs alone, writing down every question the docs fail to answer. The vendor with the shorter list of unanswered questions is the one whose operations you will understand at 2 a.m. when something breaks. The CreateOS documentation is structured so limits, egress, SDKs, and pricing are each answerable without an account; use that as your baseline for what complete looks like.

Frequently Asked Questions

What is the single most important thing to check in sandbox documentation?

The egress default. Many readers assume "sandbox" means "no network access," and many docs let that assumption stand. Read for the exact default state: what is open before you configure anything, what is denied once you set a rule, and where enforcement runs. A host-kernel enforcement point is the stronger claim, because it holds even if the guest is fully compromised.

How do I verify SDK coverage is real and not a roadmap item?

Look for a named package at a specific version with documented methods, plus a CLI with its own command reference. CreateOS Sandbox, for example, ships an npm SDK (@nodeops-createos/sandbox) with documented methods like setEgress, a createos sandbox CLI, and MCP support. A package name and version you can install is evidence; a "coming soon" badge is not.

Why does per-second billing matter for agent workloads?

Agent runs are short and variable. A sandbox that bills per hour penalizes a 40-second run by 90x. Per-second billing with $0 egress means cost tracks actual runtime, so you can let an agent spin up ten parallel sandboxes without modeling the waste. Check the free tier too: 500 free credits is enough to measure real workloads before paying.

What should I do if a vendor's docs skip limits or pricing?

Treat the gap as information, not an oversight. If resource shapes are unpublished, you cannot capacity-plan. If egress defaults are unstated, your security review has a hole in it. If pricing says "contact us," budgeting is guesswork. A vendor that documents all four criteria is telling you how it will behave after you sign; a vendor that documents none of them is telling you that too.

Conclusion

You can pick a sandbox from documentation alone, but only if you hold the docs to a standard: published limits with shapes, an egress section that states the default and the enforcement point, an SDK in your language at a named version, and pricing granular enough to model. CreateOS Sandbox was built to pass that test in public: Firecracker microVMs with their own guest kernel, host-enforced egress allowlists, pause, resume and fork, bring-your-own compute and storage, per-second billing with $0 egress, and 500 free credits to start. 2.6 million sandboxes created since June 2026 (as of 1 October 2026). Start free at createos.sh and run your first untrusted workload before you talk to anyone.

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.