Cost per merged PR is a quarter's AI coding spend (seats, metered tokens and overage, from your invoices) divided by the human-authored pull requests merged in that quarter, computed per team. It tells you what you paid per shipped change, and finance can check every input against invoices and GitHub. It isn't ROI. It's the cost half. AI makes pull requests cheap to produce, so a PR count says little about what shipped, and a falling cost per PR can mean more small changes rather than more value. To get at return, put three things beside it: the share of agent spend that went into rework, the kind of work each team did, and how significant the shipped work was.
As of November 2026. The company in the example is fictional. The one public benchmark is linked and dated.
Computing it so it holds up
The division is trivial. The work is in deciding what each side counts and keeping those decisions fixed so this quarter compares with last.
The numerator is every way money leaves for agents: per-user seats (including the ones nobody opens), metered API usage billed directly or through a cloud provider, and overage, which often lands on a different invoice line or a different card. Take the total from invoices, because that's what finance reconciles against. Usage dashboards and session-level estimates are fine for splitting the total by team, but they don't carry negotiated discounts. Where a team's share isn't on an invoice, allocate seats by headcount and metered usage by each team's share of tokens.
The denominator starts with every PR merged in the period and removes what a person didn't write. Bot PRs (Dependabot, Renovate, release automation) can be a large share of the count and cost the agent budget nothing. For reverts, pick a rule and keep it: drop the revert PR and keep the original, or drop both because the original didn't stick. How to measure the ROI of AI coding tools uses the stricter rule and counts reverted changes as zero. GitHub search gets you the raw count; is:pr is:merged merged:2026-07-01..2026-09-30 -author:app/dependabot returns Q3's merged PRs minus Dependabot's. GitHub documents the merged qualifier and author exclusions.
Use quarters. PRs merge days or weeks after the sessions that produced them, so a monthly figure puts a noticeable slice of work in the wrong month. Over a quarter the lag mostly washes out.
Compute it per team, never per person. Teams own a kind of work, a codebase and a review culture, and those set what a PR costs far more than any individual does. A per-person figure punishes whoever took the migration and invites people to manage the number instead of the work.
Add salaries for the all-in view
AI spend is a small part of what a PR costs. Jellyfish's AI Engineering Trends report (October 2026, data from 1,300+ companies) defines cost per PR as "the all-in cost of a merged pull request: engineering salary cost plus priced AI usage," and found that "AI's direct slice of the cost is small, about $18 of the $799 average." Over the past year, it reports, "the median company's cost per merged PR fell by about a third, from $1,202 to $820," driven by throughput: "Companies merged more PRs per engineer while salary cost held about flat."
So compute both: agent spend ÷ merged PRs, and (loaded salary cost + agent spend) ÷ merged PRs. The all-in number answers whether the agent line is moving the salary line. An extra $10 of agent spend per PR is a good trade if it takes $100 of salary cost per PR with it and the PRs didn't just get smaller.
Larkspur Freight, a fictional logistics software company, has 24 engineers in three teams, a loaded cost of $45,000 per engineer per quarter, and $60,000 of agent spend in Q3.
| Team | Engineers | Agent spend | Merged PRs | Agent cost per PR | All-in cost per PR |
|---|---|---|---|---|---|
| Platform | 10 | $36,000 | 400 | $90 | $1,215 |
| Payments | 8 | $18,000 | 360 | $50 | $1,050 |
| Mobile | 6 | $6,000 | 240 | $25 | $1,150 |
| Total | 24 | $60,000 | 1,000 | $60 | $1,140 |
Platform pays more than three times what Mobile pays in agent spend per PR. That isn't a verdict. Platform spent Q3 on infrastructure and a cross-service schema change; Mobile mostly shipped UI changes. Larkspur's all-in figures sit above Jellyfish's average, as you'd expect for a small company paying US salaries. Compare each team with its own trend.
Why it isn't the return
The trouble is the denominator. A merged PR used to be a rough proxy for a unit of work, because producing one took real effort. AI broke that: an agent can open ten PRs in an afternoon, and each counts the same as a feature a customer asked for. We made the longer argument in the output was never the work.
Three consequences follow. PR size moves the number more than efficiency does: split one change into four PRs and cost per PR falls by three quarters with nothing else different. The denominator includes PRs written without an agent, which flatters low-adoption teams. And a falling cost per PR says you pay less per unit without saying whether the units mattered. Report the number; don't set a target for it.
What to put next to it
Rework share. The share of a team's agent spend in sessions where the agent kept redoing its own work: wrong guess, failing test, rewrite, failing test again. This is the part of the cost you can cut without doing less, usually by fixing something dull like a missing repo instruction or a flaky test. It's also the column you can't get from invoices or GitHub. It lives in the sessions, and a team's quarter holds too many sessions to read by hand. The post on averages shows what rework loops look like up close.
Kind of work. Classify merged changes as feature, bug or maintenance work, and note each team's main focus for the quarter. When cost per PR moves, the first question is whether the work changed. A migration quarter should cost more per PR than a quarter of small fixes, and you should know that in advance.
Significance of what shipped. This is where return starts. Without a tool, have each tech lead tag a random sample of the team's merged PRs, say 30 a quarter, as small, medium or large, weighted 1, 3 and 8. Keep the rubric fixed across quarters so the trend means something. Then write a paragraph per team on what the quarter's most significant shipped work did for the business. The weighted tags tell you whether the work got bigger or smaller; the paragraph is what a CFO actually reads. Maestro does the tagging automatically, scoring every merged PR for scope, complexity and effect and categorizing each change, so you get every PR instead of a sample. Those scores describe the significance of the work, not its business value. The paragraph stays your job.
When a rising cost per PR is fine
Apply this per team each quarter.
It's fine if the rework share held or fell and your significance tags show the work held its size or shifted toward something you planned to be expensive. A falling all-in cost per PR doesn't qualify on its own; splitting work produces it too.
It's a problem if the all-in cost per PR rose, the rework share rose, and the work didn't get bigger or change in kind. The extra spend is going into loops, and the sessions will say why.
Here's Larkspur's Q4 for two teams.
Payments: up, and fine. Agent spend rose from $18,000 to $27,000 and merged PRs from 360 to 450, so agent cost per PR went from $50 to $60. All-in fell from $1,050 to $860 (($360,000 + $27,000) ÷ 450). Rework share was flat, and the lead's sample showed the same mix of sizes, so the extra PRs were real work. Payments spent $9,000 more on agents and paid $190 less per PR.
Platform: up, and a problem. Agent spend rose from $36,000 to $48,000 while merged PRs fell from 400 to 375, so agent cost per PR went from $90 to $128. All-in rose from $1,215 to $1,328 (($450,000 + $48,000) ÷ 375). Fewer PRs could have meant bigger work, but the lead's sample tags showed the same mix of sizes, and no migration was planned. The rework share rose from 15% to 32% of the team's agent spend. A dozen of the heaviest sessions told the same story: a new integration test suite failed intermittently, so agents kept rewriting code that was already correct. Fixing the suite took two days.
Both numbers rose. Only one needed attention, and cost per PR alone couldn't say which.
For a quarterly review, give one row per team with last quarter alongside: agent spend, merged PRs, agent and all-in cost per PR, rework share, kind of work, and the significance paragraph. If it's going to the board, it belongs inside a wider view of where engineering time went; see how to report engineering ROI and capacity allocation to the board.
Where VibeCheck and Maestro fit
VibeCheck captures Claude Code, Codex and Cursor sessions on each engineer's laptop and estimates each session's cost from its tokens, along with the kind of work and how it went, including rework. Filter a team's heavy-rework sessions on the Sessions page, see what they cost, and open one to read what happened. On Pro, with the GitHub App connected, it reports cost per authored PR: captured spend over human-authored PRs, bots excluded. That's authored, not merged, and the costs are estimates, so use your invoices for the total. Get started for free.
For the return half, Maestro scores and categorizes every merged change and writes up what each team shipped and why it mattered. Book a walkthrough.