Short Tasks vs Long Tasks
Most agent sandboxes were designed for one job: run a snippet the model wrote, return stdout, throw the environment away. That shape works for a data-analysis turn or a quick test run. It stops working once the agent is porting a codebase overnight or grinding through a week-long refactor.
A long run spends most of its wall-clock time not executing. The agent waits on a model call, waits on a human review, or sits idle until a scheduled job wakes it. A sandbox with a hard lifetime cap forces the harness to checkpoint and rebuild state every time it expires. Each rebuild reinstalls dependencies, restarts dev servers, and loses whatever was in memory.
| Snippet sandbox | Long-running sandbox | |
|---|---|---|
| Typical task length | Seconds to minutes | Hours to weeks |
| State between tasks | Discarded | Kept on disk and in memory |
| Idle gaps | Rare | Most of the wall-clock time |
| Failure recovery | Retry from scratch | Resume or restore a snapshot |
| Toolchain | Language runtime | Docker, databases, browsers, dev servers |
What a Long-Running Sandbox Needs
No lifetime cap
The environment lives as long as the task does. Freestyle VMs can run indefinitely, which removes the checkpoint-and-rebuild loop from the harness.
Memory-preserving pause
Idle time should cost nothing in compute and nothing in state. Pausing should freeze processes and memory, not just the disk.
Full virtualization
Agents install things. Docker-in-VM, FUSE, eBPF, and nested virtualization all show up in real repos. If it runs on EC2, it should run here.
Per-user addressing
Agent products serve many customers. Keying each environment by user or project, with scoped access, keeps tenants from colliding.
Freestyle VMs are built around this list. They are full Linux VMs for long-running, complex tasks, provisioned in milliseconds with a p99 under 400ms. Slugs let you key a VM by user or project, identities scope access, and VPCs isolate tenants at the network layer.
Pause Without Losing State
The important primitive for long runs is pause. On Freestyle, vm.pause() freezes the VM and saves its memory. vm.start() resumes the same processes at the same point, with open files and in-memory state intact. A VM can sit paused for weeks and come back in that exact state.
Two details make this practical for agent harnesses. An idle timeout pauses a VM automatically when it has no network activity, and the next request that reaches it wakes it back up. And files stay readable while the VM is paused, so a dashboard can show the agent's workspace without paying to resume compute. The full state machine is in the Freestyle VM lifecycle docs.
Stopping a VM keeps the disk but discards memory, so the next start is a fresh boot. For an agent that has a dev server, a warm build cache in RAM, or a half-finished interactive session, pause is the one you want.
Sizing for Real Toolchains
Small sandboxes fail in ways that look like model mistakes. A test suite that OOMs at 2GB reads to the agent as a flaky test. A build that takes twenty minutes on one vCPU burns the agent's patience and your token budget on polling.
Freestyle VMs go up to 64GB of RAM on public tiers, further on enterprise. Resizing is live: CPU and memory come online on a running VM without a reboot, and the disk grows in place. Resizing only goes up, so start with the shape the task needs and grow when the agent hits a wall.
When a Short-Lived Sandbox Is Fine
Persistence is not free to reason about, and not every workload needs it. Freestyle's own guidance on when to use it is direct about the cases where it is the wrong tool:
Tasks under ~15 minutes
If the average task finishes in a few minutes and is cheap to retry, persistence and recovery buy little.
Pure snippet execution
Running short Python scripts from a chat turn does not need a full VM. Benchmark, but a lighter sandbox may fit better.
Sustained CPU-bound CI
Kernel builds and similar sustained CPU workloads are better on providers offering consumer-grade single-core performance.
Production app hosting
Agent VMs are workbenches. There is no autoscaling, load balancing, or CDN, and that is on purpose.
Keeping the Agent Lucid
A persistent environment solves half of the long-run problem. The other half is the agent's context window. Over hours, search results and tool output pile up until the constraints from the start of the task are buried. We covered this in The Long-Running Agent Era.
Two things help. WarpGrep runs code search as a sub-agent and returns the relevant lines instead of whole files. Compact shrinks accumulated context by 50-70% while keeping surviving sentences verbatim. Pair them with a sandbox that never forgets its state, and the agent keeps working at hour seven the way it did at minute seven.
Frequently Asked Questions
What is a long-running agent sandbox?
An isolated environment, usually a VM, that an AI agent can work in for hours, days, or weeks. Unlike snippet sandboxes, it keeps its disk and processes across idle gaps and can be paused and resumed in the same state.
Why not just use a container for long-running agents?
Containers share the host kernel and usually restrict things agents end up needing: Docker, FUSE, eBPF, and full Linux networking. A full VM runs anything an EC2 instance can run, which matters when the agent is building and testing a real codebase.
Do I pay for a paused agent sandbox?
It depends on the provider. On Freestyle, a paused VM stops using compute and does not count against the concurrent VM limit, but it still holds its disk and saved memory as a saved VM. Current plan details are on the Freestyle pricing and limits page.
When is a short-lived sandbox the better choice?
When tasks finish in under about 15 minutes and are cheap to retry, or when the agent only runs short Python snippets. Persistence and large VMs buy nothing if the work never outlives a single request.
Give Long Runs a Clean Context Window
WarpGrep and Compact keep long-running coding agents focused on the code that matters. OpenAI-compatible, drop into any harness.