Cost per merged change should count only surviving changes

Seats and tokens count what you bought, and the bill no longer sits still

Seats and tokens measure what you bought, and since agents started running for hours, the bill they add up to no longer stays still. One vendor that publishes a cost-per-merged-PR definition says those count inputs, not what shipped².

The bill is also getting harder to forecast. The largest code host has announced that every plan of its coding assistant moves to usage-based billing in June 2026³. Its stated reason is that a quick question and a multi-hour agent session were billed the same³.

A bill that moves with usage gets noticed, and one commenter on Hacker News describes the moment the questions turn into a brake.

At Acme, the rate-limit change shows up on the invoice twice and nowhere useful.

Spend per developer is uneven, so an average cost hides where it goes

AI spend lands unevenly across developers, so an average cost per change hides the heaviest users. Andrew Lau, Jellyfish's CEO, sums up his company's first-quarter 2026 data this way.

The same data puts token cost per merged PR more than three hundred times higher at the top usage tier than at the bottom⁵. These are token costs only, from the vendor CEO's own write-up of its report in a trade outlet. Read the ratio as a shape: an average across the team hides a tail that costs many times more per change.

Consumption numbers also invite gaming, which is why a raw count makes a poor target.

LeadDev quoted Narayan in a piece on teams that ranked engineers by token use. In the same piece, Ankit Jain, founder of The Hangar, says the failure was letting an onboarding metric be used for performance management⁶. The rule we draw: the number is a team figure, never a ranking of people.

At Acme, the rate-limit change took several long agent sessions; a one-line bug fix merged the same day took one prompt. Averaged together, they look the same price. Split by change, they tell the CFO where the money went.

Divide the whole bill, review and rework included, by changes that survived

The number needs a numerator that is the whole bill and a denominator that cannot be inflated. Opened PRs inflate it. In LinearB's 2026 benchmarks, even at the top 10% of organizations, 79% of agent-opened pull requests merged within 30 days, against 92% of human-only ones⁷. Divide spend by opened PRs and the agent looks cheaper than it is, because the ones that never merge still cost tokens and review.

One vendor's formula adds four terms: token spend, tool and seat spend, review time cost and rework cost, divided by PRs that merge and survive a churn window². Survived means the change was not reverted or substantially rewritten inside that window². The vendor's example window is two weeks, and we use the same length throughout this issue.

Review belongs in the cost because it is paid for. Review time climbs as AI adoption climbs, as our first issue showed⁸. None of it appears on the AI invoice.

The vendors do not agree on the definition, and a CFO should know that. A second vendor's numerator is total engineering cost, developer cost plus AI spend⁹, and its denominator is effective PRs: merged volume adjusted downward by the rework rate⁹. A third leaves seats out entirely and says its figure "isn't your invoice"¹⁰. It calls its unit costs "directional rather than exact"¹⁰.

The FinOps Foundation names the gap in the token-only view.

We recommend keeping seats in, because the CFO reconciles to the bill. Put rework in the cost, because hours are what finance pays for. Then keep one definition, unchanged, every month. No source we found tested which definition a CFO accepts.

At Acme, the rate-limit change merges, then is substantially rewritten inside two weeks after it throttles a large customer's batch job. Its seat share, tokens, review and rework hours stay in the numerator, and it leaves the denominator. That is the change the CFO's number must not count as delivered.

A falling cost per change can hide falling stability, so report it with a pair

A rate that only divides can fall for the wrong reason: more changes merge and more of them break. DORA's 2025 report still finds a negative relationship between AI adoption and delivery stability¹². Its 2024 and 2025 reports disagree on whether AI speeds delivery, and in both, stability suffers as adoption rises¹³¹².

Nor can the team's sense of speed stand in for a measurement. In METR's randomized trial, experienced open-source developers took longer with AI tools, yet still believed AI had sped them up by 20%¹⁴.

The trial was small and used early-2025 tools, so read it as a warning about self-report. Quality signals point the same way: Uplevel's 2024 observational study saw a 41% higher bug rate for developers given an AI coding assistant, with throughput flat¹⁵.

So pair the rate with change failure rate, and add review time if you track it; that pairing is our advice, and these studies did not test it. Suppose Acme counted the rate-limit change as merged. The month's rate would fall, and only change failure rate beside it would show the month went badly. The survival rule catches a rewrite inside two weeks; the pair catches what breaks after it.

Take it to the CFO as a monthly trend with its pair and one story

Bring the CFO one rate every month, with change failure rate beside it, review time if you track it, and one change told start to finish. The CFO's problem is control, as a senior engineering leader put it at a Toronto CTO dinner held under Chatham House rules.

A rate shows the CFO what the contract buys each month, and it can be checked against the bill. At the same dinner, a leader said larger organizations expect a return within 12 months¹⁶. That clock belongs to larger companies, but it tells you how soon the question will come.

Numbers alone will not carry it. Jellyfish's board-reporting template warns that even great metrics draw a "so what" without narrative context¹⁷. That template looks back over the prior quarter; we suggest monthly because usage billing moves monthly.

What to do on Monday

1. Reconcile to the bills. Total last quarter's AI spend, seats and usage, from the invoices themselves, since a dashboard estimate leaves lines out.
2. Add the hours. Put review and rework hours in the cost at loaded rates; sample a month if you do not track time.
3. Count what survived. Count changes merged last quarter that were not reverted or substantially rewritten within two weeks.
4. Look at the spread. Split the result by team and usage tier before you average it, and never rank people by it.
5. Report the pair. Send it monthly with change failure rate beside it, review time if you track it, and one change told start to finish.

The companion, The AI ROI playbook, is free with your work email.