There’s a small moment every long-running task has: the wait. An agent finishes step three of seven and needs a human to approve step four. A training script hits a checkpoint at 2 a.m. A REPL session holds twenty minutes of careful state, and you’d really like to close the laptop.
Until now, pausing a Watasu sandbox preserved your files — the disk came back exactly as you left it, but the machine itself restarted. Processes died. The REPL forgot. The build began again.
From today, pause freezes the entire machine. RAM, running processes, open file handles, that background tail -f you forgot about — all of it goes to sleep together, and all of it wakes up together. Resume doesn’t restart your sandbox; it continues it.
What that looks like
from watasu import Sandbox
sbx = Sandbox(template="base")
sbx.commands.run("python train.py &") # long-running work, mid-flight
sbx.pause() # the machine falls asleep
# ...hours later, or from a different process entirely...
sbx = Sandbox.connect(sandbox_id) # the machine wakes up
sbx.commands.run("tail -1 train.log") # still training, same processNo re-setup, no “restore your state from disk” dance, no special checkpoint-aware code inside the sandbox. The program that was running simply keeps running, unaware anything happened. (The clock jumps forward, as it does after any nap.)
Why this matters for agents
Agents wait a lot — for approvals, for rate limits, for the next step of a plan, for a human to come back from lunch. Keeping a machine running through those waits costs compute; tearing it down costs all the working state your agent built up.
Now the pattern is simple: pause between steps, resume when the work continues. While a sandbox sleeps it bills storage only — cents per gigabyte per month, no per-second compute at all — and because Watasu is prepaid, a fleet of napping agents is a slow trickle from your balance, never a surprise. An agent can hibernate overnight for less than the cost of thinking about it.
And while we were in there…
Making machines sleep and wake taught us to make them wake fast. The same machinery now warms up new sandboxes too: a fresh sandbox from a template comes up in about 769 milliseconds on the node — roughly a second end-to-end from your API call to a working shell. Create ten sandboxes in the time a container registry would still be thinking about it.
You don’t have to do anything to get this. It’s just how starting works now.
How it works, briefly
Under the hood, every sandbox is a microVM. Pausing takes a snapshot of the machine’s memory and device state and stores it privately with your sandbox’s disk — it’s yours, tied to that sandbox, billed as its storage, deleted with it. Resuming loads the snapshot, gives the machine back its network identity, and lets it carry on. If anything about a resume can’t be satisfied, the sandbox falls back to the classic disk-checkpoint boot — your files are always safe, and a resume never fails harder than “the processes restarted, like before.”
Fast starts work the same way, one level up: each node keeps a warm, pristine image per template — booted once, never used by anyone — and new sandboxes continue from it instead of booting from scratch. Your sandboxes are never part of anyone else’s warm image, and nobody’s state is ever part of yours.
Same isolation, same EU-resident infrastructure, same per-second billing while awake.
Get started
Pause and resume are live for all sandboxes today — pause() and connect()/resume() in the Python, TypeScript, and Rust SDKs, or the same calls on the REST API. The lifecycle option on_timeout=pause puts idle sandboxes to sleep automatically. See pricing for storage rates while paused.
Questions, or a workload with unusually long naps? Write to us at info@watasu.io — we’d love to hear what you’re building.