What Our Coding Agent Costs Per Accepted Change
We have run an agent on our own repositories for long enough to have a real cost per accepted pull request. It is higher than the token bill suggests and lower than the hour it replaces, and the gap between those two numbers is where every argument about this actually lives.
The Number We Started With
Token cost per pull request the agent opens. It is easy to measure, it appears on an invoice, and it is roughly a fifth of what the agent actually costs us. Quoting it is how a business case for an agent gets approved and then quietly fails to deliver.
The rest is review. Every proposal is read by an engineer, including the ones that are rejected, and a rejected proposal costs a review with nothing to show for it. Our acceptance rate is a bit under a third, so most reviews produce nothing.
What We Measure Now
Four numbers: tokens per proposal, review minutes per proposal, acceptance rate, and the engineer-time the accepted change would otherwise have taken. The fourth is an estimate, made by the reviewer at acceptance, and it is the only one that connects the agent to value.
Cost per accepted change is then tokens plus review over the acceptance rate, which makes explicit that rejected proposals are paid for by the accepted ones. At a third acceptance, each accepted change carries roughly three reviews.
The Research on the Same Trade
Peng and colleagues published work in 2026 on the inference economics of enterprise coding agents, comparing frontier models accessed by interface against quantised open-weight models run on premises, and treating the choice as an economic question rather than a capability one.
That is the same framing we reached from the invoice side. What their comparison adds is the marginal-cost argument for on-premise inference at volume, which matters for a team running agents continuously and did not change our answer because our volume is modest.
| Cost element | Share of the total |
|---|---|
| Tokens for accepted proposals | About one fifth |
| Tokens for rejected proposals | About one tenth |
| Review of accepted proposals | About one quarter |
| Review of rejected proposals | The largest single share |
What Changed When We Measured It
We narrowed what the agent attempts. It used to attempt any failing test; it now attempts only failures matching patterns where our acceptance rate has been above half, which is about a third of failures and most of the ones that were being accepted anyway.
Proposals fell by roughly sixty percent, accepted changes fell by about fifteen, and cost per accepted change fell by nearly half. The agent does less and delivers almost as much, which is the shape of most honest optimisations and is not what anyone hoped to find.
The Number That Decides It
Review minutes per rejected proposal. Ours is about four, because a rejected proposal is usually obviously wrong and a reviewer can see it quickly. If it were twelve, the agent would cost more than it saves at our acceptance rate, and we would switch it off.
That threshold is worth stating because it depends on the reviewer's experience with the codebase rather than on the model. A team where reviews are slow gets less from an agent, and no model improvement changes that arithmetic.
What We Do Not Count as a Saving
Time the agent spends that nobody was waiting for. It works on failures overnight, and the fact that a fix exists at nine in the morning is convenient rather than a saving unless someone would otherwise have done it.
We also do not count the changes that would never have been made. About a fifth of accepted proposals fix things nobody had prioritised, which is real value and is not a cost saving, and putting it in the saving column is how these numbers become fiction.
Cloud or On Premises for This Workload
Cloud, for us, and the reasoning is the same as everywhere else in this blog. Our volume is a few hundred proposals a month, which is far below where fixed infrastructure wins, and the operational burden would fall on the same small team that reviews the proposals.
The calculation flips at scale, which is what the research examines. A team producing thousands of proposals a month has a different answer, and we would run the comparison rather than assume our result transfers.
What We Do Not Claim
We do not claim our cost per accepted change generalises. It is our codebase, our test suite, our reviewers and our acceptance criteria, and the largest term is review time, which is the most team-specific quantity in the calculation.
We also do not claim the agent is clearly worth it. At our numbers it is worth it by a margin small enough that a worse acceptance rate or slower reviews would reverse it, and we recheck quarterly rather than treating the decision as settled.