Sandbox Fit for Multi-Step vs Single-Shot Agent Tasks

The clearest empirical signal here is METR's Time Horizon benchmark, which measures the length of task, calibrated in equivalent human professional time, that a model completes autonomously at 50% probability. Like all benchmarks, it is imperfect, but it gives the field a consistent ruler.

The progression is striking. In early 2024, frontier models could sustain roughly four minutes of autonomous work at that threshold. By late 2024, that figure had grown to somewhere between fifteen and thirty minutes. By mid-2025, Claude Opus 4.5 reached approximately four hours and forty-nine minutes, a 67% improvement over the prior state-of-the-art. By February 2026, Claude Opus 4.6 had crossed a full workday at roughly fourteen and a half hours. METR's May 2026 Frontier Risk Report put the most capable shared model at sixteen to twenty hours on the 50% horizon, with the 80% threshold sitting at three to four hours. METR also found the 50% time horizon had doubled roughly every seven months, possibly accelerating to every four months through 2024.

Less discussed, though present in the same research, is a performance cliff that most infrastructure conversations skip past. Models approach near-perfect success on tasks a skilled human completes in under four minutes. That success rate falls below ten percent on tasks requiring more than roughly four hours of equivalent human effort. There is also a long-context degradation signal: success rates of forty to fifty percent on short-horizon task variants fall below ten percent once the same task is embedded in a longer interaction history, even when the relevant information is technically still in context.

That last finding is worth sitting with. It suggests sandbox architecture is not merely a container problem; it is a cognitive scaffolding problem. An infrastructure decision that fragments an agent's working context could be making the degradation curve steeper than it needs to be. But what if the infrastructure itself is encoding a known model failure mode directly into the system design?

The infrastructure implication follows directly. Multi-hour autonomous tasks are now routine at the frontier, not edge cases. A sandbox designed for sub-minute executions is already the wrong default for production agent workloads, and the gap is widening each quarter.

What single-shot tasks actually need from a sandbox

A single-shot task is one inference call, one result, execution ends. The sandbox's job is to contain the blast radius and return output.

Four requirements actually matter here: isolation strength, hard resource caps, auto-destruction, and cold start latency. Isolation strength means preventing agent-generated code from reaching the host system or adjacent sessions. Hard resource caps, configurable per task, mean a linter isn't provisioned like a full test suite. Auto-destruction means the sandbox tears itself down after completion or a timeout, leaving no orphaned resources and no cross-run state leakage. Cold start latency matters because there is no warm state to resume; the task starts cold every time.

On cold start specifically, the tradeoffs are real and measurable. Firecracker microVMs offer kernel-level isolation but add somewhere between 150 milliseconds and two seconds. Browser isolates start under 50 milliseconds but support fewer languages. gVisor lands between them on both dimensions. The choice depends on what the task demands, not on what sounds most secure in a security review.

Network isolation should be the default: no outbound access unless explicitly allowlisted. Single-shot tasks rarely need live egress, and the attack surface is narrowest when the network is simply closed.

These are not hypothetical concerns. Claude Code wiped a user's entire Mac home directory via a trailing character in an rm -rf command. Cursor IDE deleted seventy files despite an explicit "DO NOT RUN ANYTHING" instruction. Replit's AI agent deleted an entire production PostgreSQL database during a code freeze. According to Veracode's 2025 report, 45% of AI-generated code fails security tests. Containment is mandatory, not optional, even for the simplest one-shot use case.

What single-shot tasks do not need: persistent filesystems, checkpointing, resumable state, or session duration beyond the task's natural runtime. Adding those is waste, and added attack surface.

Where single-shot sandboxes break down for multi-step agents

Consider a concrete workflow: an agent asked to build a feature must clone a repository, install dependencies, run tests, iterate on a fix, and re-run tests. If each tool call spins up a fresh ephemeral sandbox, the agent reinstalls everything from scratch on every invocation. The compute waste is obvious. The less obvious problem runs deeper.

In a multi-step sequence, a bad decision in step two corrupts step three, which corrupts step four. An ephemeral sandbox that resets between steps doesn't preserve the error context needed to diagnose or recover. The agent loses its working memory of what went wrong, and the next iteration starts from a clean slate that carries none of the prior failure's signal.

State accumulation is productive work, not overhead. Crawled datasets, installed dependencies, conversation history, warm caches: every sandbox expiration discards work already completed. The METR long-context degradation finding compounds this. Even when information is technically available, agents lose effective access to it as interaction history grows. A sandbox architecture that fragments history across ephemeral sessions makes that degradation structurally worse, encoding a known model failure mode directly into the infrastructure.

Ephemeral sandboxes fail multi-step agents not because they are insecure. They fail because they have no memory of what happened. That raises an important question: if the infrastructure itself is discarding the signal a model needs to recover from errors, how much of what looks like model unreliability is actually an infrastructure problem?

The four requirements that define multi-step sandbox fit

State persistence is the foundational requirement. Filesystem, memory, and running processes must survive between sessions without requiring the agent to rebuild context. Two implementation paths exist: externalized state, where everything is written to attached volumes or object storage outside the sandbox boundary and reattached to a fresh environment on resume; and native persistence, where the sandbox retains its own filesystem state across executions. Externalized state preserves ephemeral security guarantees while supporting stateful patterns. Native persistence is simpler but ties state lifecycle to the sandbox instance.

Resume latency is distinct from cold start latency, and collapsing them is a common miscalibration. Cold start latency of 150 milliseconds to two seconds compounds across sequential agent tool calls. Under load, what feels acceptable for one session becomes a bottleneck queue for fifty concurrent ones. Pre-warmed pools reduce perceived latency but require sizing logic and idle cost management, a tradeoff teams rarely model before they need to.

Fault tolerance and checkpointing addresses what happens when the container dies mid-task. The answer cannot be "start over." Snapshotting plus rehydration, saving sandbox state at checkpoints and restoring it in a new container, lets the workflow continue from the last known-good step. Long-running agents also require retries, policy checks, and human approval gates for sensitive actions. These cannot be bolted on after the fact; they need to be structural.

Error isolation across steps is the fourth requirement. A failure in step five must be recoverable without corrupting accumulated state from steps one through four. Permission boundaries and workspace isolation prevent a bad tool call from cascading backward into earlier work. Logs and traces at each step are non-optional: you need to know which step broke, not just that the final output failed.

Session duration is the implicit container for all four. Tasks that take frontier models fourteen-plus hours of equivalent work require platforms that don't hard-kill sessions at arbitrary timeouts. That ceiling, wherever a platform sets it, is a hard constraint on the class of tasks the system can actually complete.

Security threat model shifts when the agent runs for hours, not seconds

For single-shot tasks, the threat window is short, the surface is narrow, and teardown is the primary remediation. A bad execution ends when the sandbox ends.

For multi-step tasks, a compromised or misbehaving agent accumulates access and influence over hours. The longer the session, the more damage a prompt injection or supply chain compromise can cause before detection. The Shai-Hulud supply chain campaigns in late 2025 compromised hundreds of npm packages specifically targeting AI agent workflows. A persistent sandbox that installs packages and retains them across sessions carries that risk forward across the full session lifetime, not just the installation step. The threat surface is not merely larger; it is temporally distributed in ways that conventional security tooling, designed around discrete events, handles poorly.

Network isolation matters more in persistent sandboxes, not less. The default should be no outbound access, with specific domains explicitly allowlisted. Persistent sessions have more opportunity to exfiltrate accumulated state, and that opportunity surface grows continuously with session duration.

Credential separation becomes structurally non-negotiable at scale. Teams must separate the harness and compute layers so that model-generated code never executes in the same environment where credentials live. For a single-shot task, this is good hygiene. For a multi-step agent iterating on its own tooling over hours, it is load-bearing architecture.

Human approval gates for sensitive actions, file deletion, external writes, and production deployments are a structural requirement for long-horizon tasks, not a UX feature. The longer the task runs, the more a single unchecked action can compound into irreversible damage. Teams that learn this lesson in postmortems tend to remember it.

How the current platform landscape maps to these two task types

Platforms don't divide cleanly into "single-shot" and "multi-step" products. They differ on persistence model, session duration limits, resume latency, and isolation strength. Those four dimensions determine fit more accurately than any marketing framing does. It is also worth considering how each platform's design choices reflect assumptions about task duration, assumptions that may no longer match what frontier models actually require. Daytona, for instance, is built around sandboxes that run indefinitely so agents can resume long-running work without hitting an arbitrary session ceiling.

Several persistence models are in production. Pause-and-resume with time limits, represented by platforms using Firecracker microVMs with paused sessions up to thirty days and snapshotting with a thirty-day default, suits multi-step tasks with predictable session gaps. Snapshot-and-restore for workflows extending beyond standard session limits is represented by platforms that use gVisor, support twenty-four-hour sessions with longer workflows via snapshots, and scale to fifty thousand or more concurrent sessions with starts in under one second. GPU access inside sandboxes is a differentiator for tasks that include model inference steps.

Indefinite standby at zero compute cost is a distinct category. Blaxel resumes in under twenty-five milliseconds with full filesystem and memory state intact and currently offers unlimited standby duration where no competing provider does, positioning it specifically for tasks where session gaps are unpredictable. Northflank, using microVM and Kata container isolation with volumes from a few gigabytes to sixty-four terabytes, supports unlimited session duration for tasks that simply cannot be interrupted.

Cold start speed matters most for single-shot tasks. Resume latency is the relevant metric for multi-step tasks. A platform optimized for fast cold starts may perform poorly on resume; those are different engineering problems with different solutions, and conflating them is how teams end up benchmarking the wrong dimension.

The scale signal confirms that this demand is real. One major sandbox provider grew from roughly forty thousand sandbox sessions per month in March 2024 to approximately fifteen million per month by March 2025. AI agent pull requests on GitHub grew from four million in September 2025 to more than seventeen million by March 2026.

The hybrid architecture that handles both task types in one system

Gartner projects that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024. Systems being built today will need to handle a widening mix of task types from the same infrastructure. Designing for one profile and ignoring the other is a bet that production workloads will stay uniform, and that bet has a poor historical record.

The hybrid pattern routes by task type at the workload level, not the platform level. An ephemeral pool handles stateless single-shot executions: fast cold starts, clean teardown, no idle cost from state retention. A persistent environment handles multi-step workflows: retained filesystem and process state, checkpointing, longer session limits. Both can run on the same underlying platform if that platform supports per-workload configuration, which not all of them do.

Externalized state serves as the bridge between modes. Writing all meaningful state outside the sandbox boundary lets single-shot environments serve stateful patterns when needed. A new ephemeral container reattaches external state rather than resuming the original environment, preserving most of the security properties of ephemerality while supporting continuity. The tradeoff is engineering overhead, and it is real.

A practical calibration tool: ask how long the equivalent human work would take. Tasks under a few minutes of equivalent effort fit ephemeral infrastructure. Tasks that would take a human an hour or more require persistent infrastructure. The METR time horizon data gives this a concrete anchor.

The failure mode worth anticipating is treating the sandbox decision as a one-time infrastructure choice rather than a per-workload routing decision. The cost of that error is either over-provisioned persistence for simple tasks, which is waste, or broken multi-step workflows forced into ephemeral containers, which is a category mismatch that surfaces as model reliability problems. It usually takes a few hours in execution logs to find the reset. Those hours tend to concentrate the mind on the routing decision that should have come earlier.