· 9 min read · Mert Ozgun · Facts checked
Most sandbox providers for AI agents now say their sandboxes persist. The word covers very different behavior. On one provider it means the memory and running processes survive a pause. On another it means the disk is saved when the sandbox stops, and on a third it means you can take a snapshot before the sandbox is thrown away.
Those differences decide whether an agent’s next job finds its repository and dependencies in place, and what is lost when something fails. This post asks six questions that separate them and answers each from the providers’ own documentation. Ortam is one of the ten, and it’s in private beta: its row comes from its own docs for a product you can’t buy yet, and some of its numbers, such as how often it saves and how long a start takes, aren’t published. The facts about the others come only from their own docs and pricing pages, checked on 26 October 2026, and every source is linked at the end. This post compares what is kept, how long it takes to come back and what keeping it costs. It doesn’t compare regions or SDKs.
One provider is leaving: Runloop’s docs say it “is winding down its services”, with support for existing customers through 13 November 2026. Its answers are still listed, for teams moving off it.
Each provider has its own word for the off state, and they don’t mean the same thing. Vercel and Daytona’s container sandboxes stop. E2B, Daytona’s VM sandboxes and Northflank pause. Fly.io’s Sprites pause too, first warm and then cold. Runloop suspends, Blaxel goes to standby, and Modal and Cloudflare sandboxes end. The answers below use each provider’s own word.
| Provider | Kept when off, by default | When it’s saved | Kept for, by default |
|---|---|---|---|
| Vercel Sandbox | Disk | On stop or timeout, and on request | 30 days after last use; configurable |
| Fly.io Sprites | Disk; memory only while warm | Disk synced continuously; checkpoints | Old automatic checkpoints are pruned |
| E2B | Disk and memory on pause; a timeout kills it unless auto-pause is on | On pause, or a snapshot | Indefinitely, once paused |
| Daytona | Containers (the default): disk. VM sandboxes: disk and memory on pause | Containers: disk stays on the runner. VMs: offloaded to storage. Snapshots on request | No auto-delete. Containers stop after 15 minutes idle and archive after 7 days stopped; VMs pause after 60 minutes idle |
| Modal Sandboxes | Nothing, unless you snapshot | Only on a snapshot you trigger | Filesystem 30 days, configurable; memory 7 days |
| Cloudflare Sandboxes | Nothing, unless you snapshot | Only on a snapshot your app takes (beta) | 30 days from creation or last restore |
| Runloop | Disk on suspend | On suspend, or a disk snapshot | Snapshots: indefinitely |
| Northflank | An attached volume | Not stated; the volume is a disk | No expiry stated |
| Blaxel | Disk, memory and processes on standby | On standby, and on request | No expiry; tiers 0 and 1 cap it at 7 and 30 days |
| Ortam (private beta) | Disk | On a schedule while it runs (interval not yet published), an attempted final save on Stop, and Snapshots on request | While your plan is active |
Memory survives on E2B and Blaxel by default, on Daytona’s VM sandboxes when paused, and on Sprites while they are warm. A paused process picks up where it was. That suits work that is expensive to rebuild in memory, such as a loaded dataset or a long interactive session.
On Runloop, Daytona’s container sandboxes, Sprites once they are cold, and Ortam, the disk survives and the processes don’t. Vercel restores the filesystem, and its docs don’t describe keeping memory or processes. The next run boots from the saved disk and starts its services again. For coding agents this covers most of the setup cost: the clone, the installed packages, the Docker images and the build caches are files. Runloop states the consequence plainly: “Daemons or other processes running at suspend time must be manually restarted after resuming.” On Ortam, services you enable with systemd start again at boot.
Northflank keeps only what is on an attached volume: “Anything written only to ephemeral storage is lost when the sandbox pauses.” Modal and Cloudflare keep nothing unless your code takes a snapshot. That is a different model: the sandbox is disposable, and persistence is something you build from volumes or snapshots.
This question decides what a crash can cost, and it is easy to miss. Saving only when the sandbox stops means nothing is saved while an agent works for hours. Vercel snapshots on stop or timeout, and you can call snapshot() while it runs, which also stops the session. E2B saves on pause. Runloop saves on suspend.
Sprites sync the disk continuously: “The filesystem syncs to it continuously, not as a snapshot taken at hibernation.” Ortam saves a running Sandbox on a schedule and Stop attempts a final save. Its docs don’t publish the interval yet, and they say a save can lag, so the schedule isn’t a promise about how much a failure can lose. If the final save fails, Ortam says so and the previous save stays the one it recovers from.
Expiry defaults vary more than anything else in the table. Vercel’s snapshots “expire 30 days after their last use by default”, and you can remove the expiry. Cloudflare’s snapshots expire “30 days after it is created or last restored”. Modal keeps filesystem snapshots 30 days by default and memory snapshots 7 days, which can’t be extended.
E2B keeps a paused sandbox “indefinitely”, and Runloop’s snapshots “persist indefinitely and continue to incur storage costs”. Daytona doesn’t delete by default, but unless you change the timers it stops a container sandbox after 15 minutes without activity and archives it after 7 days stopped, and pauses a VM sandbox after 60 idle minutes. On Ortam, saved data “is kept until you delete it while your plan is active.”
If an agent’s environment sits unused for a month between jobs, check this default first.
When a state is saved tells you what is in the last save. It doesn’t tell you what a hardware failure loses, because that also depends on where the disk lives while the sandbox runs. A disk that lives only on the failed machine loses everything since the last save; a disk replicated elsewhere may lose nothing. The pages this post is based on don’t settle that question for the other providers, so ask them directly:
Ortam’s docs answer the first two only in part, because its save interval isn’t published yet: changes after the last completed save can be lost, and “Ortam reports which save it recovered from and which commands were running.” Nothing reruns on its own, so your system decides what to run again. Saves and recovery covers the details.
Session caps matter for agents that run for hours. Vercel caps a session at 45 minutes on Hobby and 24 hours on Pro, but the limit “resets every time a sandbox stops and resumes”. E2B allows 1 hour of continuous runtime on Hobby and 24 hours on Pro, also reset by a pause. Modal sandboxes can run up to 24 hours. Runloop’s default lifetime is 1 hour and can be configured. Cloudflare states an inactivity timeout of up to 6 hours and “does not guarantee that an instance runs for a set time.”
Daytona has no cap by default, but its idle timer needs attention for agents: “the process itself doesn’t count as ‘activity’”, so a container sandbox whose job runs for more than 15 minutes without outside interaction can be stopped partway. Set the auto-stop interval to 0 for those. Ortam’s docs say: “A Sandbox runs until you stop it or a published limit applies.” Sprites, Northflank and Blaxel don’t state a cap.
A kept environment saves setup only if starting it again is quicker than setting it up. Few providers publish a number, and the ones that do measure different things: waking a paused sandbox with its memory is a different operation from booting one from a saved disk.
| Provider | Stated time | What it measures |
|---|---|---|
| Fly.io Sprites | 100–500 ms warm, 1–2 s cold | Waking with memory, and booting from the disk once memory is dropped |
| E2B | About 1 second to resume; pausing takes about 4 seconds per GiB of memory | Resuming with memory and disk |
| Blaxel | Under 25 ms from standby; going to standby takes about 15 seconds | Resuming with memory and processes |
| Northflank | “Under a second” | Booting a sandbox; a pause keeps only its volume |
| Cloudflare Sandboxes | Container cold starts “often” 1–3 seconds | Starting a container; restoring a snapshot isn’t stated |
| Runloop | “Seconds” on one page, 2–5 minutes on another | Resuming from the disk; its two pages disagree |
| Vercel Sandbox, Daytona, Modal | Not stated | Their pages describe resuming as fast without a number |
| Ortam (private beta) | Not published yet | Booting from the last save |
How long a disk takes to restore usually grows with its size, and none of these pages give a number for a large disk. Measure it with a disk the size of yours before you rely on it.
Saved state is billed by the GB, and the rates differ by more than ten times. Prices are as each provider states them, for a month of 30.4 days where the rate is hourly.
| Provider | Stated price | 25 GB for a month |
|---|---|---|
| Vercel Sandbox | $0.08 per GB a month for snapshots, on Pro | $2.00 |
| Fly.io Sprites | About $0.02 per GB a month cold, $0.50 while awake | $0.50 cold |
| E2B | “Paused and killed sandboxes are not billed” | Not billed |
| Daytona | $0.000108 per GiB an hour after the first 5 GiB; archived sandboxes aren’t billed | $1.58 for 25 GiB, with 5 free |
| Modal Sandboxes | Not stated for snapshots | Not stated |
| Cloudflare Sandboxes | Not stated for snapshots | Not stated |
| Runloop | $0.000072 per GB an hour for snapshots, $0.00034236 for a suspended devbox’s disk | $1.31 as a snapshot, $6.25 suspended |
| Northflank | $0.11657 per GiB a month for a volume | $2.91 for 25 GiB |
| Blaxel | $0.20 per GB a month for snapshots | $5.00 |
| Ortam (private beta) | $0.01 per GB a month, measured after deduplication; a planned launch price | $0.25 |
For a few environments, none of these amounts matter. For hundreds of kept environments, or for one per task, they add up, and so does the difference between “kept by default” and “kept until it expires”.
Almost every provider here runs each sandbox in a VM or microVM. Daytona runs containers by default, with VM sandboxes as an option, and Modal offers gVisor or a VM runtime. On Northflank’s cloud, CPU sandboxes run in microVMs and GPU sandboxes under gVisor.
Docker inside the sandbox works on most of them, often as Docker-in-Docker from a provided image or template. Vercel supports it as a process with system privileges, and Modal on its VM runtime. Ortam runs each Sandbox in its own VM, where the developer user has sudo and can run Docker, and a save keeps Docker images and volumes with the rest of the disk.
Providers change these behaviors often. Several of the features above are marked beta or alpha in their docs, and some depend on the plan, so check the linked pages before you decide.
Checked on 26 October 2026. Quotes are from these pages.
· 5 min read
What a hardware failure can lose in an agent’s sandbox, how Ortam picks the save it recovers from, why it never reruns a command, and what your system should do to bound the loss.
· 6 min read
A coding agent’s sandbox can start fresh, from a prebuilt image, or on the disk the last job left. What each one costs in waiting, failures, drift, parallel work and money, and how to measure it on your own jobs.
· 10 min read
Set an agent’s environment up once, keep it in a Snapshot, give each task its own copy, and rebuild it only when the lockfile or images change. With a script that waits for every step.