What it saves

Measure what moving an agent’s loop out of its sandbox saves, because the answer depends on how your own agents spend each hour. When I ran 1,000 agent loops multi-tenanted on one server, with each tool call on Archil’s serverless execution, the CPUs needed at peak came to something like 180. Giving each loop its own sandbox would have needed something like 2,000.From What comes after sandboxes, October 14, 2026. Both numbers are rounded, from one demonstration.

A demonstration isn’t a forecast for your agents. This chapter works through the arithmetic behind numbers like those. It covers what each design holds over an hour, a calculator that prices a fleet for a month, where the calculator’s defaults come from, and the cases where a sandbox is still the better home.

What each design holds§

An agent in a sandbox holds the sandbox’s full size for every hour the sandbox runs. The model writing its next step, a person reading a diff, and a test suite all hold the same vCPUs. For a fleet, this is one line:

vCPUs held = agents × sandbox vCPUs

With the harness outside, two things hold CPU. The harness host runs all the time, but one process carries many agents, because a harness spends nearly all its time waiting on the model. Many agents, one machine runs many pi sessions in one Node process this way. Each tool call holds its compute only until the command returns. On Archil, that’s a microVM with 2 vCPUs and 4 GiB.The per-command size is in Limits. On average:

tool share = tool calls per hour of session × mean seconds per call ÷ 3,600
vCPUs held = harness vCPUs + agents × tool share × vCPUs per call

The tool share is the only usage term, so it decides the answer. When tools run for a small part of each hour, the outside design holds a small fraction of what the sandboxes hold. When they run for most of it, the two designs converge.

An average isn’t a peak, and you size capacity for the peak. Tool calls from independent sessions overlap at random, so at the busiest moment more are in flight than the average suggests. The explorable in How much one host can take models that moment exactly, and this chapter’s calculator uses the same model. The peak depends on two things: the tool share, and the vCPUs each call holds.

That explains the gap between the demonstration and our own measurements. If each call held 2 vCPUs, a peak near 180 across 1,000 sessions means fewer than 90 calls in flight at the busiest moment, which fits a tool share of about 6%. Our engineering team’s agents are busier. At the tool share of our median loop, that explorable puts the busiest moment for 1,000 sessions near 314 vCPUs.

Dollars follow a different meter. A sandbox bills by the vCPU-hour and GiB-hour for as long as it runs. Archil bills a serverless tool call at a flat $0.05 per 1,000 calls with execution included, however long the command takes within its 5-minute limit.See Pricing & Billing. So the outside design’s CPU follows how long your calls run, and on Archil its bill follows how many you make.

A fleet, priced§

The calculator runs both designs for a fleet that keeps the same number of sessions open around the clock, and prices a 730-hour month at list prices. Each total has its arithmetic underneath it. It leaves out storage and data transfer; for what the disk costs, see What you pay for.

Three of its choices are worth knowing before you trust a number from it:

• The busiest moment assumes independent sessions. Real traffic bunches up, as when a team starts work at nine, so watch your own peaks before you size a host.
• Long calls run in a sandbox. The share of tool time you put in calls over 5 minutes runs in a sandbox of the size you chose, started for the call and stopped after it. Those calls are also billed per call, which errs high.
• The harness host is an assumption. Its price uses our sandbox rates, and its size matches the host in Many agents, one machine. How many agents one host carries depends on what your harness does between model calls, so measure it under load.

Not every sandbox bills a waiting agent’s full size. Vercel Sandbox bills memory for as long as a sandbox is provisioned but CPU only while it’s actively used, and Fly.io Sprites bill only the CPU and memory actually used. Both bill an idle agent far less than a reserved sandbox does. The calculator leaves them out because their meters don’t reduce to a rate per vCPU-hour.From What does an idle agent sandbox cost per hour?, which links each provider’s pricing page.

Where the defaults come from§

The usage defaults are our engineering team’s own coding agents: 30 days of sessions, 384 agent loops, and about 37,000 tool calls, read from timestamps only. We modeled each loop with a sandbox started at its first tool call and stopped after 15 minutes without one, and the calculator’s session is that sandbox time. Those sandboxes would have run for 493 hours, and the tools ran for 174 of them.The method is in Do AI agents need a sandbox running for the whole session?, and the hours are in Where an agent’s hours go. Each default follows from those figures:

• Session length: 493 hours across 384 loops.
• Tool calls per hour of session: about 37,000 calls over 493 hours of sandbox time. Counted per hour of activity alone, without the waits on a person that the timer kept the sandbox up through, the rate is about 160.
• Mean tool-call duration: 174 hours over about 37,000 calls.
• Tool share: together, those give the share of all loops that the host explorable uses, 35%.
• Calls over 5 minutes: about half of all tool time, as the next figure shows.
• Prices: E2B’s default sandbox size at E2B’s list price, and an 8 vCPU harness host carrying 1,000 agents, the count from the demonstration.

The mean sits far higher than the median, because a few long calls hold much of the time:

That makes our agents a demanding case. They run builds, test suites, and benchmarks, so their tools stay busy for a good share of each hour, and the calculator’s default saving in CPU is far smaller than the demonstration’s. An agent whose calls look like the median, reading files, searching, and making small edits, spends much less of each hour in tools. Set the mean to a few seconds and the long-call share to zero, and the fleet holds about a tenth of what the sandboxes hold, or less.

To put your own agents in the calculator, measure the two usage inputs where your tools run today. This wrapper goes around whatever function runs a command, in a sandbox or on serverless execution:

type Run<T> = (command: string) => Promise<T>;
 
// Wrap the function your bash tool calls, and record how long each call takes.
// Create it when the sandbox starts, so its hours match what the sandbox bills.
export function measured<T>(run: Run<T>) {
  const started = performance.now();
  const durations: number[] = [];
 
  async function tool(command: string): Promise<T> {
    const t0 = performance.now();
    try {
      return await run(command);
    } finally {
      durations.push((performance.now() - t0) / 1000);
    }
  }
 
  // The calculator's two usage inputs, for the session so far.
  function usage() {
    const hours = (performance.now() - started) / 3_600_000;
    const seconds = durations.reduce((sum, d) => sum + d, 0);
    return { callsPerHour: durations.length / hours, meanSeconds: seconds / durations.length };
  }
 
  return { tool, usage };
}

Collect usage() from many sessions, not one, because a single session’s tool share swings widely.

When the sandbox still wins§

The arithmetic favors the harness outside when tools run for a small part of each hour and every call fits in a short-lived microVM. These cases don’t, and a sandbox is still the right home for them:

• Agents that edit their own environment. If the agent is meant to change the machine it runs on, its loop and its tools belong together in one sandbox. This is the exception What comes after sandboxes carves out.
• Long-running services. A dev server, a file watcher, a database, or anything listening on a port has to stay up between calls. A serverless call keeps nothing between calls except what it writes to the disk.
• Heavy, continuous compute. As the tool share approaches the whole hour, the outside design holds as many vCPUs as the sandbox, and per-call billing loses its edge too. A 2 vCPU, 4 GiB E2B sandbox costs the same as about 3,300 calls an hour, close to one call a second, sustained.From What does an idle agent sandbox cost per hour?
• Calls over the per-call limit. On Archil, a serverless command that runs past 5 minutes is stopped, and the call returns 504 with Exec timed out.See Serverless execution limits. In our loops, those calls were few but held much of the tool time.
• Loops where per-call startup matters. Each serverless call starts a microVM, mounts the disk, and begins with an empty client cache, so a search that a warm sandbox answers from memory reads its files again. A model turn hides tens of milliseconds, but a loop of many tiny calls back to back doesn’t. Price and speed has the measurements.

Most agents end up with a split rather than one side. Keep the harness outside, send everyday tool calls to serverless execution, and start a persistent sandbox, with the same disk mounted, only for the step that needs one. A persistent sandbox bills by the vCPU-hour and GiB-hour while it runs and pauses after 30 idle minutes by default, so stop it when the step is done.See Persistent sandboxes and Limits.

Migrating from an in-sandbox agent moves an in-sandbox agent to this shape one step at a time, including what to do with the parts that have to stay up.