The most expensive line in your agent config is the model name
We had a tidy theory. Our codebase has roughly doubled since late May, agents have to read more of it to do anything, so cost per story should climb with the line count. Cost per story did climb, from around $7.50 to around $19, so the theory looked confirmed on the first pass.
It’s wrong. Codebase size has no measurable effect on what a story costs in our data. What moved the number is a single line of stage configuration: which reasoning model the judgment stages run on.
This is the $7.54 median taken apart along a different axis, and it’s the most actionable thing we’ve measured.
The setup
CodeHerder walks every story through todo → plan → code → review → merge → verify → done, and
each stage declares which model tier it runs on. Plan, review and verify get the reasoning tier;
code and merge get the faster, cheaper tier. That split is deliberate and it holds tightly in
practice: the judgment stages run 99.7–100% on the reasoning tier.
In late July we moved the reasoning tier from Claude Opus 4.8 to Claude Opus 5. Everything else about the workflow stayed put. Because every API call is recorded against a story, a stage and a model, we can price that one change exactly.
Window is 29 June to 4 August 2026. Dollar figures are notional list price on flat-rate subscription plans: what those tokens would cost at published API rates, not an invoice we paid. Currency to two decimals, time to one, percentages to one.
The same story, two reasoning models
Shipped stories, grouped by which reasoning model did the judgment work:
| reasoning model | stories | median cost | median lead time | median API calls |
|---|---|---|---|---|
| Opus 4.8 | 2,784 | $7.83 | 53.5 min | 197 |
| Opus 5 | 939 | $18.85 | 155.7 min | 333 |
2.4× the cost. 2.9× the lead time. 1.7× the API calls.
The obvious objection is that these are different weeks, and the codebase grew between them. So here is the same comparison inside a single week, 20 to 26 July, when both models were in service at once and the codebase is therefore identical:
| reasoning model | stories | median cost |
|---|---|---|
| Opus 4.8 | 804 | $7.48 |
| Opus 5 | 155 | $20.69 |
2.8×, same week, same codebase, same workflow. The model is doing the work that the codebase hypothesis was getting credit for.
Where the extra money goes
Two multiplicative effects, and it’s worth separating them because they behave differently:
| per API call | Opus 4.8 | Opus 5 |
|---|---|---|
| cost | $0.06339 | $0.08548 |
| cache-read tokens | 65,121 | 102,795 |
| output tokens | 613 | 547 |
Opus 5 costs 1.35× more per call and takes 1.7× more calls per story. Multiply those and you land on the 2.4× story cost. Note the second row: it carries 1.6× more context per call, which is most of why each call is dearer. And note the third: it emits slightly fewer output tokens. This isn’t a model that writes more. It’s a model that reads more, and goes around the loop more times.
That’s a coherent picture of a stronger reasoning model doing more thorough work. Whether it’s worth 2.4× is a judgment about your codebase and your risk tolerance, not something our data can settle for you. What our data can do is put a price on the decision, which is the part that’s usually invisible.
Why we tested the codebase theory properly, and what it showed
The tempting version of this analysis is a weekly time series: plot codebase lines against median story cost, week by week. Do that and you get a correlation of +0.98, which looks like a finding and is actually an artefact.
Two things break it. Codebase growth and the model migration both advance with the calendar, so they’re collinear, and a time series can’t tell them apart. And our line count only varies about 1.27× across the entire dataset, so dividing any correlated time trend by that narrow range produces a nonsense slope: fitted naively, it implies that doubling a codebase would multiply cost by 39×. When a model implies something absurd, the model is wrong.
The test that actually answers the question is to hold the model fixed and let the codebase vary. Splitting each model’s stories by the codebase size at the moment the story started:
| model | codebase lines | cost | lead time | context per call |
|---|---|---|---|---|
| Opus 4.8 (n=2,753) | 195k → 201k | 1.00× | 0.93× | 1.00× |
| Opus 5 (n=939) | 212k → 222k | 0.85× | 0.51× | 1.00× |
Read across each row, not down the columns: every ratio is normalised to that same model’s own earlier stories, so 0.85× means Opus 5 got cheaper as the codebase grew under it, not that it’s cheaper than Opus 4.8. Within a model, a bigger codebase costs the same or slightly less, takes the same or considerably less time, and moves context per call not at all. Whatever is scaling with our line count, it isn’t what agents charge to ship a story.
We’ll state the limit plainly: our codebase spans a 1.27× range over this period, which is too narrow to rule out an effect that only appears across an order of magnitude. What we can say is that at our scale, over these two months, model choice dominated it completely.
What to do with this
Price your model config before you tune anything else
The cheapest experiment in agentic coding is changing one model name and measuring the same workload. It’s also the highest-leverage one, and it’s reversible in a way that most architecture decisions aren’t.
Attribute cost per stage, not per project
The reason we could isolate this at all is that every call is recorded against the stage it was activated for. A single project-level bill would have shown the same 2.4× rise and given us nothing to act on. This is the practical argument for per-stage attribution: it turns “our agents got expensive” into “the reasoning tier on three stages got expensive, and here is what we get for it.”
Be suspicious of your first correlation
Ours was +0.98 and pointed at the wrong cause. The check that saved us was cheap: find a window where the suspected cause is constant and the suspected effect still varies. If the effect persists, you’ve learned something. If it vanishes, you’ve been reading the calendar.
Match the tier to the stage, not to the project
Nothing here says Opus 5 is the wrong choice. It says the choice is expensive and should be made per stage, deliberately, with the number in front of you. A workflow where planning and review get the stronger reasoning model while implementation and merge get the faster one is already most of the shape of our cost table, and that’s a dial rather than a constant.
The broader point is the one that keeps coming up in this data. Agentic coding cost is not one number that drifts with the size of your project. It’s a small set of configuration decisions, each with a measurable price, and most teams can’t see any of them.
If you want the rest of the receipt: what a median story costs stage by stage, or ten things from the first hundred billion tokens. If you’d rather try it, CodeHerder is here.
Method notes
Stories are grouped by the model that did the majority of their reasoning-tier calls, which is the model the plan, review and verify stages ran on. Cost is attributed to the stage a session was activated for, not the task’s live status when the call happened.
Dollar figures cover 29 June onward, where cache writes can be priced exactly: a cache entry’s price depends on how long it lives, and our per-call record of that starts then. Each call is priced at its own model’s rate with uncached input, cache writes, cache reads and output priced separately.
The billing unit is one API call, deduplicated. The harness writes one transcript line per content block and every line from a single model response repeats that response’s usage figures, so calls are collapsed back to one row per model response before anything is summed.
Codebase size is non-test source lines (Go, TypeScript, JavaScript, SQL, shell) at the last commit
before 00:00 UTC on each measurement date, interpolated to the day each story started. Lead time is
the first plan transition to the first done transition.
This is one team’s production history on one codebase, not a benchmark. Two months is long enough to price a model swap and not long enough to characterise how agent cost behaves across an order of magnitude of codebase growth.
