Searching Over Sandbox States for Coding Agents

Coding agents often make substantial progress before they fail. An agent might install dependencies, modify several files, populate a database, configure a service, and then make one incorrect decision near the end of the trajectory.

A normal retry throws away that execution state and starts again from the original environment. We wanted to understand whether preserving intermediate machine states could make retries more efficient.

We tested this using a Go-Explore-inspired search strategy. During an agent rollout, we periodically captured full Daytona sandbox snapshots. If the original trajectory failed, another agent could restore one of those snapshots and continue from that machine state with a fresh model context.

Our initial hypothesis was that this would outperform repeatedly starting from scratch under the same inference budget. On the Terminal-Bench tasks we tested, however, independent retry solved 17 of 25 task-seed pairs, while snapshot branching solved 6 of 25.

That result shifted the focus of the project from whether snapshots could preserve progress to understanding when preserved state was actually useful.

Saving And Reusing Agent Progress

A coding agent changes more than source files. Important progress may also live in packages, services, databases, and other environment state.

A Git diff captures some of this progress, but it cannot represent all of it.

A full sandbox snapshot can.

Instead of treating a rollout as one continuous attempt, we can think of it as a series of machine states. One state might have a new library installed, the next might include a function built with that library, and a later state might have tests passing or a database already configured.

S0 → S1 → S2 → S3 → ... → Sn

A normal retry returns to S0. Snapshot-based search allows another trajectory to return to an intermediate state and explore a different continuation.

In practice, a root trajectory produces intermediate snapshots that can later be restored as starting points for new child trajectories.

This approach builds on the core idea behind Go-Explore, which showed that remembering promising states, returning to them, and exploring again can work well on difficult reinforcement learning problems. In simple terms, the system needs to reliably return to a state it has seen before and continue from there. Daytona gives us that ability for coding agents by restoring a saved sandbox and letting a new trajectory branch from it.

The challenge is that a coding-agent state can be much larger than a typical reinforcement learning state. It may include source files, Git metadata, installed dependencies, databases, services, caches, and generated artifacts. This gave us several ways to checkpoint agent progress, from lightweight source-level state to a full sandbox snapshot. Our hypothesis was that preserving more of the environment would give later agents a better starting point, especially once useful progress extended beyond the repository.

We also verified that full sandbox restoration worked reliably. Across 24 intermediate environments, all 24 restored successfully, including details such as an unresolved Git merge and its corresponding Git index state.

With restoration working, the more important question was whether returning to those states actually helped the agent.

Snapshot Search Versus Independent Retry

For the main experiment, we selected five Terminal-Bench tasks with intermediate difficulty and evaluated five seeds per task. Every seed received a total budget of one million tokens.

Independent retry divided the budget across three fresh attempts. Snapshot search used one root trajectory followed by up to two children restored from intermediate snapshots.

We created checkpoints around signals of progress, such as file changes and test runs, then used those signals to select promising states for the children to continue from. This selection was intentionally simple, and deciding which states were actually worth revisiting turned out to be one of the harder parts of the problem.

Both strategies therefore received the same total inference budget.

Independent retry solved 17 of 25 cases, or 68 percent.

Snapshot branching solved 6 of 25, or 24 percent.

Snapshot recovery was not completely ineffective. We observed several cases where the root trajectory failed and a child restored from that trajectory later completed the task. In a follow-up experiment, snapshot branches recovered 67 percent of failed roots on extract-elf.

The problem was that these successful recoveries were not common enough to compensate for the additional costs introduced by branching.

The experiments pushed us toward a more specific question: what kind of progress requires the full machine state to be preserved?

What Full Snapshots Preserve

The main Terminal-Bench experiment showed that a full snapshot was not always more useful than preserving only the source-level changes. On many coding tasks, most of the valuable progress already lives in the repository, so a Git diff can capture what matters while a new agent rebuilds the rest cheaply.

That changes when useful progress starts to live outside source control.

An agent may update a database, install system packages, configure a service, or create artifacts that are expensive to reproduce. In those cases, the repository no longer contains the full state needed to continue from where the previous agent left off.

This became the key distinction in our results. Some tasks can be resumed from source-level state alone. Others require preserving the broader environment.

We built an additional task specifically to test that second case.

When Progress Lives Outside Git

Our staged-service-repair task includes a SQLite database stored at:

/var/lib/inventory/store.db

The agent must modify both the repository and the database for the verifier to pass.

To isolate the effect of what state was preserved, we fixed the same intermediate checkpoint for every condition. The clean restart, Git-diff restore, and full-snapshot restore all began from this same point in the task and received the same remaining budget of 200,000 tokens. The only difference was how much of the previous environment each condition preserved.

Across five seeds, the clean restart solved 0 of 5 attempts, the Git-diff condition solved 0 of 5, and the full snapshot solved 4 of 5. The sample is small, but the failure mode is concrete. The Git-diff condition restored the same source changes while losing the database state required to finish the task..

Successful snapshot continuations finished using approximately 21,000 to 41,000 tokens.

When a snapshot preserves the right state, the next agent can spend tokens solving the remaining problem instead of reconstructing work that was already done.

This gives snapshots a more specific role than simply making retries faster. They provide a checkpoint representation for agent progress that exists outside the repository.

That becomes increasingly important as coding agents move beyond isolated source-editing tasks and interact with databases, services, package managers, browsers, clusters, virtual machines, and other persistent systems.

As agents move from editing files to operating databases, services, package managers, and other stateful systems, preserving the full environment becomes increasingly important.

What Makes Snapshot Branching Difficult

The experiments exposed several recurring costs of branching from intermediate environments. The main ones were deciding which state to restore, dividing inference across branches, inheriting mistakes from the parent trajectory, and reconstructing the context behind the restored machine.

One of the clearest problems was that snapshots preserve mistakes just as well as they preserve progress. If the parent agent makes a wrong assumption and builds a substantial implementation around it, a child restored from that state may continue refining the same approach instead of reconsidering it.

A fresh retry loses the previous work, but it also starts without those assumptions. This creates a tradeoff between preserving progress and preserving diversity across attempts.

There is also a handoff cost. The snapshot restores the machine, but not the parent agent's understanding of why that machine looks the way it does. The child may need to inspect files, rerun tests, and reconstruct the reasoning behind earlier changes before it can make useful progress.

We saw this directly in one trajectory. A restored child used roughly 190,000 tokens across 26 steps, while a successful fresh retry used about 90,000 tokens across 11 steps.

We also tested whether giving the child additional context about the parent trajectory would reduce this handoff cost. It helped in some cases, but the effect was inconsistent and did not materially change the overall result.

This makes the problem harder than simply restoring more state or attaching a better summary. The child still has to correctly interpret the restored environment and decide whether the previous trajectory is worth continuing.

Where This Becomes Useful

Terminal-Bench is heavily centered on repository state, which makes it a useful baseline but also limits how often full snapshots provide unique information.

The interesting cases are workloads where returning to an intermediate state is expensive or impossible to reproduce from Git alone.

An agent debugging a distributed service may have several processes configured and running. A database agent may have performed migrations or populated tables. A systems agent may have installed packages and changed machine configuration. A browser agent may have accumulated application state across a long interaction.

For these workloads, the machine is no longer just where the agent executes commands. It contains part of the trajectory's accumulated progress.

Snapshots make that progress addressable.

Instead of repeatedly reconstructing an environment from the beginning, an agent system can preserve intermediate machine states, branch from them, and decide where additional inference should be spent.

That turns the sandbox from disposable execution infrastructure into part of the search algorithm.

Conclusion

The main result from these experiments is that

Full-environment snapshots matter most when useful agent progress extends beyond the repository.

For file-centric tasks, source state may capture nearly everything worth preserving. For stateful tasks, important progress can live in databases, services, installed packages, generated artifacts, and the broader execution environment.

Full sandbox snapshots give us a way to preserve and revisit that state directly.

In our restoration experiments, all 24 of 24 intermediate environments were recovered successfully. On the SQLite task where critical progress lived outside Git, full snapshots solved 4 of 5 continuations while clean restart and Git-diff restoration solved 0 of 5.

The infrastructure problem is becoming tractable. We can save an agent's machine, restore it, and branch from that point.

The open question is how useful this becomes as agents take on longer-horizon work in databases, browsers, cloud infrastructure, distributed systems, CI/CD, and other stateful environments.