What a fleet of agents actually costs

Over seven weeks of building our own product, a fleet of agents ran 279 times, spent 41.9 hours working, and read 1.16 billion input tokens to write 4 million. That work landed as 73 merged pull requests. So one merged PR cost roughly 3.8 agent runs, 34 minutes of agent time, and 15.8 million input tokens.

The number that surprises people is the ratio: 288 tokens read for every token written. A fleet of agents is overwhelmingly a reading machine. Almost everything it costs is spent re-establishing context, not producing output.

What is measured

Every subagent invocation on our own codebase is logged by a SubagentStop hook into an append-only journal, then pushed into a Postgres table in production. Each row carries the agent, the wall-clock duration, input and output tokens, and a timestamp. Nothing is sampled and nothing is estimated.

The window is 2026-06-09 to 2026-07-31, the full span of the telemetry at the time of writing, read on 2026-08-03. The figures below are the ones in the table at the bottom of this page, and the CSV next to it is a projection of that same file: what we display and what we hand out cannot drift apart.

The counterpart comes from the repository over the identical window: 73 squashed pull requests merged to the main branch, 499 files touched, 35,558 lines added and 2,318 removed.

| Per merged pull request | | |---|---| | Agent runs | 3.8 | | Agent time | 34 minutes | | Input tokens | 15.8 million | | Output tokens | 55,000 |

| Per agent run | | |---|---| | Duration | 9 minutes | | Input tokens | 4.1 million | | Output tokens | 14,400 |

Fifty-three distinct agents ran in the window. Most are one-off specialists spawned for a single job, not a standing roster.

What these numbers do not say

They are a floor, not a total. The hook fires on subagents only. The main session that orchestrates them, reads files and writes most of the code is not counted anywhere in this dataset. The real token cost of the seven weeks is materially higher than 1.16 billion, and we cannot tell you by how much, because we do not measure it yet.

They say nothing about running an agent in production. This measures what it costs to build software with a fleet of agents, on our own codebase, with our own conventions. It does not answer what a client's agent costs to operate once deployed. The two get confused constantly and they are not related.

The error column is empty, and that is an instrumentation gap, not a perfect record. The field exists and is wired, but it has never once been true across 246 logged invocations. Seven weeks without a single subagent failure is not credible. We publish the column raw rather than quietly dropping it, and we draw no reliability claim from it.

The repository side is not verifiable by you. The pull request and line counts come from a private repository. They are first-hand and we stand behind them, but you cannot check them the way you can check a public benchmark. Lines of code in particular is a weak measure of anything, and it is included only to give the token figures a scale.

One window is not a trend. This is the first row of a series. A single measurement of a single team on a single codebase tells you what happened here, not what will happen anywhere else.

How to reproduce it

The mechanism is three pieces, and none of them is specific to us. A SubagentStop hook appends one JSON line per invocation to a local journal. A script pushes new lines into a table, keyed so a replay cannot double-count. A second script reads a closed window and appends one row to a data file committed to the repository.

The last step is the one that matters. Figures generated at build time get rewritten on every deploy, and "measured in August" quietly becomes "measured at the last deploy". Ours are appended deliberately, reviewed in a pull request, and a test fails if a released row ever changes. That is why the series below can be cited: it cannot be edited after the fact without the change being visible.

The projects this work produced are listed in our work.