What a merged pull request costs

Token prices are public. What a unit of finished work costs is not — almost nobody measures it, because it needs agent spend and business outcomes joined on the same key. BurnLens does that on itself, across every repository it was used to build, so this page is our own number with the arithmetic shown.

The headline is not a number. It is a 12x spread. The same developer, the same agents, the same models produced merged pull requests costing $6.84 on one repository and $84.94 on another. Blended across all of them it is $32.55, and that blended figure is the least useful number here — it hides exactly the variance worth acting on.

Cost per merged pull request, by repository

4 of 13 repositories have a unit cost. The other 9 are in the second table below, with the reason each one has no number.

Why the spread is this wide

Nothing here says the dear repositories were run badly. A unit cost is a ratio, and both halves move:

• Small denominators are loud. A repository with two merged pull requests divides real spend by two. Read the merged column before the cost column — one number in this table rests on a sample of 2.
• Not all agent work becomes a pull request. Exploration, debugging, spikes and abandoned branches cost money and merge nothing. A repository used mostly for investigation will always look expensive per PR, and that is a true statement about the work, not a defect in the measurement.
• Pull request size is not held constant. One merged PR is not one unit of work across repositories. This measures the cost of the granularity each repository actually used.

That is the honest reading, and it is still actionable: a 12x spread tells you where to look first, which is more than a token dashboard has ever told anyone.

Repositories with no unit cost

Two different reasons, and the distinction matters. Most of these repositories are trunk-based — work lands on the default branch and no pull request is ever opened, so there is no accepted outcome to divide by. Outcomes are derived through the GitHub CLI, so a repository whose remote lives elsewhere cannot report them either.

One row is different: ShubhLifafa has 31 merged pull requests and still no unit cost, because every one of them closed outside the window where its spend was measured. That is the window rule below, visible.

The method, including where it is weak

• A merged pull request is the accepted outcome. Closed-unmerged is a rejected one. Both come from git, not from a form somebody remembered to fill in — cost-per-outcome products usually die on instrumentation nobody wires up.
• Total spend divides by accepted outcomes, not just successful spend. Rejected and abandoned attempts cost real money. Charging that to the pull requests that landed is what one merged PR actually costs.
• Each repository’s window is its own, and it is an intersection. Telemetry for a repository starts when the proxy first saw it; git remembers pull requests from well before that. Outcomes outside a repository’s spend window are excluded, because no telemetry backs them. Counting them would divide the same spend by a bigger number and quietly understate the unit cost — on this repository it is the difference between $6.84 and $5.43.
• Attribution is per repository, not per pull request. Agent session logs record which repo a session was in, never which branch. With several PRs in flight at once, every number here is an average, not a per-PR invoice.
• The blended figure is spend-weighted, not an average of the rates. A mean of ratios would weight a 2-PR repository the same as a 104-PR one.
• Human time is not in it. This is API spend only — the AI cost of the work, not its fully loaded cost.

Why the token mix matters more than the token price

71.8% of prompt tokens across all 13 repositories were prompt-cache reads — 6,899.4M cached against 2,708.8M fresh input. A coding agent re-sends its whole context every turn, so almost everything it reads is a cache hit billed at a fraction of the input rate.

Estimate this workload off the input column of a price list and you are wrong by close to an order of magnitude. Output was only 16.6M tokens — well under one percent of everything moved.

What is not in the number

The database behind this page holds $11,214.93 of measured spend. Only $4,758.10 of it carries a workflow id, and the 13 repositories published here account for $4,588.97 of that. None of the remainder is in any division above.

Most of the unattributed $6,456.82 is older agent-log scans imported before workflow tagging existed. A little of it carries a workflow id that is not a repository at all — an artifact of how session logs encode a working directory — and those are excluded rather than published under a name nobody could look up.

We publish this because a unit-economics number without its attribution coverage is not checkable, and the honest version of the metric is the one that shows what it left out.

Measure your own

Cost per accepted outcome is the question token dashboards cannot answer: a model that looks cheaper per token can cost more per merged PR once retries and rejected work are counted, and a 12x spread between your own repositories is invisible until you measure it. BurnLens is a local proxy that does — pip install burnlens, one environment variable, and merged pull requests are derived from git with nothing to integrate.

Read the docs · Scan existing agent logs · LLM pricing table · See the dashboard