Benchmarks / Live agent footprint
An agent as a goroutine
A dormant agent is a row; a running one still has to hold its place. 601 bytes of heap per live agent, 187 ns to spawn one, 114 ms to wake a million — and the three language runtimes that can sit inside one.
- harness
- hanzoai/cloud · bench/goroutine
- our paper
- What a Dormant Agent Costs
cd goroutine && go build -o /tmp/g . && /tmp/gprints the table on this page — transcribed from bench/README.md, the pass of 2026-09-07
What is measured
A dormant agent is a row on disk. An agent that is running still has to hold its place, and the question is what that place costs. Here it is a goroutine: the heap it occupies, the time to start one, and the time to wake a million of them at once. The comparison column is what a platform built on V8 isolates publishes for the same two quantities.
Results
M-series laptop · the pass of 2026-09-07 · memory was identical on all five runs; timings are medians
| measurement | Hanzo, measured | the published figure |
|---|---|---|
| heap per live agent | 601 bytes | 1.2 MB per isolate, isolated-vm |
| one million live agents | 573.0 MB | — |
| spawn one | 187 ns | 2.79 ms, isolated-vm |
| wake one million | 114 ms — 114 ns each | — |
601 bytes against a 128 MB container floor is about 223,000×, and against a V8 isolate about 1,700× — and that second one is a goroutine against a JavaScript VM, so read it as what each primitive costs rather than as one beating the other. The isolate column is measured here rather than cited: a fresh isolated-vm isolate is 1.00 MiB and 0.59 ms on this laptop, close to the 1.2 MB attributed to it, because a megabyte is what any isolate costs including one of ours. The number that matters more for an interactive system is the 187 ns: an agent that costs nothing to start does not need to be kept warm, and a pool is a thing you maintain because starting was expensive.
What can run inside one
the same pass · instantiate is per context; call is a warm invocation
| runtime | language | instantiate | call |
|---|---|---|---|
| wazero | WASM — any language that targets it | 8.9 µs | 23 ns |
| goja | JavaScript | 2.7 µs per VM | 818 ns warm eval |
| gpython | Python | 29.9 µs per context | — |
WASM is not one language: CPython, QuickJS for TypeScript, Rust and Go all target it. A V8 isolate is JavaScript, and only JavaScript.
How to get this wrong
Benchmark a built binary. Under go run the compile is counted and spawn reads 253 ns instead of 187 ns — a 35% error from the command you used to start the measurement. The reproduce line on this page builds first for exactly that reason.
A goroutine is not a sandbox. These agents share an address space. Nothing here is a security boundary, and an agent that must run untrusted code needs one — which costs 150.8 ms for a cold container, four orders of magnitude more than the spawn above. The two numbers answer different questions and a platform needs both.
One machine, one day. A single pass on one laptop, reproducible by one command. It establishes a floor; it is not a service level under load.
The other benchmarks
LoCoMo · MemoryAgentBench · LongMemEval · RepoBench-R · LoCoMo · subject scope · LoCoMo-Conv · Fleet residency · Sandbox cold start · Inference vs llama.cpp · GPQA-Diamond · all of them, and the head-to-head
harness and the committed table: hanzoai/cloud · bench/goroutine · the paper: What a Dormant Agent Costs