Persistent Sandbox for AI Agents: How to Keep State Between Runs

The one-shot agent is giving way to the agent that works in shifts. The length of tasks agents can complete on their own keeps growing, and coding, research and data agents now run for hours, across many sessions, with long waits for a model, a tool or a person in between.

That makes the machine an agent runs on part of its memory. A persistent sandbox is an isolated cloud machine that keeps an agent's files, installed packages and running processes between sessions, so the agent picks up where it stopped instead of rebuilding its environment every time. This guide covers why persistence matters now, what you can run in a persistent sandbox, how Solari keeps one alive, and where long-running agents are heading.

Why Do AI Agents Need a Persistent Sandbox Now?

The first generation of agent sandboxes was built for one-shot code: start a clean machine, run a snippet, return the output, throw the machine away. That works when the job takes seconds. It breaks when the job takes an afternoon.

Long-running agents work in discrete sessions, and each new context window starts with no memory of the last one. Anthropic's engineers describe how they bridge those sessions with progress files and git commits that the next session reads first. Those notes only help if the machine they sit on is still there, with the repository cloned, the dependencies installed and the dev server ready to start.

Rebuilding that environment on every run costs time and tokens, and it adds a failure point to every session. A persistent sandbox removes the rebuild: the environment outlives the session, and every new session starts on the machine the last one left behind.

What Does a Persistent Sandbox Keep?

A persistent sandbox keeps state in one of four ways, and each fits a different wait. Pausing saves the whole running machine, a snapshot saves a copy you can return to, a volume keeps one folder of data across machines, and destroying a machine keeps nothing.

The difference matters for how you design an agent. Pause is for the gaps inside one job, such as a slow model call or a person reviewing a diff. A snapshot is a named save point: rewind to it after a bad change, or start fresh copies from it. A volume is for data that many machines read and write over time, like a package cache or model weights.

What Can You Run in a Persistent Sandbox?

Any agent whose work spans more than one session gains from a machine that stays. These are the jobs teams move to persistent sandboxes first:

• Coding agents that work in shifts. The agent clones the repository, installs dependencies and runs the test suite once, then pauses between sessions. The next session resumes on the same machine with the same files and processes, so it starts on the next feature instead of the setup script.

• Data analysis that keeps its variables. The agent loads a dataset into Python once and keeps querying it across many calls. Variables, imports and loaded data stay in memory, so each new question runs against work already done.

• Agents that wait for a person. A pull request, a refund or a migration often needs a human sign-off before the next step. The agent pauses its sandbox while it waits, and resumes with everything in place the moment someone approves.

• Trying several fixes at once. The agent snapshots a machine just before a risky change, then starts several copies from that snapshot and tries a different fix in each. It keeps the copy whose tests pass and deletes the rest.

• Background jobs that outlast the client. A long build, a crawl or a data export keeps going after the agent's own process disconnects. The agent checks back later and reads the output and exit status where the job left them.

• Shared caches and datasets. One folder of packages, model weights or scraped output is mounted into each new machine. The tenth machine starts with the same data as the first, without downloading it again.

Each job needs a machine that pauses without losing state, wakes quickly and stays isolated from everything else the agent runs. That is the problem Solari sandboxes were built to solve.

How Does Solari Keep a Sandbox Persistent?

Solari sandboxes are isolated Linux machines created by API, with commands, files, code execution, pause and resume, snapshots and forks. Your agent brings the logic; Solari keeps its machine.

• Pause and resume. Call pause() and Solari saves the machine's state; the next connect() picks up right where it left off. A paused VM does not count against your limit on running VMs, and a paused Solari VM resumed on the same host in about 1.3 seconds on staging, across five trials.

• Idle timeouts that pause instead of delete. Set an idle timeout when you create a sandbox, and the default lifecycle pauses it once that time passes with no activity. An agent that forgets to clean up leaves a paused machine it can resume, not a lost one.

• Snapshots, revert and fork. Solari snapshots save a running machine's disk and memory without stopping it. Your agent can revert the same machine to a snapshot and keep its id, or start many independent copies from one prepared snapshot. Stored snapshots cost $0.05 per GB-month, with the first 10 GB free.

• Volumes for data that outlives machines. A Solari volume is durable storage you mount at a path when a sandbox starts. Data written there survives the machine and reappears when the same volume is attached to a fresh one.

• State inside the machine, too. Named shells keep the working directory, exported variables and background jobs from one call to the next, and runCode remembers Python variables and imports between calls. Background executions keep running, with their output and exit status, after your client disconnects.

• Isolation that matches the code. Each dedicated sandbox is a microVM of its own on a hypervisor, and hardened isolation blocks all outbound network for code you do not trust. Git credentials travel with a single command and are never left behind on the machine.

• Fast starts at fleet scale. A Solari machine starts usually in about a second, and with Solari you can run up to 100,000 sandboxes at once. Your agent can fork one prepared machine into a whole fleet without waiting on setup.

Sandboxes are one of three surfaces on one Solari account. Solari desktops give a computer-use agent a full Linux screen with the same pause and snapshot lifecycle, and Solari profiles keep a browser agent signed in between runs. Pinetree Research, the company behind Solari, runs its own marketing system in a Solari sandbox. Solari is also about 1.3x faster than E2B on a sandbox's full lifecycle and almost 3x cheaper per sandbox hour.

Where Are Persistent Agents Going Next?

Today most agents still treat their machine as disposable. Over the next year that changes in four ways:

• From sessions to standing workers. Agents will keep one machine for the life of a project, paused between tasks and resumed on a schedule or a message. Starting from a clean machine every morning will look as odd as a developer reinstalling their laptop each day.

• Checkpoints as standard. Long jobs will take checkpoints on a timer, so a host failure costs one interval of progress instead of the whole run. Solari VMs already take durable checkpoints on an interval you set when you turn it on.

• Branching as a search strategy. Agents will fork a machine into many copies to try several plans in parallel and keep the best result. Engineers already work this way with branches; agents will do it with whole machines.

• Teams of agents from one starting point. A coder, a tester and a reviewer will each start from the same prepared snapshot, in their own isolated machines. They will hand results to each other through files instead of rebuilding environments.

What stays human is the judgment around the work: which job is worth running, which fix to merge, and what an agent may touch. The teams that win will give their agents machines that remember, and keep their people on the decisions.

Get Started With Solari

Solari is the younger company in agent infrastructure, and it moves faster on speed and price. Start with one job, such as a coding agent that pauses its sandbox between sessions, then add snapshots and forks once it runs cleanly. Solari is the fastest and cheapest way to run cloud browsers and VMs for long-running AI agents. Get started with a free account and start running your agents today.