Do AI agents need a sandbox running for the whole session?

No. Most of an agent's tool calls (run a shell command, read or edit a file, search, run the tests) are short commands that only need the agent's files, so each one can run in a short-lived microVM against a persistent disk and exit. A sandbox that stays up for the whole session is still the right tool for dev servers, file watchers, in-memory state and commands that run longer than a few minutes.

Do AI agents need a sandbox running for the whole session?

An agent session alternates between three kinds of waiting: the model generating its next step, a tool running, and often a person reading the result before the next turn. A sandbox kept open for the session is billed, or at least occupied, through all three. Only the second one needs a machine.

What the agent actually needs between tool calls is its working directory: the repository, installed dependencies, build output, notes. If that lives on a disk that outlives any one machine, each tool call can start a fresh microVM with the disk mounted, run one command, return the output and shut down. This is what we mean by serverless tool calls.

Where an agent session's time goes

We measured this on our own coding-agent sessions. Over 30 days, Archil's engineering team ran 384 agent loops (main sessions and subagents) with about 37,000 tool calls. We read only the timestamps on each model turn and each tool call, not their content.

• The median tool call finished in 0.5 seconds. 89% finished within 10 seconds.
• About 1% of tool calls ran longer than five minutes (builds, benchmarks, waiting on CI), and that 1% accounted for about half of all tool time.
• Suppose each loop had kept a sandbox running from its first tool call and stopped it after 15 minutes without a tool call. That sandbox would have been idle for 65% of the time it ran, and for 88% in the median loop. With a 5 minute auto-stop it would still have been idle 48% of the time.

Two things follow. Most tool calls are short enough that starting a machine per call is cheap if starting one is fast. And the long calls that dominate tool time are the ones that need a long-lived sandbox anyway.

What has to persist between tool calls

For most coding and data agents the first two rows are the whole state. The rest is rebuilt in milliseconds or isn't needed: a shell variable can be passed on the command line, and the working directory is the same on every call.

Running each tool call against a persistent disk

With Archil, the agent's workspace is a disk and each tool call is one disk.exec(). Each call runs one command in its own Firecracker microVM with the disk mounted at /mnt/archil, returns stdout, stderr, exit code and timing, and shuts the microVM down. Only what the command writes to the disk outlives the call, and there is no sandbox to create, stop or delete.

import * as archil from "disk";
 
const disk = await archil.getDisk(process.env.ARCHIL_DISK_ID!);
 
// The agent's bash tool: one call, one short-lived microVM, same disk every time.
async function bash(command: string) {
  const { stdout, stderr, exitCode, timing } = await disk.exec(command);
  return { stdout, stderr, exitCode, queueMs: timing.queueMs, executeMs: timing.executeMs };
}
 
await bash("git clone --depth 1 https://github.com/expressjs/express.git");
await bash("cd express && npm install");
const result = await bash("cd express && npm test");

Each call reports queueMs, the time spent scheduling, booting a microVM and mounting the disk, and executeMs, the time the command itself ran. In our measurement from a laptop to a disk in AWS us-west-2, 50 sequential calls running true came back in 82 ms at the median and 95 ms at p90, end to end, including the internet round trip; the median queueMs was 37 ms. Running the Express test suite (1,288 tests) on the disk took 4.7 seconds per call at the median, almost all of it the tests themselves.

Archil bills each exec call as one serverless tool call at $0.05 per 1,000 calls, with execution included and no separate CPU or memory charge. See Pricing & Billing.

When a long-lived sandbox is still the right choice

Serverless tool calls are the wrong fit when the work needs something that a single short command can't carry:

• Long-running processes. A dev server, a file watcher, a database or anything listening on a port has to keep running between tool calls.
• State in memory. A Python kernel holding a loaded dataframe, or a REPL session, is lost when the microVM exits.
• Long commands. Each Archil exec call can run for up to 5 minutes, after which it returns 504 with Exec timed out. A full build or a long test suite may need more.
• Heavy setup outside the workspace. If every call would reinstall a large toolchain that you can't put on the disk, a sandbox that keeps its root filesystem is cheaper in time.

For those cases, Archil persistent sandboxes run until you stop, pause or delete them, keep their root filesystem and installed packages, and save memory and processes when paused. They are billed per vCPU-hour and GiB-hour. The same disk can be mounted in either, so an agent can use serverless calls for most of its tools and start a sandbox only for the step that needs one.

How to decide for your agent

• If most tool calls finish in seconds and the agent's state is its files, run each tool call serverlessly against a disk.
• If the agent fans work out in parallel, serverless calls give each branch its own microVM against the same workspace without managing a pool of sandboxes.
• If the agent's work moves between machines, regions or processes, keeping the workspace on a disk means nothing has to be copied.
• If the agent runs a server, keeps a kernel alive, or runs commands longer than 5 minutes, use a persistent sandbox for that part.

Log queueMs and executeMs from your own tool wrapper for a day. The split between time spent starting machines, running commands and waiting on the model will tell you which side of this line your agent is on.