Sanbox By Sanlabs

Guides

Agent computers explained

Explainer

Persistent vs ephemeral sandboxes for AI agents: which do I need?

By the Sanbox team updated

Ask ChatGPT Ask Claude

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 doesChooseWhy
Runs a snippet the model wrote and returns the outputEphemeralNothing to keep, and a clean machine each time is the safest default
Builds or runs third-party code you don't trustEphemeral, with no credentialsThrow the machine away afterwards
Grades many eval tasks from identical starting pointsEphemeral copies of a prepared stateEach attempt needs a clean environment; a snapshot removes the setup time
Reviews some files and writes a reportEphemeral taskInputs go in, outputs come out, nothing else matters
Works on a repository across daysPersistentThe repo, dependencies, build caches and session history carry over
Logs in to websitesPersistentCookies and signed-in sessions live in the browser profile on disk
Runs a database or dev server it uses again tomorrowPersistentImages and volumes stay; containers with a restart policy start again after a resume
Acts as an always-on assistant with memory, email or TelegramPersistentMemory, learned skills and channels are the product
Serves one end user of your productPersistent, one per userEach 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 <task-template-id> --input <path> --wait --json runs one OpenCode task, and sanbox batch runs many in parallel. A task run's disk is kept until you delete it.
sanbox runs stop <run-id> --wait --json
sanbox snapshots create --run <run-id> --name clean-start --wait
sanbox run --snapshot clean-start --json
sanbox runs delete <copy-run-id> --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.

Sources