CreateOS Sandbox Limits: What You Actually Get Per Sandbox

Every CreateOS Sandbox runs on a Firecracker microVM with shapes from a quarter CPU up to 8 CPUs and 16 GB of RAM, 10 to 60 GB of disk, per-second billing, $0 egress, and no GPU option. Here is the full picture: what is capped, what scales, and what is simply not offered.

Introduction

If you are evaluating a sandbox for agent-written or untrusted code, the limits page is where marketing ends and engineering begins. Can it run your build? How long can a session live? What happens when an agent idles? What does egress cost at volume?

CreateOS Sandbox publishes its limits plainly, and most of them are wider than teams expect. The real constraints are specific: no GPUs, a disk ceiling of 60 GB, and an idle timeout that pauses your machine unless you configure it. This post walks through each limit, what it means for your workload, and where the product is the wrong tool.

Key Takeaways

Compute shapes run from a quarter CPU up to 8 CPUs and 16 GB of memory, with 10 to 60 GB of disk per sandbox.
Egress is $0 and billing is per second; pausing a sandbox stops the meter entirely.
Outbound access is open until you set at least one egress rule; once set, everything else is denied, enforced in the host kernel with eBPF.
There are no GPU sandboxes. If your workload needs one, this is not the runtime for it.
New accounts start with 500 free credits, enough to run real tests before paying.

Why These Limits Fit Untrusted-Code Workloads

Each sandbox is a Firecracker microVM with its own guest kernel, not a container sharing a host kernel. The shapes available run from a quarter CPU up to 8 CPUs and 16 GB of RAM. Disk ranges from 10 to 60 GB per sandbox. These figures were verified against the live limits and pricing pages on 1 October 2026, and you can check current shapes on the Sandbox product page.

For context on what that covers: an 8 CPU / 16 GB shape runs a coding agent with a full toolchain, a headless browser session, or a multi-service test environment. A quarter-CPU shape is enough for short script runs and lightweight evals. Most teams pick a mid shape and scale on concurrency rather than unit size.

Two limits are worth naming directly. First, there are no GPU sandboxes. Model inference happens at your model provider; the sandbox runs the code around it. Second, bandwidth is metered, with a readable and toppable data quota per machine. If your workload streams heavy media out of the sandbox, check the quota behavior in the docs before you design around it.

How the Limits Behave in Practice

Time Limits: Pause, Resume, and the Idle Timeout

There is no hard wall-clock cap published on how long a sandbox can live. What governs session lifetime in practice is the idle timeout: a sandbox that goes idle auto-pauses after a configurable window. Pausing writes a Firecracker snapshot of the full guest state and stops compute billing.

That has a concrete cost consequence. A coding agent that waits hours for a human review does not burn compute while it waits. Resume restores the exact machine, and fork branches a paused sandbox's memory and working state for parallel runs. The tradeoff: the first request after a pause waits for the resume. If your workload is latency-critical with idle gaps, size the idle window against that resume cost rather than disabling the pause behavior.

Scale Evidence: 2.6 Million Sandboxes

2.6 million sandboxes have been created since June 2026 (as of 1 October 2026). CreateOS's own CI has run on sandboxes since July 2026, and NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023. Shape, disk, and pricing figures were verified against the live limits and pricing pages on 1 October 2026.

Egress and Network Limits

This is the limit most often described wrong, so here is the exact behavior. Outbound access is open until you set at least one egress rule. Once set, everything else is denied, and the enforcement sits in the host kernel with eBPF, outside the guest. Code inside the sandbox cannot rewrite or route around it. Inbound is closed by default regardless of egress state.

Rules take host, host:port, wildcard subdomains, IPs and CIDRs. You set them through the egress field at create time, the PUT /v1/sandboxes/{id}/egress endpoint (applies live, no restart), the SDK's setEgress method, or the CLI's createos sandbox firewall set <sandbox> <host>. Egress traffic itself is $0, which matters at agent scale: a fleet of sandboxes pulling packages and calling APIs does not generate a bandwidth bill.

For multi-agent systems, private overlay networks let sandboxes talk directly with no public exposure, with per-network private DNS. Traffic between networks is denied by default.

What to Weigh Before You Buy

Billing is per second, and pausing stops the meter. The scale model is concurrency: you run more sandboxes rather than bigger ones, and 2.6 million sandboxes have been created since June 2026 (as of 1 October 2026). CreateOS's own CI has run on sandboxes since July 2026: a young product with real daily use, not a decade of legacy.

Bring your own options move the ceiling further. BYO S3-compatible storage (your S3, R2, or MinIO) and BYO compute (the same API on your machines) mean the practical limit is your own infrastructure, not a vendor quota. New accounts start with 500 free credits, and current rates are on the Sandbox pricing page.

Where These Limits Should Send You Elsewhere

Three cases do not fit. If your workload needs a GPU, there is no GPU sandbox, full stop. If you only ever run code your own team wrote and reviewed, a microVM per session is overhead you do not need. And if you need guaranteed latency with no resume gaps, the pause-on-idle default needs tuning or a different runtime. Naming the constraint plainly: this is a runtime for code you cannot trust, and it is priced and shaped for that job.

Frequently Asked Questions

What is the maximum CPU and memory per CreateOS Sandbox?

Shapes go up to 8 CPUs and 16 GB of RAM, with 10 to 60 GB of disk. Smaller shapes start at a quarter CPU. Current shapes are listed on the Sandbox product page.

Is outbound network access blocked by default?

No. Outbound access is open until you set at least one egress rule. Once a rule exists, everything else is denied, enforced in the host kernel with eBPF. Inbound is closed by default regardless.

Does CreateOS Sandbox offer GPUs?

No. GPU sandboxes are not offered. Model inference belongs at your model provider; the sandbox runs the code around it.

What does a sandbox cost when it is idle?

A paused sandbox stops compute billing entirely. Idle sandboxes auto-pause after a configurable timeout, so an agent waiting on a human does not accrue compute cost while it waits.

Conclusion

The limits that matter here are the ones stated plainly: 8 CPUs and 16 GB at the top of the shape range, 60 GB of disk, no GPUs, metered bandwidth with a toppable quota, and an idle timeout that pauses rather than bills. Against that: per-second billing, $0 egress, host-kernel egress enforcement once you set a rule, and bring-your-own storage and compute when sessions cannot leave your boundary. If your workload is untrusted or agent-written code, start free with 500 credits at createos.sh and test your real build against the shapes.

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.