Research · The cheaper-agents series · Part 2 of 3
Why splitting the work saves money
Routing the busywork to a cheaper model is real money saved. But the larger lever is not which model you call — it is how much you make it read, and how often.

In Part 1 we changed one setting and pushed the repetitive work onto a cheaper model. That helps. But if you stop there, you have found only the smallest of the three levers — and not the one that matters most.
The instinct is to think of agent cost as a property of the model: pick a cheaper one and the bill goes down. It is more useful to think of cost as a property of the whole loop. A single number governs it:
Switching models scales the first term — often by a useful factor. But the second and third terms compound, and a badly built agent inflates both without anyone noticing. That is where budgets quietly disappear.
The hidden multiplier: context you resend every call
An API call carries no memory. Whatever the model should "know" for a step, your code must send again. The lazy way to satisfy that requirement is to send everything, every time:
- the entire conversation so far;
- the whole repository, or large parts of it;
- every previous model response, including discarded ones;
- complete test logs and stack traces;
- files unrelated to the current change.
Each of these grows as the task proceeds. So the cost of call number forty is not the cost of call number one — it is much larger, because call forty re-reads everything that happened in the first thirty-nine. Each step carries every step before it, so the cost does not merely climb; it compounds. Roughly, doubling the length of a session quadruples the spend — the token count grows with the square of the number of calls, even though the useful information at each step stays small and roughly constant.
This is also a quality problem, not only a cost one. Burying the one relevant function inside fifty thousand tokens of unrelated material makes the model's job harder, not easier. The signal you need is still there; it is just harder to find. Bloated context and poor answers tend to arrive together.
A rough sum to make it concrete
Forget exact prices for a moment — they change weekly, and the point survives without them. Count token-calls: tokens supplied multiplied by the number of calls. To see where the money really goes, hold both agents to the same eight calls and change only what each call carries.
The undisciplined agent resends its accumulated context, so each call is larger than the last — eight thousand tokens, then sixteen, then twenty-four, climbing to the end:
resend everything: 8k + 16k + … + 64k ≈ 290,000 token-calls
The disciplined agent sends only what each step needs, so every call stays flat:
send only what it needs: 8 × ~4k ≈ 32,000 token-calls
That is already a factor of roughly nine at an identical call count — proof that the cost is the accumulation, not the number of calls. In practice the gap is wider still: an undisciplined agent also tends to sprawl into more calls — forty, not eight — pushing the difference past thirty-fold. Now layer the routing on top: run those calls mostly on a model that is, say, ten times cheaper per token, and reserve the premium model for the two that need judgement. The effects multiply.
A premium model used twice with precise context can cost less than a cheap model called forty times with an undisciplined prompt.
This is the uncomfortable part for the "just use a cheaper model" reflex: a ten-times-cheaper model, fed thirty times more context, is more expensive — and usually worse. Cheapness at the token level does not survive contact with an undisciplined loop.
What a disciplined loop actually does
The fix is not heroic. It is a handful of habits, applied at every step:
- Build context fresh each call. Do not append forever. Assemble the smallest set of files and history the next decision needs, then discard the rest.
- Keep state outside the model. The full history lives in your application — a file, a database, a scratch directory — not in the prompt. The prompt is a working set, not an archive.
- Summarise what is done; drop what failed. A one-line note that "the parser now passes its tests" is worth more than the four rejected attempts that preceded it, and costs a hundredth as much to carry.
- Feed back evidence, not transcripts. When a test fails, send the relevant failure — not the entire log, and certainly not the whole conversation that produced it.
This is exactly why Claude Code's built-in Explore subagent runs on a cheap model and returns a summary rather than the raw search output: it attacks two of the three terms at once — a cheaper price and fewer tokens carried back into the main context. The pattern in Part 1 was not only "use Haiku"; it was "keep the bulky work out of the expensive window."
Spend intelligence where it is scarce
Put the two ideas together and a design rule falls out. Cost is driven by price, tokens and calls; quality is driven by putting strong reasoning at the few points where a wrong answer is expensive. Those are the same decision, viewed from two sides:
Spend heavily where mistakes are costly or judgement is scarce. Spend little where the work is repetitive, testable and reversible.
A search, a reformat, an agreed edit, a re-run of the suite — repetitive, testable, reversible. Choosing the architecture, diagnosing why three fixes in a row failed, deciding whether a change is safe to ship — costly to get wrong. The first kind wants a cheap model and a tight context. The second wants your best model and your full attention. Most loops never make the distinction, and pay for it twice: once in tokens, once in quality.
Part 1 showed the built-in controls that do this without code. Part 3 goes the whole way — a router you build yourself, with a cheap non-Claude worker doing the iteration and Claude reviewing the result. Both rest on the arithmetic here: price × tokens × calls. Bring all three down together, and the savings are not incremental — they multiply.
The cheaper-agents series: Part 1 — Cheaper models inside Claude Code · Part 2 — Why splitting the work saves money (this article) · Part 3 — Roll your own, across providers
First published on x-trillion.com. A version also appears on Medium.