# 1. The work outlives the machine

Source: https://archil.com/guides/storage-for-agents/the-work-outlives-the-machine · Part of The buyer’s guide to storage for AI agents · Facts checked 2026-11-04

**The short answer:** An agent’s sandbox is disposable. Providers stop it when it sits idle, and its host can be retired with little warning. The workspace, meaning the repository, packages, databases, and notes, has to outlive every one of those machines, which sets six requirements that no classic storage design meets at once.

Follow one coding agent through a day. In the morning it clones a repository into a fresh sandbox, installs its packages, and creates a SQLite database for its tests. Then it asks a person to review its plan, and while it waits, the sandbox’s idle timer stops the machine. The person replies before lunch, and the agent picks up on a different host. That host is retired early in the afternoon, so the agent moves again. Later it tries three fixes at once, each in its own sandbox, and keeps the one whose tests pass. The next morning, it starts where it left off.

Count the machines, and there are seven. Count the workspaces, and there is one. Everything the agent did lives there: the repository and its history, the installed packages, the build output, the test database, and the notes the agent wrote for its next run. Every machine did its job and was thrown away. If the workspace had gone with any of them, the day’s work would have gone too.

**One workspace, a day of machines**

One workspace across a day of machines, from 09:00 to 18:00 and on to the next morning. Sandbox A clones a repository and runs `npm ci`, writing `repo/`, `node_modules/`, `app.db`, and `notes.md` into the workspace, and its auto-stop ends it at about 09:40. Sandbox B resumes on a second host at 11:00 and runs until that host is retired at 13:30. Sandbox C picks up on a third host. At 15:00, three attempts run at once on sandboxes D, E, and F, each on its own branch of the workspace, and at 16:00 the attempt that passes its tests is kept and the other two are thrown away. The workspace waits overnight, and sandbox G picks up again at 09:00 the next day. Seven machines, one workspace.

This guide is about that workspace: what it needs from storage, the designs teams build for it and where they break, why the problem is harder than it looks, and what it costs. This chapter starts with the two facts the rest of the guide depends on. The sandbox is disposable, and the workspace isn’t.

## A machine built to be thrown away

A sandbox exists to run code that nobody has reviewed, somewhere that code can’t do harm. The cheapest clean room is a new one, so sandboxes are built to be created on demand and thrown away afterward. A sandbox is a machine rented for the length of a task. The provider places it on whichever host has room, and each of the providers in the next figure builds in a timer that stops it. E2B’s default timeout ends a sandbox and its state, unless you set the sandbox to pause instead. Modal’s sandboxes end at a default timeout too, and Daytona stops a sandbox that sits idle. Ours pause when they sit idle, and no session runs longer than a day. (From each provider’s documentation, as summarized on our comparisons with [E2B](https://archil.com/compare/e2b), [Modal](https://archil.com/compare/modal), [Daytona](https://archil.com/compare/daytona), and [Vercel Sandbox](https://archil.com/compare/vercel-sandbox), and from our own [limits](https://docs.archil.com/reference/limits). These are defaults, and most of them can be changed.)

Stopping is often gentler than it sounds. E2B can pause a sandbox and keep its memory and files, and Daytona keeps a stopped sandbox’s files, archiving them after 7 days. But a paused sandbox keeps its files with that one sandbox. When the agent’s next step runs on another machine, or as three attempts at once, the files have to be somewhere that every one of those machines can reach.

Underneath every sandbox is a physical host, and hosts fail. AWS schedules an EC2 instance for retirement “when AWS detects irreparable failure of the underlying hardware,” and warns that by the time you hear about it, the instance “might already be unreachable.” Data on the host’s own drives doesn’t survive a retirement, a stop, or a failed disk. (From [Instance retirement](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-retirement.html) and [Data persistence for Amazon EC2 instance store volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-store-lifetime.html). What this means for a program that calls `fsync()` is in [Where fsync returns from](https://archil.com/guides/how-file-systems-work/where-fsync-returns-from).) Neither the agent nor you decides when that happens.

**Every sandbox has a timer**

A clock runs from 1 minute to 30 days on a log scale. E2B’s default timeout ends a sandbox, and its state, at 5 minutes. Modal’s default timeout is also 5 minutes. Daytona stops a sandbox after 15 idle minutes, Archil pauses one after 30 idle minutes, and a Vercel Sandbox session on the Hobby plan ends at 45 minutes. Where a longer session is allowed, it ends at 24 hours: on E2B Pro, Modal, Archil, and Vercel Pro. In the last row, the agent’s work picks up again after a pause of almost 15 days, the longest pause in our agent loops.

## Where an agent’s hours go

The timers exist because agents spend most of their time waiting. We read the timestamps on 30 days of our engineering team’s coding-agent sessions: 384 agent loops and about 37,000 tool calls. The median tool call finished in 0.5 s, and the model’s median turn took 2.7 s. Between bursts of work, the agent waits on a person, and some of those waits last overnight or longer. At least 26 of the loops picked up again more than a day after their previous tool call. (The method is in [Do AI agents need a sandbox running for the whole session?](https://archil.com/article/do-ai-agents-need-a-sandbox-running-for-the-whole-session) We read only when each model turn and tool call started and ended, not what they contained. The count of 26 comes from re-running the analysis a day later, on the 363 loops whose timestamps we still had.)

That pattern defeats every timer setting. Suppose each loop had started a sandbox at its first tool call and stopped it after 15 minutes without one. That sandbox would have been idle for 65% of the time it ran. A shorter timer idles less, but the sandbox stops more often, and each new start needs the workspace on a new machine.

**Drag the auto-stop timer**

An explorable chart of 31,422 pauses between tool calls, from 363 of our agent loops, on log scales from 0.1 s to about 3 weeks. Most pauses last 1 to 10 s, while the model writes its next step. A long, thin tail runs through minutes and hours to pauses of days. Pauses of 10 minutes or more are 1.5% of all pauses but hold 98% of the waiting time. Dragging the auto-stop timer splits the pauses: shorter ones keep the sandbox up and idle, and longer ones stop it. Over all 384 loops, a 1-minute timer leaves the sandbox idle 28% of the time it runs (54% in the median loop), for 243 hours of sandbox time against 174 hours of tool work, and 1,303 pauses outlast it, about 4.6 starts per loop. A 5-minute timer: idle 48% (75% in the median loop), 337 hours, 669 pauses, 2.8 starts per loop. A 15-minute timer: idle 65% (88%), 493 hours, 384 pauses, 2.1 starts per loop. A 1-hour timer: idle 83% (96%), 1,019 hours, 226 pauses, 1.6 starts per loop. Pause and start counts come from the 363 loops.

Neither end of the timer is a good home for the work. A long timer pays for a machine that mostly waits, and a short one throws the machine away several times in a loop. Either way the machine is temporary, so the workspace has to live somewhere that isn’t. What that waiting costs in storage is the subject of [What you pay for](https://archil.com/guides/storage-for-agents/what-you-pay-for).

## What the workspace needs

Read the day again, and each thing that happened to the workspace sets a requirement for the storage under it:

- **It survives a lost machine.** When the host is retired mid-task, every write that the agent was told was saved has to be there on the next machine. That makes a write safe when `fsync()` returns, not when an upload finishes later. Storage that acknowledges from the host’s own drive and uploads afterward can lose its newest writes with the host. See [When is a write safe?](https://archil.com/guides/evaluating-storage/when-is-a-write-safe)
- **It’s as fast as a local disk on thousands of small files.** An `npm ci` of one Next.js app writes 18,602 files. Add 1 ms of network waiting to each file, an assumption for the arithmetic, and the install takes about 19 s longer. Agents run steps like this all day, and wait on every one. See [How fast is it on small files?](https://archil.com/guides/evaluating-storage/how-fast-is-it-on-small-files)
- **It moves to other machines, and is shared with them.** The next tool call can land on any host. Copying a 5 GiB workspace onto each new machine at an assumed 500 MB/s takes about 11 s, more than 20 times the median tool call. So the workspace has to be reachable from wherever the call runs, and sometimes from two machines at once. See [Can many machines use it at once?](https://archil.com/guides/evaluating-storage/can-many-machines-use-it-at-once)
- **It forks cheaply.** Three attempts from one starting point need three writable copies of the workspace, made in about the time it takes to start the sandboxes. See [Can you fork it?](https://archil.com/guides/evaluating-storage/can-you-fork-it)
- **It costs little while idle.** Most of a workspace’s life is waiting, and storage that bills by the machine or by a reserved size bills all of it. See [What does it cost when nothing is running?](https://archil.com/guides/evaluating-storage/what-does-it-cost-when-nothing-is-running)
- **It’s a real file system.** `git commit` renames a lock file over the index, SQLite writes pages in place, and `npm install` creates symbolic links. The agent’s tools assume POSIX, and the agent didn’t write them. See [Is it really a file system?](https://archil.com/guides/evaluating-storage/is-it-really-a-file-system)

**From the day to the requirements**

Six events from the agent’s day, each with the requirement it sets. The host is retired mid-task, so the storage survives a lost machine. `npm ci` writes thousands of files, so it needs local-disk speed on small files. The next call lands on another host, so the workspace moves to, and is shared with, other machines. Three attempts start from one state, so it forks cheaply. It waits overnight, or for days, so it costs little while idle. Git, npm, and SQLite run as they are, so it is a real file system.

The storage you already have meets some of these requirements, never all of them. The sandbox’s own disk is fast and is a real file system, and it disappears with the host. An S3 bucket outlives any machine and bills only for what it stores, but it isn’t a file system, and every operation is a request over the network. The requirements pull in opposite directions. Speed and POSIX want the data on the machine doing the work, and surviving, moving, and idling cheaply want it somewhere else.

A team that runs agents ends up building something between those two poles. [The next chapter](https://archil.com/guides/storage-for-agents/the-obvious-ways-to-build-it) climbs through the designs teams reach for, starting with the sandbox’s own disk, and shows which requirement each one gives up.