Per-Second Billing That Stops When Your Sandbox Pauses: How CreateOS Sandbox Charges Only for Compute You Use

Most sandbox pricing bills you for the clock, not the work. CreateOS Sandbox bills per second and stops the meter when a session pauses: pausing snapshots the full guest state and compute billing stops, and resume restores that exact machine. You pay for the seconds your code runs, not the hours it waits.

Introduction

An agent session is not a steady stream of work. It runs for ninety seconds, then waits four minutes for a human approval. It runs again, then idles overnight until the next webhook. If your sandbox vendor bills by the hour, or bills per second but never stops, you are paying full price for a machine that is doing nothing but holding memory.

CreateOS Sandbox treats that waiting time as what it is: compute you should not be charged for. Pause writes a Firecracker snapshot of the full guest state, memory and disk, and stops compute billing. Resume brings back that exact machine. This post explains how that billing model works, what it costs, and where the tradeoffs sit.

Key Takeaways

Billing is per second, and pausing a sandbox stops compute billing entirely. The meter runs only while the machine is up.
Pause writes a full memory-plus-disk snapshot; resume restores that exact machine, so agents can wait on a human for hours without paying for the wait.
Egress is $0, so data transfer is not a hidden line item.
New accounts start with 500 free credits, enough to measure your own pause/save pattern before committing.
The tradeoff: the first request after a pause waits for the resume, so pause windows should match your actual idle patterns.

Why This Solution Fits: Billing That Follows the Compute

The cost problem with agent workloads is not the price of a machine. It is the ratio of idle time to run time. A coding agent that a developer checks twice an hour is idle most of the time. A long-running agent that pauses mid-task to ask for approval can sit for hours. Under hourly billing, that idle time is pure waste. Under per-second billing with no pause, it is a smaller waste, but it is still waste.

Pause changes the shape of the bill. When a sandbox pauses, CreateOS writes a Firecracker snapshot of the full guest state and stops compute billing. The machine is not running, so there is nothing to meter. When the next request arrives, resume restores that exact machine: same memory, same disk, same open state. The agent picks up where it stopped.

This is why the model fits agent workloads specifically. Sessions that run for hours but compute for minutes are the norm, not the exception. Billing that follows the compute, rather than the session, is the only model that matches it.

Key Capabilities of Per-Second Billing With Pause

Per-second metering, pause stops the meter. You are billed per second while a sandbox runs. Pausing halts compute billing; resuming restarts it. There is no charge for a paused sandbox beyond storage of its snapshot.

Pause, resume, and fork. Pause writes a memory-plus-disk snapshot. Resume restores it. Fork takes a paused sandbox and branches its state, so you can run N parallel rollouts and keep the winner. Forking is billed the same way: per second, only while running.

Idle timeout auto-pause. A configurable idle timeout pauses a sandbox automatically when it goes quiet, so an abandoned session stops costing money even if nobody remembers to pause it.

$0 egress. Data transfer out of a sandbox costs nothing. For workloads that move real data, this is often the difference between a predictable bill and a surprise one.

Bring your own compute and bucket. The same API runs on customer machines, with customer S3, R2, or MinIO for snapshots, so the billing conversation can stay inside your own infrastructure if that is where it needs to be.

Verified limits as of 1 October 2026: shapes from a quarter CPU up to 8 CPU / 16 GB, disk from 10 to 60 GB, per-second billing, $0 egress, and 500 free credits for new accounts. Current details are on the Sandbox pricing page.

Proof & Evidence: Scale and Speed Numbers

CreateOS Sandbox has created 2.6 million sandboxes 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.

On speed, the qualifiers matter. Creating a sandbox takes tens of milliseconds, about 30 ms on an idle host, though idle p50 is not an SLA. Pausing takes about 1.4 seconds. Resuming on the same host takes under 0.7 seconds. A cross-host cold resume takes 11 to 13 seconds, because the snapshot has to travel. That last number is the real cost of an aggressive pause policy: pause often and cheaply, and some resumes will cross hosts.

You can check the mechanics yourself in the Sandbox documentation and the product page.

Buyer Considerations Before You Commit

Resume latency is not zero. The first request after a pause waits for the snapshot to restore. Under a second on the same host, 11 to 13 seconds cross-host. If your workload is latency-critical with bursty traffic, tune the idle timeout rather than pausing on every gap.
Egress restriction is opt-in. 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, outside the guest. Inbound is closed by default regardless. Set the allowlist at create time or live via the API, SDK, or CLI.
Isolation is not a container. Each sandbox is a Firecracker microVM with its own guest kernel. That is the right default for untrusted or agent-written code, and it is a different product category from container-based sandboxes.
The product is young and says so. CreateOS's own CI and its coding-agent plugin are usable proofs. Where compliance comes up: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

Frequently Asked Questions

Does pausing a sandbox stop billing completely?

Yes. Pausing writes a Firecracker snapshot of the full guest state and stops compute billing. Billing resumes when the sandbox resumes. There is no compute charge for the paused period.

How fast does a paused sandbox come back?

Resume on the same host takes under 0.7 seconds. A cross-host cold resume takes 11 to 13 seconds. Creation from snapshot is tens of milliseconds, about 30 ms on an idle host, which is not an SLA.

What does egress cost?

Nothing. Egress is $0. Data transfer out of a sandbox is not a billed line item.

Is there a free way to test the pause-and-resume pattern?

Yes. New accounts start with 500 free credits, enough to run real sessions, pause them, and measure what the billing model saves on your workload. Start at createos.sh.

Conclusion

Per-second billing fixes the granularity problem. Pause fixes the idle problem. Together they mean the bill tracks the compute your agents actually do, not the time their machines spend waiting. The tradeoff is resume latency on the first request after a pause, and the fix is a tuned idle timeout rather than a bigger bill.

If your agents spend more time waiting than working, that gap is where the savings are. Spin up a sandbox, pause it, resume it, and read the meter. 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.