Why CreateOS Sandbox Has No Egress Fees for Agent Workloads

Agent workloads move data constantly, and most cloud pricing meters every outbound byte. CreateOS Sandbox takes a different position: $0 egress, per-second billing, and a Firecracker microVM with its own guest kernel for every run. Here is what that buys you, and what to check before you commit.

Introduction

An agent run is a burst of network activity. It clones a repository, installs dependencies, pulls model context, pushes artifacts, and streams logs back to your orchestrator. Multiply that by fan-out runs, parallel rollouts, CI jobs, and retries. Outbound traffic becomes one of the fastest-growing lines on your infrastructure bill.

Egress pricing punishes the workloads that succeed. The more agents you run, the more you pay for the network they use. CreateOS Sandbox was built against that model. It runs untrusted or agent-written code in Firecracker microVMs, bills per second, and charges nothing for egress.

Key Takeaways

Egress is free. Outbound traffic on CreateOS Sandbox costs $0, so agent networking stops scaling your bill.
Isolation is on by default, not a setting you have to remember. Every sandbox is a Firecracker microVM with its own guest kernel, not a container on a shared host.
Cost and control are separate dials. 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.
You pay per second for shapes from a quarter CPU up to 8 CPUs and 16 GB of memory, with 10 to 60 GB of disk.
500 free credits cover your first runs.

Why a sandbox with no egress fees fits agent workloads

Agent platforms pay twice: once to the model provider, once to the infrastructure. The first bill is set by your model choices. The second is a design decision. When egress is metered, every product win raises it. More runs, bigger artifacts, richer telemetry, more parallel rollouts. Success carries a bandwidth tax.

Forking multiplies the pattern. Fork a running sandbox and you branch its state with a memory and disk snapshot, so you can test candidate fixes side by side. Under metered egress, every branch pays to pull the same dependencies and push the same artifacts. At $0 egress, fan-out is an architectural choice, not a pricing decision.

The result is predictable unit economics. Your bill tracks compute seconds, not bandwidth. Cost per agent run becomes a number you can model, not a line you discover at invoice time.

Key Capabilities

Isolation that holds under compromise. Each sandbox is a Firecracker microVM with its own guest kernel. Not a container, not a namespace on a shared host. That kernel boundary is what makes the egress policy enforceable.

Egress governance, enforced on the host. The allowlist is set by you and enforced in the host kernel with eBPF, outside the VM, so it survives a full guest compromise. Rules accept hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs. Set them in the egress field at create time, apply them live with PUT /v1/sandboxes/{id}/egress and no restart, call setEgress in the SDK, or run createos sandbox firewall set from the CLI. The CreateOS docs cover each mechanism.

Pricing that follows usage. $0 egress and per-second billing. Shapes run from a quarter CPU up to 8 CPUs and 16 GB of memory, with 10 to 60 GB of disk. Current rates are on the sandbox pricing page.

Session control for agent loops. Pause stops the meter and takes about 1.4 seconds. Same-host resume returns in under 0.7 seconds. Fork branches a running sandbox's memory and disk for parallel rollouts.

Your boundary, your data. Bring your own bucket works with S3, R2, and MinIO. Bring your own compute runs the same API on your machines, so sessions that must stay on your infrastructure can.

Proof & Evidence

$0 egress, per-second billing, and 500 free credits, published on the pricing page.
2.6 million sandboxes created since June 2026.
CreateOS's own CI has run on sandboxes since July 2026, with 99%+ uptime.
Sandboxes restore from snapshot in tens of milliseconds, about 30 ms on an idle host. That figure is an idle-host measurement, not an SLA.
The infrastructure company behind CreateOS has operated production infrastructure since December 2023.

The young-product frame applies, and the next section states it plainly. What is proven today: the API, the isolation boundary, the egress enforcement, and daily CI on the same infrastructure.

What to check before you commit

Ask how egress is priced, in writing. Free should mean free, with no caps, tiers, or throttling in the fine print. If a provider quotes a per-gigabyte rate after some threshold, model your peak month against it.

Check the default, not the brochure. Isolation is on by default. Egress restriction is not: outbound access is open until you set at least one rule. If your threat model needs deny-by-default, set the allowlist at create time. It applies immediately and updates live without a restart.

Match isolation to your threat model. A microVM with its own guest kernel and a container are different answers to a compromised guest. Ask which one you are buying.

Know what is young and what is proven. CreateOS Sandbox is a young product. The usable proofs are its own CI on sandboxes since July 2026, plus the GitHub Actions runner and the coding-agent plugin that run on the same API. Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. If procurement needs one today, raise it early.

Budget for cross-host moves. Same-host resume returns in under 0.7 seconds. A cold start on a different host takes 11 to 13 seconds. If your orchestrator reschedules sandboxes across hosts, plan for the wait. For the full docs-only evaluation checklist, see which sandbox you can pick from docs alone.

Frequently asked questions

Does CreateOS Sandbox really charge $0 for egress?

Yes. Outbound traffic is free. Billing is per second on the compute shape you choose, from a quarter CPU up to 8 CPUs and 16 GB of memory, with 10 to 60 GB of disk. Current rates are on the sandbox pricing page.

If egress is open by default, how do I control where agents connect?

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, so code inside the sandbox cannot rewrite or route around it. Set rules in the egress field at create time, apply them live with PUT /v1/sandboxes/{id}/egress, call setEgress in the SDK, or use the createos sandbox firewall set CLI command. Inbound is closed by default regardless.

What does a typical agent run cost?

Billing is per second by shape, so a short run pays only for the seconds it uses, and pausing a sandbox stops the meter. The pricing page lists current rates, and 500 free credits let you run real workloads before paying anything.

Can agent data and traffic stay inside my own cloud?

Yes. Bring your own compute runs the same API on your machines, and bring your own bucket works with S3, R2, and MinIO, so artifacts and session data stay in your boundary.

Conclusion

Egress fees are a tax on the agent workloads that succeed. Every fan-out, every artifact, every log stream grows a bill that scales with usage. CreateOS Sandbox removes the tax and keeps the control: Firecracker microVMs with their own guest kernels, egress allowlists enforced in the host kernel once you set them, per-second billing, and bring-your-own compute and storage when data has to stay in your boundary.

The fastest way to evaluate it is to run your own workload. Create an API key, spin up a sandbox, point one agent at it, and read the bill. 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.