# Persistent vs ephemeral sandboxes for AI agents: which do I need? > Use an ephemeral sandbox for one-shot code execution. Use a persistent computer when the agent must keep files, packages, browser logins or services between sessions. - Source: Sanbox knowledge base, by Sanlabs GmbH - URL: https://sanbox.cloud/kb/agent-computers/persistent-vs-ephemeral-sandboxes/ - Type: explainer - Section: Agent computers explained - Language: en - Published: 2026-11-06 - Updated: 2026-11-06 Decide by how long the agent's work lives and what it must keep. If each job is one piece of code with nothing to remember, an ephemeral sandbox is the right tool: a fresh machine every time, thrown away afterwards. If the agent comes back to the same work, with a repository, installed tools, browser logins, a database or its own memory, you want a persistent computer such as a Sanbox Computer, which keeps its disk between sessions. ## Which two questions decide it? 1. **How long does the work live?** A single call, a task of a few minutes, a project that runs for weeks, or a service that is always on? 2. **What must still be there next time?** Files, installed packages, build caches, browser cookies, container images and volumes, or the agent's notes and chat history. If the answers are "one call" and "nothing", go ephemeral. If the work lasts longer than one session and anything on that list must survive, go persistent. ## Decision table | What the agent does | Choose | Why | |---|---|---| | Runs a snippet the model wrote and returns the output | Ephemeral | Nothing to keep, and a clean machine each time is the safest default | | Builds or runs third-party code you don't trust | Ephemeral, with no credentials | Throw the machine away afterwards | | Grades many eval tasks from identical starting points | Ephemeral copies of a prepared state | Each attempt needs a clean environment; a snapshot removes the setup time | | Reviews some files and writes a report | Ephemeral task | Inputs go in, outputs come out, nothing else matters | | Works on a repository across days | Persistent | The repo, dependencies, build caches and session history carry over | | Logs in to websites | Persistent | Cookies and signed-in sessions live in the browser profile on disk | | Runs a database or dev server it uses again tomorrow | Persistent | Images and volumes stay; containers with a restart policy start again after a resume | | Acts as an always-on assistant with memory, email or Telegram | Persistent | Memory, learned skills and channels are the product | | Serves one end user of your product | Persistent, one per user | Each user's files stay with them; stop the machine when they leave | ## What does ephemeral cost you? - **Setup every time.** Every run clones, installs, builds and logs in again. For a coding agent that can take minutes before any real work starts. - **No memory.** The agent relearns the project on every run. - **Logins.** Sites ask for passwords and second factors again. What you get in return is a clean state. Nothing piles up, nothing drifts, and a bad run leaves nothing behind. ## What does persistent cost you? - **Drift.** What works today depends on what the agent installed last week. Snapshot a known-good state so you can go back to it. - **Secrets pile up on disk.** Tokens written to files and cookies in the browser profile stay. Forks and snapshots copy files as they are, credentials included. Keep API keys off the disk with Secret Proxies. - **Storage.** You keep paying for disks you no longer use, so delete them when you're done. - **Processes don't survive a stop.** A stop keeps the disk, not memory, so services must start again after a resume. ## Can I have both? Most real setups mix the two, and Sanbox supports both shapes: - **Persistent.** A Computer isn't deleted automatically while your account is active. Stop it when it's idle and resume it when you need it. - **Fresh copies of a prepared state.** Prepare a Computer once, stop it and snapshot it, then start a new copy for each job and delete the copy afterwards. A warm pool keeps up to five ready copies, so a new one can start in under a second. - **One-shot tasks.** `sanbox run "task" --template --input --wait --json` runs one OpenCode task, and `sanbox batch` runs many in parallel. A task run's disk is kept until you delete it. ```bash sanbox runs stop --wait --json sanbox snapshots create --run --name clean-start --wait sanbox run --snapshot clean-start --json sanbox runs delete --yes --json ``` ## How do sandbox providers handle persistence? The line between the two keeps moving, so check each provider's defaults rather than its label. Two examples from current documentation: - **E2B.** Pausing a sandbox saves its filesystem and memory, including running processes, and a paused sandbox is kept until you kill it. A running sandbox can run for up to 24 hours at a time on the Pro tier and 1 hour on Hobby. - **Daytona.** Stopping a sandbox keeps its filesystem and clears memory. Sandboxes stop after 15 minutes without activity unless you change that, and stopped container sandboxes are archived after 7 days by default. A Sanbox Computer works differently from both: it runs until you stop it, a stop keeps the disk but not memory, and a stopped Computer isn't deleted automatically. ## When Sanbox is not the right fit - **High-volume code execution** where each call is a few lines and start time per call is what matters most. A code-execution sandbox is built for that. - **You need memory restored**, with processes continuing mid-step after a pause. Sanbox resumes with a fresh boot from the saved disk. - **You need machines that stop themselves when idle.** OpenCode and Hermes Computers run until you stop them, from the console, the CLI or your own code. - **You need GPUs.** Sanbox Computers don't have them. ## Related - [What is an agent computer? Sandbox vs Computer vs VPS](https://sanbox.cloud/kb/agent-computers/what-is-an-agent-computer/) - [What survives when an agent's computer stops?](https://sanbox.cloud/kb/agent-computers/what-survives-a-stop/) - [How do I make agent computers start instantly?](https://sanbox.cloud/kb/build/warm-pools-and-snapshot-templates/) - [Sanbox vs E2B](https://sanbox.cloud/compare/sanbox-vs-e2b/) - [Sanbox vs Daytona](https://sanbox.cloud/compare/sanbox-vs-daytona/) ## Sources - [E2B: Sandbox persistence](https://docs.e2b.dev/sandbox/persistence), pause, memory and retention (checked 2026-11-06) - [E2B: Sandbox lifecycle](https://docs.e2b.dev/sandbox), continuous runtime limits (checked 2026-11-06) - [Daytona: Sandboxes](https://www.daytona.io/docs/en/sandboxes/), states, auto-stop and auto-archive defaults (checked 2026-11-06) ## Next step Talk to us at sales@sanlabs.ai. Sanlabs' forward-deployed engineers build agent use cases with your team, with experience in aviation, pharmaceuticals, supply chain and logistics, and internal admin workflows. How we work: https://sanbox.cloud/kb/teams/forward-deployed-engineering.md Existing customers can use Sanbox from a coding agent: install the CLI with `npm install -g @sanlabs/sanbox-cli@latest`, sign in with `sanbox login`, then run `sanbox skill` for the full agent guide.