The cost lever nobody is optimising

Across 27 controlled trials of an AI coding workflow, the largest single cost difference I measured had nothing to do with how many agents ran. It was how one session searched the codebase.

---

I spent a month measuring what a multi-agent coding pipeline costs. Three conditions, three tasks, three replicates each, every figure taken from transcripts rather than from anything an agent said about itself.

The headline result is what you would expect: the arm that delegates to subagents costs more than the arm that doesn't, and does proportionally more work. Fine.

The interesting number is in a place I wasn't looking.

Three cells of one condition

These are three runs of the same task, in the same condition, with the same tools available and the same starting commit. The only thing that varied is what the session chose to do.

Three times the cost, between two runs that delegated nothing at all.

Run 3 is the only cell in the entire 27-cell square where Read calls outnumber Bash calls. Run 1 read three files and ran forty-five shell commands. Run 3 read seventy-eight files and ran fifty-four.

And look at the middle row. The run that actually delegated cost about the same as the expensive run that didn't. Delegation moved almost nothing. Search strategy moved 3×.

What it isn't

I tested the alternatives before believing this.

It isn't delegation. Structurally excluded — both extreme cells ran zero subagents. There is nothing for a delegation explanation to attach to.

It isn't batching. I measured whether the expensive run was making tool calls one at a time where the cheap run batched them. Batching turned out to be low everywhere, and lowest in the expensive cells — the opposite of what that explanation predicts.

It isn't task difficulty. Same task, same baseline commit, same brief, same available tooling.

What it is

Reading a file loads its entire contents into the session's context. Searching returns the matching lines.

That difference does not cost you once. Every subsequent turn re-sends the whole accumulated context, so a file read on turn 12 is paid for again on turns 13 through 149. The cost compounds with the number of turns still to come — which is why the delta shows up overwhelmingly in cache reads, 5.72M against 24.32M, rather than in output tokens, and why turn count tracks it too: 51 against 149.

A session that reads its way through a codebase is not just slower. It makes every remaining turn more expensive, and then takes more turns.

Why this matters

Practically every published discussion of agentic coding cost is about delegation topology — how many agents, arranged how, returning what, at what token multiple. That work is real and I have contributed to it.

But this is a 3× lever that sits entirely inside a single session, requires no architecture, no subagents, no handoff protocol and no framework. It is also the cheapest thing on the list to change: prefer search over enumeration, and read a file only when you need its contents rather than its existence.

If you are optimising your agent topology before you have looked at your read-to-search ratio, you are tuning the second-order term.

The caveat, stated up front

Two cells, one condition, one task, one operator.

This is not a controlled comparison — it is an observation with a legible mechanism and a corroborating signal that tracks it exactly. I am reporting it because the mechanism is clear and the direction is unambiguous, not because n=2 establishes a rate. I would expect the magnitude to vary considerably with codebase size and task shape.

What I would not expect to vary is the sign. Reading is more expensive than searching, and the gap grows with every turn that follows.

---

This came out of a larger measurement programme whose main finding was that the cost of an agent workflow is tractable to measure and the benefit is not. That write-up is separate, and considerably less cheerful.