zeekayandHanzo Dev
4fdedc5f54
The measurement lanes lived in hanzoai/cloud/bench, which meant cloning the thing being measured to run anything — including lanes that measure no binary at all. They are here now, at the root, beside the load and scale harnesses that were already here: eleven lanes, MEASURED.md for what each found, naive.md for what competitors publish and where it was read. Four lanes still need the cloud source, because they measure a binary rather than a library. `cloud_src` in host.sh finds it — $CLOUD_SRC, then ../cloud — or prints how to get one. It does not clone: a benchmark that fetches its own subject decides which revision you measured. AND IT SAYS WHICH SOURCE IT FOUND. hanzoai/cloud and hanzo-inc/cloud are different repositories that both check out as `cloud`, and self/modules.sh reads 127 modules on one and 55 on the other. Neither is wrong about the tree it was handed; a lane that does not name its subject is. It prints path, remote and commit now, the way every timing prints its host. Fixed on the way: egress reached for bench/egress/catcher.py and transport for ./bench/transport/harness, both paths in the repository they left. The harness builds from this module now — its only dependency is zap-proto/zip — and market/bench.mjs and brain/tables.mjs lost a directory level each. Verified from the new root: fleet reproduces 454.6 MB and 477 bytes per agent, and self/modules.sh reproduces 127 of 127 when pointed at the tree the figure came from. Co-authored-by: Hanzo Dev <[email protected]>
2.2 KiB
Fleet residency
What a dormant agent costs to keep, measured rather than modelled.
node fleet.mjs /tmp/fleet # writes 1,000,000 agents, measures disk and resume
node cost.mjs # turns that into a monthly bill at list prices
Why this exists
Competitors publish a cost-per-million-agents row and mark it modelled. Naïve's says so in its own footnote — "MODELLED, NEVER BILLED · 100,000 TENANTS × 10 AGENTS" — at an assumed ~1 MB of state per agent.
An assumption is a fine thing to publish if you label it, and they do. But we do
not have to assume: a dormant agent here is a row in the same kv(key, value, upd) table the cloud already runs on, so the number can be taken instead.
What it measured
On an M-series laptop, September 2026:
| agents | 1,000,000 |
| on disk | 454.6 MB — 477 bytes per agent |
| write | 3.2 s, 310,270 agents/s |
| resume, in-process | 0.031 ms |
| resume, cold process | 3.57 ms (includes sqlite3 spawn) |
477 bytes against an assumed 1 MB is a factor of 2,198. At S3 list that is $0.01 a month of storage for the fleet.
What it does not measure
Residency, and only residency. Nothing here says what a fleet costs while it works — model tokens, tool calls, and the compute of a running turn dwarf all of the above and fall on every architecture alike.
That is the same boundary the competing page draws around its own claim: "The advantage is dormancy, and only dormancy." This measures exactly that much, so the honest unit for a price list is $/agent-hour-awake, with a storage line small enough to give away.
Method
fleet.mjs writes agents in batches of 50,000 through sqlite3 on stdin —
piped rather than passed, because a 50,000-row insert is 20 MB of SQL and argv
tops out well before that. The record is what the platform actually stores for a
dormant agent: identity, org, model, standing instruction, tool grants,
schedule, and a cursor into its history. History itself is not resident; a
conversation is not loaded when nobody is talking.
Resume is timed two ways because both are true: in-process is what the server does, cold is what a fresh worker pays.