Your agent finishes a task. The next job is 30 minutes away.
Do you keep its sandbox running, rebuild it later, or checkpoint it?
What breaks when you try the cheaper option?
Before your invoice agent upgrades its PDF tools:
1. Save processed invoice IDs to disk.
2. Take a Sandbox0 RootFS snapshot.
3. Upgrade and check the output.
Rolling back also rewinds files to the snapshot. Preserve newer reports first.
Restart ≠ rollback.
Building a personal agent that needs its own persistent workspace?
New Sandbox0 users get a one-time $5 usage credit. No credit card required.
Install tools, save files, pause compute between tasks, and return to the same environment.
sandbox0.ai/pricing
Your agent finished a report. Why wake its whole environment just to read it?
Sandbox0 lets you read persistent files while compute stays paused.
Filesystem-only pause: read + edit files.
Memory pause: read-only to preserve captured process state.
Broken terminal ≠ lost workspace.
Sandbox0's recovery path works outside its guest command service.
Restart: fresh processes, committed files.
Rollback: restore an earlier snapshot.
Restarting won't undo bad config edits.
Three agent tasks. One dependency setup.
With Sandbox0:
1. Prepare a workspace.
2. Create a RootFS snapshot.
3. Start an isolated sandbox per task from that snapshot.
Each gets its own writable branch. The snapshot carries files, not running processes.
A paused agent cannot watch for the event that wakes it.
Keep the scheduler outside the sandbox. Wake it for a job, save task state, then pause compute again.
sandbox0.ai/blog/2026-10/why…
Agent output vanished after pause/resume? Check the path.
In Sandbox0's default filesystem-only mode:
/tmp → runtime-only; recreated on resume
/workspace → writable RootFS; restored after a successful checkpoint
Keep task artifacts out of temporary mounts.
Persistence checklist for agent builders:
- Project files still there?
- Installed tools still there?
- Config + caches still there?
- Processes restored, or restarted?
Sandbox0 checkpoints the writable RootFS. Default resume starts fresh processes.
Test the second session.
Most "long-running" sandboxes live minutes. Some, days.
That is not a background agent. It is a short-lived sandbox with a long life.
The real distinction is not runtime. It is whether the rootfs grows. An agent holding one workspace for months builds a filesystem no fresh sandbox has.
That 'thinks hard, then waits' shape is why idle has to be cheap. If pausing a waiting agent resets its workspace, it can never accumulate anything across a long task.
We treat the rootfs as durable and compute as replaceable, so waiting costs storage, not a running machine.
Second reason: live migration drains lightly-occupied nodes with process and memory intact, so a handful of background agents don't have to pin a whole machine and inflate the price.
Receipts: sandbox0.ai/pricing
Background agents run for months. Their rootfs only grows.
If pause copies the whole disk, it gets slower every day.
Sandbox0 pauses on a block-COW rootfs: it seals only what changed since the last checkpoint.
Pause scales with change, not size.
The costly part of autoscaling isn't scaling up.
It's the aftermath. A spike spins up nodes, the spike fades, and you're left with a fleet where each node holds one or two sandboxes — all still billed as running memory.
Sandbox0 now fixes that while workloads keep running.
The point is consolidation: stop paying for fragmentation.
Compute is $0.015 per GiB-hour of running sandbox memory. Fewer half-empty nodes means less of it.
Normalized to 1 GiB-month, Sandbox0 is $10.95 vs E2B/Daytona $30.22.
Write-up:
sandbox0.ai/blog/2026-09/liv…
Measured: a Python workload holding 128 MiB of random memory.
Drain trigger to a usable destination: 3.40-3.64s over six migrations, 3.52s median. None under 3 seconds.
After each move we verified guest PID, memory SHA-256, and an unlinked open file's offset.
Files were never the hard part.
A running workspace also holds in-memory state, live subprocesses, and open files with no pathname left. On stock gVisor we checkpoint execution state, transfer it to a compatible node, and resume the same process — same guest PID, same memory.