An ephemeral sandbox runs one task and is destroyed when the task ends, while a persistent sandbox keeps its filesystem, its installed packages and its working directory across sessions, so the choice comes down to what has to survive between one run of an agent and the next.
Your agent just wrote a script and something has to run it. If the script draws a chart from an uploaded CSV, a box that appears, runs it and disappears is the right answer. Nothing survives to leak into the next job.
Change the job and the answer flips. The agent cloned a repository an hour ago, installed four hundred packages, started a dev server and is halfway through a refactor. Tear that box down after every tool call and you buy the clone and the install again on the next one, and throw away the half-finished work in between.
Both jobs show up in the same product, often in the same session, which makes this a platform question rather than a preference.
What Is the Difference Between an Ephemeral and a Persistent Sandbox?
Lifecycle is the difference. An ephemeral sandbox is created per task and destroyed after it; a persistent one survives from session to session. Both isolate code nobody reviewed. What changes is how long everything inside them lives.
| Ephemeral sandbox | Persistent sandbox | |
|---|---|---|
| Lifecycle | Created per task, destroyed after | Survives and resumes across sessions |
| What survives | Nothing, unless exported first | Filesystem, packages, repositories, caches |
| Setup cost | Paid on every run | Paid once, then amortised |
| Leftover risk | Nothing carries into the next job | Anything broken or planted stays until reset |
| Idle cost | None, because it no longer exists | Depends on whether idle compute is billed |
| Typical work | Code interpreter calls, evals, data transforms | Coding agents, long-running projects, previews |
Products blur that line, and often on a single flag. Vercel Sandbox makes every sandbox persistent unless you pass persistent: false, snapshotting the filesystem when a session stops.[1] Daytona sells ephemeral sandboxes as an option, deleted automatically when they stop.[2] E2B kills a sandbox after a five-minute default timeout, or pauses it instead if you tell it to.[3] Read the defaults before assuming which shape you bought.
When Should You Use an Ephemeral Sandbox?
Reach for an ephemeral sandbox when every task stands alone and nothing it writes is wanted afterwards. That covers most of the work described as “run this generated code and give me the output”:
- Code interpreter tool calls. The model writes a snippet, the sandbox runs it, the output goes back into the conversation.
- Evals and benchmarks. Every attempt starts from an identical state, or the scores measure the environment instead of the model.
- Fan-out jobs. Hundreds of short tasks in parallel, each one collected or graded and then dropped.
- Untrusted uploads. A customer’s script, a file of unknown origin, anything where the only safe leftover is none.
Setup is what this shape costs. Every run starts cold, so every run reinstalls the dependencies, refetches the data and rebuilds the context the last run already had. Push that work into the image instead: bake the packages and fixtures in once, then start each task from the prepared image. A sandbox that boots from one is disposable in state and still fast off the line.
When Should You Use a Persistent Sandbox?
Keep the sandbox when the second run builds on the first. A coding agent makes the case on its own: the repository, the dependency tree, the build cache, the local database and the notes the agent left itself are all slow to rebuild and pointless to discard.
Persistence also carries work that outlasts one session: an agent running overnight, a preview someone opens tomorrow, a project a user returns to next week.
Drift is what builders complain about in return. The box that still has your files tomorrow also still has last night’s half-finished install, and agents build on a broken setup rather than noticing it is broken. A week in, nobody can say whether a regression came from the code or from the machine it ran on. So a persistent sandbox needs a route back to a known state.
Is an Ephemeral Sandbox More Secure?
Not inherently. Both are only as strong as the boundary underneath them, and a container sharing the host kernel is a weaker boundary than a microVM with a kernel of its own, whatever its lifecycle. The microVM vs container comparison covers that distinction.
Lifecycle decides how long a mistake lasts, not how easily one happens. A poisoned dependency dies with an ephemeral sandbox; in a persistent one it sits there until somebody removes it, and every later task inherits it. Three controls close most of that gap:
- Checkpoints. A known-good snapshot to restore whenever the current state stops being trustworthy.
- A base the agent cannot dirty. A reproducible image underneath, with the agent’s changes in a layer you can inspect, snapshot and throw away.
- Egress policy. An allowlist of hosts the environment may reach, set from outside it, so compromised code has nowhere to send what it found.
That third one matters just as much to ephemeral sandboxes. Ten seconds is plenty of time to post a credential to the wrong host.
Lifecycle and isolation are separate choices. Pick the boundary for the code you are running, then pick the lifecycle for the work.
Cold Starts, Setup Tax and Idle Cost
Ephemeral is cheap per run and expensive per repeat. Persistent inverts that, and idle billing decides by how much.
The sandbox’s own cold start is rarely what you wait for. The wait is in the cloning, the installing and the cache warming that follow the boot. A task that spends ninety seconds in npm install gains almost nothing from a sandbox that boots in two hundred milliseconds, and a persistent environment pays that install once.
Idle is where persistence gets affordable or does not. Bill reserved resources by wall clock and an agent waiting on a model call costs exactly what an agent compiling costs. Pausing changes that arithmetic, and every provider pauses differently. E2B’s pause holds memory and filesystem, takes about four seconds per GiB of RAM, and keeps the paused sandbox indefinitely.[3] Vercel’s automatic snapshots expire 30 days after their last use unless you change the default.[1] AI sandbox pricing puts the billing models side by side.
What a Burst Workload Needs: Images and Egress
Burst work, hundreds of short tasks at once, turns on two platform properties, and persistence is neither of them.
Custom images
A burst job wants its dependencies already installed, which makes the starting image a requirement rather than a nicety. Daytona builds sandboxes from Docker or OCI images, or from snapshots.[2] A Sprite boots a managed Ubuntu base carrying the common language runtimes and coding agents,[4] and reaches the same place from the other direction: install what the job needs once, checkpoint the writable layer, and restore that checkpoint whenever a run needs the prepared state back.[5]
Egress control
Burst jobs run the least-reviewed code on the platform, so what they can reach on the way out belongs on the checklist. Sprites take a DNS-based domain allowlist, applied from outside the Sprite and readable but not writable inside it, so code that is already running cannot widen its own network policy. The defaults cover the package registries and the major AI APIs, which is what a build needs and not much else.[6]
Session caps, GPU support and the rest of the provider grid are in agent sandbox providers.
Using Both: A Persistent Workspace With Ephemeral Workers
Run both and the tension mostly disappears: one workspace per user or project, disposable environments for the parallel and dangerous parts.
The line worth drawing is between durable state and reproducible execution. The workspace holds what the user would miss: the repository, the agent’s notes, the database. Execution gets rebuilt from a known state every time, and nothing inside it is trusted to survive. A regression then points at the workspace or at the prepared state, rather than at a box that has been alive for three weeks.
Concretely:
- A long-lived workspace that sleeps when idle, holds the project and restores from a checkpoint when the environment stops making sense.
- Short-lived workers started from a known state for test runs, evals and untrusted input, destroyed on completion.
- An egress policy per tier, wider for the workspace that pulls from registries, narrow for workers running code nobody has read.
It stays simple only while both halves run on the same isolation boundary and the same API. Two vendors means two security models and two bills.
Ephemeral and Persistent Sandboxes on Fly.io
Both halves of that pattern are the same product on Fly.io. A Sprite is a Firecracker microVM with a 100 GB ext4 filesystem, and what makes it persistent or ephemeral is how long you keep it.
The agent lives in a Sprite. Its project sits on a disk that survives sleep. The Sprite pauses after roughly 30 seconds of idle, comes back from a warm pause in 100 to 500 milliseconds with processes still running, and after a cold wake of one to two seconds starts processes fresh and relaunches supervised services itself, per the Sprite lifecycle docs.[7] Compute bills while the Sprite is active and stops when it sleeps. Checkpoints snapshot the writable layer and restore it in place, which is the route back from drift.[5] Sprites for AI agents covers the workspace side in depth.
When work does not belong in the workspace, the agent spins up another Sprite. Untrusted input, a dependency it does not want on the project disk, twenty test runs at once: the agent creates a second Sprite through the same REST API that created its own, runs the code there, and destroys it when the job finishes.[8] That child is a separate microVM with its own filesystem and its own egress allowlist, so a package that phones home or a script that fills a disk does it somewhere the project is not.
The lifetime is the only thing that changes between the two. One Sprite is kept and checkpointed, the other is created for a task and deleted after it, and both run behind the same hardware boundary under one API and one bill.
Frequently Asked Questions
What is a sandbox for AI agents?
A sandbox for AI agents is an isolated environment where code an agent wrote runs without reaching the host, production systems or credentials it was never given. It can be ephemeral, created per task, or persistent, kept between sessions. On Fly.io both are Sprites: Firecracker microVMs that differ only in how long you keep them.
Do AI agents always need a persistent sandbox?
No. An agent running independent snippets, such as a code interpreter or an eval harness, is better off with a fresh environment per task. Persistence pays once the next run wants the repository, dependencies or files the last one left. On Fly.io an agent can keep a Sprite for the project and create short-lived Sprites for the throwaway work.
Does a persistent sandbox keep processes running?
Not always. Most persistent sandboxes promise the filesystem, not the processes. A Fly.io Sprite keeps its processes through a warm pause; after a cold wake they start fresh, and the runtime relaunches supervised services automatically.
Can an ephemeral sandbox use persistent storage?
Yes. Storage outside the sandbox, such as an object store or a mounted volume, outlives the sandbox that wrote to it. On Fly.io, a short-lived Sprite can write its results out, or hand them back to the Sprite that created it, before it is destroyed.
Can a Sprite create another Sprite?
Yes. Sprites are created and destroyed through the Sprites REST API, so an agent working inside one can provision a second Sprite for a job it wants outside its own filesystem, then delete it when the job is done. The new Sprite is a separate microVM with its own disk and its own network policy.
Should each user get their own persistent sandbox?
Yes, for coding agents and anything holding a user’s project. On Fly.io the usual pattern is one Sprite per user or per project, each with its own filesystem, its own installed packages and its own network policy.
Is an ephemeral sandbox cheaper than a persistent one?
Not necessarily. Ephemeral sandboxes cost nothing between tasks but pay setup on every run, while persistent ones pay setup once and then cost whatever idle costs. Fly.io Sprites bill compute only while a Sprite is active, so a sleeping workspace bills for its storage.
Can a sandbox allow package installs but block other network traffic?
Yes, with an egress allowlist. Fly.io Sprites take a domain-based network policy whose defaults cover the common package registries and major AI APIs, and any domain outside it is refused. The policy is set from outside the Sprite, so code running inside cannot widen it.
Sources
- ^ Vercel, “Persistence”. vercel.com/docs/sandbox/concepts/persistent-sandboxes. Checked 2026-09-17.
- ^ Daytona, “Sandboxes”. daytona.io/docs/en/sandboxes/. Checked 2026-09-17.
- ^ E2B, “Sandbox persistence”. docs.e2b.dev/sandbox/persistence. Checked 2026-09-17.
- ^ Fly.io, “Working with Sprites”. docs.sprites.dev/working-with-sprites. Checked 2026-09-17.
- ^ Fly.io, “Checkpoints”. docs.sprites.dev/concepts/checkpoints. Checked 2026-09-17.
- ^ Fly.io, “Networking”. docs.sprites.dev/concepts/networking. Checked 2026-09-17.
- ^ Fly.io, “Lifecycle and Persistence”. docs.sprites.dev/concepts/lifecycle. Checked 2026-09-17.
- ^ Fly.io, “Sprites API”. sprites.dev/api. Checked 2026-09-18.