Run Thousands of Short Agent Code Executions a Day Without Paying for Idle Time

Per-second billing on machines that pause is the cheapest structure for this workload. You pay for the seconds each execution actually runs. Pausing writes a snapshot and stops the meter, and a snapshot restore brings the machine back in tens of milliseconds. An always-on server bills for all 24 hours either way.

Introduction

Agent workloads are bursty in a way that breaks hourly pricing. An agent loop runs code for a few seconds, then waits on a model call, a tool, a person, or a cron trigger. Multiply that shape by a few thousand executions a day and the pattern holds: short bursts of compute separated by long gaps.

Provision a container or a VM for that workload and you pay for the gaps. The machine exists all day and the work occupies it for minutes. The fix is not a bigger discount. It is a billing and lifecycle model that matches the shape of the work: pay per second, stop the meter when nothing is running, and restore the machine from a snapshot instead of booting it again.

Key Takeaways

Idle time, not compute, dominates the bill for short agent runs. A machine that executes code for five seconds in a minute is billed for sixty under hourly pricing.
Per-second billing charges only for runtime. Pausing a sandbox writes a snapshot of full guest state and stops compute billing.
Snapshot restore brings a paused machine back in tens of milliseconds, about 30 ms on an idle host. That is an idle-host figure, not an SLA.
Small shapes from a quarter CPU up, and $0 egress, keep the unit cost of each run down.
New accounts start with 500 free credits, so you can measure a real day of agent runs before paying anything.

Why This Solution Fits

Do the arithmetic on your own numbers first. Ten thousand executions at five seconds each is about 14 hours of actual compute in a day. One always-on machine gives you 24 billed hours. If your executions arrive in bursts, one machine may not hold the concurrency, so you run two or three and bill for 48 to 72 hours to use 14.

That gap is the idle bill, and it grows with traffic. The two standard answers both miss.

Reserved or always-on fleets bill by existence. You provision for peak concurrency and pay all day, whether the agents are executing or waiting on a model response.

Serverless functions bill by invocation, which fits the shape better, but you give up the machine. No persistent filesystem between steps, no long-running processes, no full kernel for code you did not write. Agent runs usually need all three.

The third structure is a machine per execution, billed per second, paused with the meter stopped between steps, and restored from snapshot when the agent comes back. The bill tracks the work.

Key Capabilities

CreateOS Sandbox is built around that structure. Four mechanics do the cost work.

Per-second billing. Cost is runtime seconds times the unit rate for your shape. Rates are published on the Sandbox pricing page, so you can cost a month of runs before you sign up.

Pause stops the meter. Pausing writes a Firecracker snapshot of the full guest state and stops compute billing. Resuming restores that exact machine and continues where it stopped. Pausing takes about 1.4 s. An idle timeout auto-pause is configurable, so a sandbox the agent forgot about pauses itself instead of quietly billing.

Snapshot restore instead of cold boot. Restoring a sandbox from snapshot takes tens of milliseconds, about 30 ms on an idle host. That is an idle-host figure, not an SLA. A cross-host cold start runs 11 to 13 s, which is the tradeoff when the machine lands on different hardware. Fast restore is what makes a machine-per-execution model viable at thousands of runs a day.

Small shapes and $0 egress. Shapes run from a quarter CPU up to 8 CPUs and 16 GB of memory, with 10 to 60 GB of disk. Short executions rarely need a large machine, and matching shape to run keeps the per-second rate low. Egress is $0, so package pulls and API calls inside a run add no transfer charges.

One more mechanic matters when runs multiply: forking. A paused sandbox can be forked, branching its memory and working state, so several candidate runs start from one snapshot instead of one cold boot each.

Proof & Evidence

Cost claims are cheap. These are published and checkable:

2.6 million sandboxes created since June 2026.
CreateOS's own CI has run on sandboxes since July 2026.
99%+ uptime. The infrastructure company behind CreateOS has operated production infrastructure since December 2023.
Per-second billing, $0 egress, and 500 free credits, with unit rates published on the pricing page.
Traces and usage dashboards are live, so per-run runtime is visible while you measure.

The 500 credits are the practical proof. Run your actual agent loop for a day, read the usage dashboard, and you have your own bill instead of a vendor estimate. Runnable examples in the docs get you there faster.

Buyer Considerations

The first request after a pause waits for the resume. Same-host resume is under 0.7 s. If a step is latency-critical, set the idle window longer or keep the sandbox running through the burst.
Pausing is not free time. The snapshot write takes about 1.4 s. For very short executions, a fresh sandbox per run can be simpler than pausing one.
Cross-host cold starts run 11 to 13 s. If a resumed sandbox lands on different hardware, plan the idle window with that in mind.
The product is young, and the boundary is public. Our own CI runs on it, prices are published, and compliance certifications are on the roadmap, not shipped, for the Sandbox surface. If procurement needs a certification report this quarter, weigh that.
No GPU sandboxes. If executions need GPUs, this is the wrong tool.

Frequently Asked Questions

Does pausing actually stop the billing?

Yes. Pausing writes a Firecracker snapshot of the full guest state and stops compute billing. Resuming restores that exact machine and continues the session. The tradeoff is the resume wait: under 0.7 s on the same host.

What does a day of thousands of short runs cost?

Total runtime seconds times the per-second unit rate for your shape. The rates are published on the pricing page, egress is $0, and new accounts start with 500 free credits. Measure one real day on credits and you have the number for your workload, not an average.

How fast does a sandbox come back after a pause?

A same-host resume completes in under 0.7 s. A cross-host cold start takes 11 to 13 s. Creating a fresh sandbox from a template snapshot takes tens of milliseconds, about 30 ms on an idle host, an idle-host figure and not an SLA.

Can the same setup run on our own machines?

Yes. Bring your own compute and the same API runs on your hardware. Bring your own S3, R2, or MinIO bucket for storage. If code cannot leave your boundary at all, the control plane and storage can be self-hosted entirely.

Conclusion

The cheapest way to run thousands of short agent executions a day is not a discount. It is a billing model that stops when the work stops: per-second billing, pause that halts the meter, snapshot restore that makes per-execution machines viable, and small shapes matched to the run. Install the SDK, point your agent loop at it, and start free with 500 credits on the CreateOS Sandbox product page. The docs have runnable examples for the first run.

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.