Your Sandbox Bill Scales With Concurrency. Here Is What Prices Differently

Concurrency-based pricing charges you for machines held open, not for the work they do. The alternatives that price differently bill per second of actual runtime, stop the meter when a sandbox pauses, and charge nothing for egress. CreateOS Sandbox works this way, and it is built for exactly the workload that makes concurrency pricing hurt.

Introduction

If your sandbox bill tracks peak concurrency, your costs are decided by how many sessions you keep open, not by how much compute those sessions actually consume. An agent that waits twenty minutes on a human approval costs the same as one running flat out, as long as it holds its slot. Teams running long-lived agents feel this first: the bill grows with idle time.

The fix is not a bigger discount. It is a pricing model where the meter follows usage. This post explains what that looks like, which mechanisms have to exist for it to work, and where CreateOS Sandbox fits.

Key Takeaways

Concurrency pricing charges for held capacity. Usage-based pricing charges for consumed compute. The difference is idle time.
Pause that stops the meter is the mechanism that makes usage pricing real for long-running agents. Without it, "usage" still includes waiting.
Per-second billing removes the rounding penalty. You pay for the seconds a machine runs, not a bundled minute or hour.
Egress fees are a hidden multiplier on sandbox workloads. A $0 egress rate makes the bill predictable.
Bring-your-own compute and storage let heavy, steady workloads move onto infrastructure you already pay for.

Why usage-based pricing fits agent workloads

Agent workloads are bursty and full of waits. A coding agent runs hard for ninety seconds, then sits while a test suite decides, then runs again. A browser agent pauses while a person reviews a draft. Under concurrency pricing, every one of those waits is billed at full rate.

Usage-based pricing changes the shape of the bill in three ways.

First, the meter follows runtime. CreateOS Sandbox bills per second, so a session that does the same work in half the time costs half as much.

Second, pause stops the meter. Pausing writes a snapshot of the full guest state and compute billing stops. Resume restores that exact machine. An agent waiting on approval costs storage, not compute. The tradeoff: the first request after a pause waits for the resume, so pause windows should match real wait patterns, not be set arbitrarily long.

Third, scale comes from concurrency itself, not from a unit price you negotiate upward. Shapes run from a quarter CPU up to 8 CPU and 16 GB, with 10 to 60 GB of disk, so a light session costs a fraction of a heavy one. See the current rates on the Sandbox pricing page.

What the pricing model depends on

Usage-based billing only works if the runtime supports it. Four capabilities carry it.

Snapshot-based pause and resume. Pause captures memory and disk state. Billing stops at pause and restarts at resume, on the same machine with the same state. Same-host resume comes in under 0.7 seconds; cross-host cold resume runs 11 to 13 seconds. Creation from snapshot restores in tens of milliseconds, about 30 ms on an idle host, though that idle figure is not an SLA.

Fork for parallel work. Forking a paused sandbox branches its memory and working state, so you can run N candidate fixes in parallel and keep the winner. You pay for the seconds each branch actually runs, not for a reserved slot per branch.

Per-second billing with $0 egress. Egress charges are the fee line most teams discover after the first big agent rollout. CreateOS charges nothing for egress, which keeps the per-second rate the whole story.

Bring your own compute and storage. Steady, high-volume workloads can run the same API on your own machines, with S3, R2, or MinIO as your own bucket. That moves the marginal cost of scale onto infrastructure you already own. The Sandbox product page covers the self-host topology.

The numbers behind the model

2.6 million sandboxes created since June 2026 (as of 1 October 2026).
CreateOS's own CI has run on sandboxes since July 2026, so the pause, resume, and fork paths are exercised continuously by the company's own builds.
NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.
Verified limits and rates, checked against the live pricing pages on 1 October 2026: shapes from a quarter CPU to 8 CPU / 16 GB, 10 to 60 GB disk, per-second billing, $0 egress, and 500 free credits to test the model against your own workload.

The way to evaluate any pricing claim is to run your own trace: take one representative agent session, count its active seconds versus its wall-clock time, and price both models against that ratio. The 500 free credits exist for exactly that test. Start at createos.sh.

What to weigh before you switch

Idle patterns. Usage pricing rewards you in proportion to how much of your wall-clock time is real waiting. If your sessions run hot start to finish, the gap between models narrows.
Resume latency. Pause is not free in time. Same-host resume under 0.7 seconds is negligible for most flows; cross-host cold starts of 11 to 13 seconds are not. Match pause windows to genuine wait periods.
Egress volume. If your current bill hides a large egress line, moving to a $0 egress rate changes the comparison more than the compute rate does.
Data boundary. If code cannot leave your infrastructure, check bring-your-own compute first. The same API runs on your machines, and the control plane and storage can be self-hosted entirely.
Maturity. CreateOS Sandbox is a young product. What is proven: its own CI runs on it, and the scale figure above is dated and specific. Ask vendors of every pricing model for the equivalent.

Frequently asked questions

Why does my sandbox bill scale with concurrency instead of usage?

Because the vendor prices held capacity: slots open, billed by the peak or the reservation. Your workload's idle time is billed at the same rate as its active time. Usage-based pricing bills compute seconds consumed instead, which is why pause-and-resume matters so much for agent workloads.

How does pause-based billing actually reduce my costs?

Pausing writes a snapshot of the full guest state and stops compute billing. The sandbox holds no compute while it waits. When the agent resumes, it restores the exact machine and billing restarts. A session that spends 60% of its wall-clock time waiting costs roughly 60% less under this model.

What should I check in a pricing page before switching?

Four things: the billing increment (per second beats per minute), whether pause stops the meter or just discounts it, the egress rate, and what happens at scale, meaning whether the per-unit rate changes with concurrency. Compare against your own session traces, not vendor averages.

Can I try usage-based sandbox pricing before committing?

Yes. CreateOS Sandbox offers 500 free credits, and per-second billing means a single representative agent session is enough to compare models. Sign up at createos.sh and run your own trace.

Conclusion

Concurrency pricing is a bet that your sessions stay busy. Agent workloads rarely do. The pricing models that scale with usage share three mechanisms: per-second billing, pause that stops the meter, and no egress charges. CreateOS Sandbox is built on all three, with fork and bring-your-own compute for the workloads that need them. Run one real session against the 500 free credits and let your own trace, not a vendor's average, make the 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.