Files
zeekayandHanzo Dev e57d01a884 The paper argued from a pooling tier the system does not have
Every measured constant in hanzo-dormant-agents came from bench lanes that
have since been re-run, and two of them from a lane that was deleted. The
paper is the last consumer to be corrected and the one where it matters most.

The pooled row was the problem. Section 6 reported 37.54 ms for "a command
dispatched into a container that is already up" and built a paragraph on it —
"pooling collapses most of the gap, and is the only tier that matters at fleet
scale" — which the conclusion then turned into policy: pool the expensive
boundary so a fleet pays the pooled number in steady state. That row was
docker exec, on a runtime this system does not use. The runtime it does use
has no exec, no attach and no pool. Every call boots.

So the table is hanzo-vm now: 309 ms cold, 335 p95, and 311 ms from a
checkpoint — which is the same number, because a checkpoint carries the
filesystem an earlier run left and the kernel boots either way. The pooling
paragraph is replaced by what is true: there is no warm tier, the published
resume figures elsewhere are memory snapshots and ours is not, and setting the
two side by side would claim a mechanism by borrowing its name. The cost of
not having it is stated instead — about 3x on a whole agent call.

Section 6 also said our figure "compares favourably to the published
cold-start figures". At 309 ms it does not: it is slower than the under-200 ms
published for Firecracker sandboxes, faster than the container platforms, and
all of those were taken by their authors on their own hardware. The paper says
that now, including that quoting their hardware back at them is not a defence.

The rest are re-measurements: a goroutine spawns in 125 ns (the 187 was a
fresh binary's first run, which is 1.65x its own steady state), a million wake
in 107 ms, a V8 context is 0.13 ms, an isolate 0.35 ms, wazero 7.8 us, goja
2.4 us, gpython 25.0 us. The isolation ratio is 2377x, not 1016x.

Rebuilt: 12 pages, no stale figure survives in the PDF.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-16 07:48:02 -07:00
..