What a coding agent sandbox really needs: real build data

We ran a real coding-agent build, OpenCode's own provider benchmark, inside a Firecracker microVM on bare metal. Isolation cost about 16% against the same machine with no VM. Peak memory moved between 11 and 14 GiB across identical runs, so plan for 24 GiB, not 16. CPU gains flatten past 16 cores. And cutting the sandbox off the network by default cost nothing we could measure.

Most sandbox benchmarks time how fast an empty box boots. That matters, but an idle sandbox isn't an agent. An agent clones a repo, installs dependencies and runs the type checker, over and over. This post is about that workload: what it costs to isolate, and what it needs from the machine. Every raw run, failures included, is published on GitHub.

#What we ran

The benchmark started with a tweet. On 16 July 2026, dax, who builds OpenCode, posted the bar a sandbox provider had to clear.

i am evaluating all sandbox providers, our requirements are high

• fast disk, not networked
• fast CPU, should be virtualizing on bare metal
• can pause/resume

dax (@thdxr), 16 July 2026

That list reads like a description of a self-hosted sandbox. Hotcell runs on your own machine's local disk, virtualizes with Firecracker on bare metal, and pauses a microVM by snapshotting its memory. So we ran his benchmark.

The workload is his provider benchmark from the OpenCode repository (script/provider-benchmark.sh on the provider-benchmark branch). Inside one sandbox it downloads Bun, clones the OpenCode repo, runs bun install, then runs bun typecheck. It times seven phases in total. It's the same workload behind the "sandbox-dax" test in the open-source ComputeSDK benchmarks.

We ran the script unmodified in Hotcell, our open-source sandbox runtime, using Firecracker microVMs. Two details matter for reading the numbers:

• Our own harness, not ComputeSDK's wrapper. Each run used a fresh, cold microVM. We sampled peak guest memory and sorted every run into pass, out of memory, install flake or admission refusal. So there's no ComputeSDK-format score for Hotcell, but the phase timings are the same workload.
• Self-hosted, so no network round trip to a sandbox API. Hosted providers in the public leaderboard are called over the internet from a CI runner. Our harness ran on the same machine as the sandboxes. That's the honest setup for a self-hosted runtime, and it's not apples to apples with a hosted number.

The headline runs used a bare-metal Hetzner server with an AMD Ryzen 9 5950X: 5 cold runs at 32 vCPU and 32 GiB.

#Result 1: isolation costs about 16%

The same script on the bare host, with no VM at all, took 30.41 s for the workload. So the microVM added about 16%. That's the price of giving each agent its own kernel, and for most teams it's worth paying: an agent that runs rm -rf or a malicious postinstall script only damages its own microVM.

#Result 2: memory is a band, not a line

The surprise was memory. Peak working set moved between 11.0 and 14.2 GiB across byte-identical runs. Same commit, same lockfile, same machine. That spread decides whether a run survives:

• At 8 GiB or less, it always ran out of memory.
• At 12 GiB, it passed 1 run in 3.
• At 16 GiB, it passed 3 of 3 in one session and ran out of memory in an earlier one.
• At 24 GiB or more, it has never failed.

If you size a sandbox from one good run, you'll pick 16 GiB and get random failures. For a build like this, provision 24 GiB. More generally, run a workload several times and size for the worst run, not the median.

#Result 3: CPU gains flatten past 16 cores

Typecheck is the CPU-heavy phase. With memory fixed at 32 GiB, here's its median by core count:

Each doubling buys less. Going from 16 to 32 cores saves under 3 seconds. Install barely cares about cores at all: it came in between 11.7 and 19.4 s at every size we tried, because it's limited more by disk than by CPU. For this workload, 8 to 16 vCPU per agent is the useful range.

#Result 4: default-deny egress is free

Hotcell's microVMs can run with no network device at all. Every request leaves through a gateway on the host over vsock, and only allowlisted hosts get through. That's also where the gateway swaps a sandbox token for the real API key, so the key never enters the sandbox.

We expected that to cost something. It didn't. At 8 vCPU the same workload passed 3 runs of 3 at a 46.2 s median, with no measurable difference from the same configuration with normal NAT networking. The whole build needed exactly three allowlist entries, which we read from the denial logs: nodejs.org, api.github.com and pkg.pr.new.

#How this compares to hosted sandboxes

We ran these numbers against ComputeSDK's published run of 17 July 2026. Back then, only one of nineteen hosted providers, Modal, completed all seven phases, with a full-script total of 62.59 s from a single run. Our 58.45 s at 32 vCPU was a little faster, but on a much bigger machine, so we never counted it as a win.

The field has moved since. The live sandbox-dax leaderboard now shows 20 providers completing all seven phases, as of 31 October 2026. The fastest, isorun and promigence, finish in about 36 s. Most land between 50 and 85 s. Our results would sit in the middle of that range: 58.45 s at 32 vCPU and about 70 s at 8 vCPU. The leaderboard page doesn't state machine sizes, and our harness has no network round trip in it, so treat any side-by-side reading as rough.

That's fine. Hotcell isn't trying to be the fastest hosted sandbox; it runs on your own hardware, with your keys outside the sandbox. The more useful output here isn't a leaderboard row. It's the demand curve above: the memory band and the CPU knee, which tell you how to size a machine for agents.

#What this means for sizing a server

Not every agent runs a 14 GiB build. We also measured lighter work, on a small 4-core ARM server with 8 GB of RAM. These runs used Hotcell's container driver.

The runtime overhead per sandbox is small next to that: about 2 MiB for an idle container and about 54 MiB for a Firecracker microVM. So the agent's workload, not the sandbox, decides how many fit on a machine. The "fits about N agents" figure in dl setup is an estimate based on 1 GB per sandbox, which matches the TypeScript row, not the monorepo row.

#What broke along the way

Measuring this found real bugs. We fixed three: a gap in writable root filesystems, a git failure behind the proxy (a 407 on CONNECT), and an admission gap when resuming a paused sandbox. One is still open. Inside the microVM, bun install builds tree-sitter-powershell from source instead of using its prebuilt binary. Putting npm's bundled node-gyp on the path works around it at a cost of about 1.3 s. The diagnosis is in the raw results.

#Which Hotcell version this was, and what's changed since

All of these runs happened between 17 and 18 July 2026, on Hotcell's main branch between the v0.1.3 and v0.1.6 releases. The current release is v0.1.38. A lot has shipped in between, and some of it could move the numbers when we rerun.

• Warm pools and snapshot-fork templates. MicroVM warm pools (July) and snapshot-fork Firecracker templates (v0.1.34) make a sandbox ready much sooner. The benchmark only times work inside an already-running sandbox, so this mostly changes the time before the clock starts, not the totals above.
• A new default image. The default sandbox image is now Hotcell's own base image on Node 22, rebuilt fresh for security fixes. These runs used a stock image plus the node-gyp workaround. A different image could change install time, and could remove the 1.3 s workaround if it ships the toolchain bun install was missing.
• Network path changes. Since July, git traffic goes through the gateway automatically, the gateway relays provider redirects instead of following them, and networked Firecracker sandboxes are firewalled off host services and cloud metadata. Clone and install go over the network, so these could shift those phases slightly in either direction.
• Bounded microVM boots. Hotcell now caps how many microVMs boot at once. That matters when many agents start together, not for one sandbox running one build.
• Fixes found by this benchmark. The three bugs above were fixed during these runs, so later reps already ran on fixed code. The node-gyp source build was still open when we wrote this up.

Changes like the container driver's new guest agent (v0.1.31) and container warm pools (v0.1.33) don't affect these numbers, because these runs used Firecracker. We'll rerun the same script on the current release and update this post with both sets of numbers side by side.

#Reproduce it

Everything is open source. The full write-up, with methodology, every table and the boot-time results we didn't cover here, is in Hotcell's benchmarks. The raw output of every run, including every out-of-memory failure, is in the evidence folder. If your numbers differ, open an issue: a single run isn't a number, and more machines make the curve better.

#Run agents in sandboxes like these

Hotcell is the sandbox layer under Directionally Local, the open-source coding agent harness you run on your own computer or server. dl sets up the harness and its sandboxes with one command, and on a Linux server with KVM each agent gets its own Firecracker microVM:

npm install -g directionallylocal
dl

#FAQs

#How much memory does a coding agent sandbox need?

It depends on the work. Running scripts or a small Python repo peaked at 10 to 16 MiB per agent. Installing and type-checking a typical TypeScript app of about 92,000 lines peaked at about 1 GiB. OpenCode's full build peaked between 11 and 14.2 GiB across identical runs, so give that kind of build 24 GiB.

#How much slower is a Firecracker microVM than running on the host?

About 16% on this workload. The clone, install and typecheck took a median of 35.4 s in a microVM and 30.4 s on the same bare-metal machine with no VM. That's the cost of giving each agent its own kernel.

#How many vCPUs should each agent get?

For a build like OpenCode's, 8 to 16. Typecheck went from 102.8 s on 2 vCPU to 20.2 s on 16, but only to 17.4 s on 32. The install phase barely changes with more cores, because it's limited by disk.

#Does blocking network access slow an agent down?

Not measurably. With no network device in the microVM and all traffic going through Hotcell's gateway, the build ran at the same speed as with normal networking. It needed only three allowed hosts: nodejs.org, api.github.com and pkg.pr.new.

#Do I need bare metal to run Firecracker sandboxes?

Firecracker needs KVM. Bare-metal servers have it. On a cloud VM you need nested virtualization, which some providers offer; our earlier Google Cloud runs used it. Without KVM, Hotcell can use Docker containers instead, with less isolation.

#Which Hotcell version was tested, and will you rerun it?

The runs were on 17 and 18 July 2026, on Hotcell's main branch between v0.1.3 and v0.1.6. The current release is v0.1.38. We'll rerun the same script on the current release and publish both sets of numbers side by side.

#How does Hotcell compare with hosted sandbox providers on this benchmark?

On the live sandbox-dax leaderboard, 20 hosted providers complete all seven phases, the fastest in about 36 s. Hotcell's 58.45 s at 32 vCPU and about 70 s at 8 vCPU would sit in the middle. The comparison is rough, because the leaderboard doesn't state machine sizes and our runs had no network round trip to a sandbox API.