Long-Running AI Agents That Wait on Humans: A Sandbox That Pauses Instead of Burning Compute

An agent that waits hours for a human approval does not need to keep burning CPU while it waits. CreateOS Sandbox pauses the whole machine: a Firecracker snapshot of full guest state, compute billing stopped, resume restoring the exact session. Pause takes about 1.4 seconds, and same-host resume comes back in under 0.7 seconds.

Introduction

Agents that run for hours hit a problem most infrastructure was never designed for: the wait. A coding agent finishes a change and needs a human review. A research agent drafts a plan and needs sign-off before it acts. A multi-step workflow stalls until someone answers a question.

On a typical VM or container platform, that wait is billed time. The session holds its memory, its CPU reservation, its open files. You either keep paying for an idle machine, or you kill the session and lose the state, and the agent starts over from scratch when the human finally replies.

The third option is pause. CreateOS Sandbox is built for exactly this pattern: agents that run for hours, sometimes wait on a person, and need to come back to the same machine when that person answers.

Key Takeaways

Pausing writes a full Firecracker snapshot of guest state and stops compute billing, so an agent waiting on a human costs storage, not compute.
Resume restores the exact machine: same memory, same working state, under 0.7 seconds on the same host.
Idle timeout auto-pause is configurable, so a forgotten session does not become a forgotten bill.
Forking a paused sandbox branches its state, so you can run parallel rollouts while the original waits.
New accounts start with 500 free credits, and billing is per second with $0 egress.

Why This Solution Fits

The economics of a waiting agent are simple. While an agent waits on a human, it does no useful work. It holds state: loaded context, open connections, files on disk, the position in its task. The state matters. The compute does not.

Pause in CreateOS Sandbox writes a Firecracker snapshot of the full guest state, memory and disk, and stops compute billing at that moment. The machine is not running. It is a snapshot on storage. When the human approves, resumes, or answers, the sandbox restores that exact machine and the agent continues where it stopped.

The timings, with their real qualifiers: pausing takes about 1.4 seconds. Same-host resume is under 0.7 seconds. Cross-host cold resume runs 11 to 13 seconds. Those are measured figures, not an SLA, and the create-time figure of tens of milliseconds, about 30 ms on an idle host, is likewise an idle-host measurement, not an SLA.

There is also a default that protects you from yourself. Idle timeout auto-pause is configurable, and it is on by default at thirty minutes. If a session goes quiet and nobody pauses it, the platform pauses it. The tradeoff is direct: the first request after a pause waits for the resume. For an agent already waiting on a human, that tradeoff is usually free.

Key Capabilities

A coding agent opens a pull request and waits for review. Pause it. When the reviewer comments, resume, and the agent has its full context: the files it changed, the tests it ran, the reasoning it had.

A research or operations agent needs sign-off before an irreversible action. Pause at the gate. Resume on approval. The audit trail shows the wait, the approval, and the continuation.

A team runs N candidate fixes. Fork the paused sandbox and each fork branches the memory and working state. Run the candidates in parallel, keep the winner, discard the rest. The original session is untouched.

What the Sandbox Does While Your Agent Waits

Pause, resume, fork. Full guest-state snapshot, compute billing stopped while paused, resume restoring the exact machine, and forking a paused sandbox to branch agent state for parallel runs.
Idle timeout auto-pause. Configurable, on by default at thirty minutes, so an abandoned session stops costing compute without anyone remembering to pause it.
Per-second billing with $0 egress. You pay for the seconds a machine actually runs. Paused time is storage, not compute. Egress is free.
Isolation while it waits. Every sandbox is a Firecracker microVM with its own guest kernel, not a container. A paused session is still a machine boundary, not a shared process.
Bring your own storage and compute. Snapshots can land in your own S3, R2, or MinIO, and the same API runs on your machines when sessions need to stay inside your boundary.

One thing to get right: outbound network access in a sandbox is open until you set at least one egress rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. Inbound is closed by default regardless. Set the allowlist through the egress field at create time, the egress API, the SDK's setEgress, or the CLI.

Proof & Evidence

2.6 million sandboxes created since June 2026 (as of 1 October 2026). CreateOS's own CI has run on sandboxes since July 2026, which is the young-product proof we can point to: the platform eats its own cooking. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

The product is young and we say so plainly. What is proven is the mechanism: snapshot, restore, fork, and the billing model that makes a waiting agent cheap. See the Sandbox product page and sandbox pricing for current limits and shapes, which run from a quarter CPU up to 8 CPUs and 16 GB, with 10 to 60 GB of disk.

What to Check Before You Commit

Resume latency across hosts. Same-host resume is under 0.7 seconds; cross-host cold resume is 11 to 13 seconds. If your workflow needs instant continuation after a human reply, know which case you are in.
The first request after a pause waits for the resume. Auto-pause trades a short delay for a stopped meter. For human-in-the-loop waits, that is almost always the right trade.
No GPU sandboxes. If your agent needs a GPU while it waits or works, this is not the fit.
Egress is opt-in restriction. If your security model assumes deny-by-default outbound from the first second, set the allowlist at create time rather than after.
Self-host if the state cannot leave. Control plane and storage can be self-hosted entirely, so paused snapshots of sensitive agent state stay in your own boundary.

Frequently Asked Questions

What happens to my agent's state while it waits for a human?

Pausing writes a Firecracker snapshot of the full guest state, memory and disk. Compute billing stops. On resume, the exact machine is restored and the agent continues where it stopped, with its context, files, and working state intact.

How much does a paused sandbox cost?

Paused time is storage, not compute. Running time is billed per second with $0 egress. An agent that runs for minutes and waits for hours costs mostly storage while it waits.

Can I run parallel versions of a waiting agent?

Yes. Fork a paused sandbox and each fork branches its memory and working state. Run N candidates in parallel, keep the winner, and the original session stays untouched.

What if someone forgets to pause the session?

Idle timeout auto-pause handles it. It is configurable and on by default at thirty minutes, so a session that goes quiet stops consuming compute on its own.

Conclusion

An agent waiting on a human should cost storage, not compute. Pause writes a full snapshot, the meter stops, and resume brings back the exact machine in under a second on the same host. Point your longest-waiting agent at a sandbox and watch the bill flatten. New accounts start with 500 free credits, and the docs cover the pause, resume, and fork APIs. Start 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.