Burrowbox Blog
← All posts

Ephemeral sandbox vs persistent machine: what an AI agent keeps between runs

· The Burrowbox team · 7 min read

#Ephemeral sandbox or persistent machine: the short answer

Use an ephemeral sandbox when every run should start clean: running untrusted code, reproducible tests, one-off tasks that share nothing. Use a persistent machine when the agent needs something from last time: a signed-in browser, installed apps, files it wrote, or windows it left open.

Most comparisons of the two focus on code execution, where the state worth keeping is a cloned repo and some installed packages. An agent that uses a computer has more to lose, usually starting with a browser session it took a password and a 2FA code to get.

#What each model keeps

Here's what survives between runs in each model. The persistent column describes a Burrowbox machine after stop and start, as documented in Machines.

State Ephemeral sandbox Persistent machine (Burrowbox)
Files the agent wrote Gone Kept
Installed apps and packages Gone, unless baked into the image Kept
Browser cookies, including session cookies Gone Kept
Open browser tabs and desktop windows Gone Reopened on start
Stored credentials (the vault) Gone Kept
Running processes and memory Gone Not kept: programs are relaunched

A Burrowbox stop snapshots the whole filesystem and records the open windows and tabs, but it doesn't keep memory. A script that was halfway through a loop starts over. If your agent's progress lives only in a process, write it to a file.

Two more details from the docs:

  • While a machine runs, a save point is taken every 30 minutes. If a machine stops unexpectedly, lastStopMode is crashed and it restores from the last save point.
  • The default light browser keeps its cookies across stop and start, but a live agent update makes it forget sign-ins. The full browser (Chromium) keeps them in both cases, so pick "browser": "full" for machines whose logins you care about.

#Three ways a throwaway sandbox breaks a stateful agent

Starting an agent in a fresh environment every time tends to fail in one of three ways.

#It logs in on every run

The agent opens the CRM, gets a login page, types the password, and only then starts the task, every time. On a persistent machine the browser still has yesterday's cookies, so the next run often skips the login page.

#It reinstalls its toolchain

A sandbox that starts from a base image has to apt install the PDF tool, download the AppImage and configure the desktop app before it does anything useful. You can bake some of that into an image. You can't bake in per-customer setup, such as a desktop app signed in to that customer's account.

#It hits a 2FA prompt nobody can answer

If the account uses an authenticator app, a fresh sandbox needs a code on every login, and there's no one at the keyboard. On a Burrowbox machine you store the TOTP secret in that machine's vault once, and the browser_login tool fills the form and the code without the model seeing either:

curl -X PUT https://burrowbox.dev/api/machines/$MACHINE_ID/vault/crm \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"url": "https://crm.example.com/login", "username": "agent@acme.com", "password": "…", "totpSecret": "…"}'

Combine the two and most runs never see a login page at all: the session cookie is still there, and when it expires, the agent calls browser_login and signs in again without asking anyone for a code.

#When an ephemeral sandbox is the right call

A clean environment is the better default in plenty of cases:

  • Code a user uploaded, or a file you don't trust, should run somewhere you throw away afterwards.
  • Tests and evaluations should start from the same state every time. Leftovers from the last run make results hard to compare.
  • Ten research tasks that share nothing don't need to share a machine, and keeping them apart means one can't affect another.

Burrowbox covers this with warm pools. A claimed pool machine is brand new, nothing from other customers is on it, and pool machines are never reused after a claim. That's the model the Manus post builds on: a fresh machine per task, stopped when the task ends.

#The hybrid: a pool for tasks, a machine per customer

You rarely need to pick one model for everything. A common split:

  • Clean work goes to a machine claimed from a pool, set up from the pool's template, and stopped or deleted afterwards.
  • Stateful work goes to one persistent machine per user or customer, which holds their logins, vault, files and apps. This is the one-computer-per-user model.

The two look similar in code. A task machine comes from a pool:

curl -X POST https://burrowbox.dev/api/pools/pool_3fa91c/claim \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"externalId": "cus_8f2a", "ttlMinutes": 30}'

A customer's machine is created once, tagged with their id, and then started and stopped for each session:

# first time
curl -X POST https://burrowbox.dev/api/machines \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"name": "acme", "size": "tiny", "browser": "full", "ttlMinutes": 30, "externalId": "cus_8f2a"}'

# every later session
curl -X POST https://burrowbox.dev/api/machines/$MACHINE_ID/start \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"ttlMinutes": 30}'

With ttlMinutes, the machine turns itself off when the time runs out. The default onExpire is stop, which keeps all state. Either way the agent connects to the machine's mcpUrl with its mcpToken, as in the quickstart.

#What it costs to keep a machine

A persistent machine costs money while it's stopped, but not much. Per Billing, usage is charged by the minute:

  • Running: $0.07 an hour for tiny up to $0.26 an hour for large.
  • Stopped: $0.001 an hour, or $0.72 per 30 days, whatever the size.
  • Idle warm pool machines are billed like running machines.

Keeping state costs the stopped rate. Not keeping it costs the minutes each run spends signing in and reinstalling, billed at the running rate.

#Key takeaways

  • Ask what the agent needs from the last run. If the answer is nothing, use a clean sandbox.
  • For computer-use agents, the state worth keeping is mostly logins, installed apps and files.
  • A Burrowbox stop keeps the disk, vault, cookies and open windows and tabs, but not memory.
  • Many products need both: pool machines for isolated tasks, and a persistent machine per customer.

#FAQ

#Does a persistent machine keep running processes?

Not on Burrowbox. Stopping keeps the filesystem and reopens windows and tabs on the next start, but memory isn't kept, so running programs are relaunched. Some sandboxes do keep memory: E2B's pause saves the filesystem and memory, including running processes, and a paused sandbox is kept until you delete it (E2B docs). Burrowbox isn't involved with E2B.

#Is an ephemeral sandbox more secure?

It limits what one run can leave behind for the next. A persistent machine per customer keeps customers apart from each other instead of runs apart from each other: each machine has its own disk and vault, and its mcpToken is scoped to that machine. Use a fresh machine for untrusted code even if the customer also has a persistent one.

#Can an agent stay logged in between runs?

Yes, on a persistent machine. Stop snapshots the browser's cookies, including session cookies, so the next start comes back signed in until the site expires the session. Use "browser": "full" so live agent updates don't sign it out, and keep the credentials in the vault for when the session does expire.

#How do I get rid of a persistent machine?

DELETE /api/machines/{id} permanently deletes its files, apps, vault, browser profile, snapshots, scheduled jobs and webhooks. It can't be undone.

Create an account and try a machine that keeps its state.

#Sources