Cost per landed PR is quota burn divided by merge commits, not by PRs you opened

Cost per PR divides your Claude Code spend by every PR you opened. Cost per landed PR divides it only by PRs that actually merged to the default branch. The gap is the quota you burned on abandoned branches, PRs that failed CI three times before you gave up, rebases you threw away, and experiments that never shipped. All of that still incremented seven_day_opus.utilization on the server. None of it ships product. On a team with a 60 percent merge rate, cost per landed PR is roughly 1.67x cost per PR, and that 1.67x is the number that matters for budgeting headcount against a Max 20x or Team Premium plan.

ccusage reads ~/.claude/projects/**/*.jsonl and reports tokens per session. It has no concept of git, no concept of merge commits, and no concept of the rolling quota buckets Anthropic actually rate-limits against. It also cannot see server-side adaptive-thinking tokens or tokenizer expansion on Opus 4.7. So it can tell you 'this session used 1.2M tokens at $15/1M input', but it cannot tell you 'that session belonged to a PR that never landed, so divide it into the abandoned bucket'. Both halves of the question require data it does not have: git merge state and the server utilization floats that ClaudeMeter pulls from claude.ai/api/organizations/{org_uuid}/usage.

Every 60 seconds the extension (see POLL_MINUTES = 1 in claude-meter/extension/background.js line 3) hits claude.ai/api/organizations/{org_uuid}/usage, timestamps the response with fetched_at (UsageSnapshot field at claude-meter/src/models.rs line 65), and posts it to a local bridge at http://127.0.0.1:63762/snapshots. That gives you a time-series of utilization floats. Join that series against git log --merges --format='%H %cI' for the window you care about, and you can compute delta-quota-per-merged-commit directly. No cookie paste. No API key. No approximations.

A merge commit on the default branch (main, master, trunk) inside the window you are measuring. git log --merges --first-parent main returns the list. Squashed merges still show up because GitHub writes a merge commit. Rebase-and-merge workflows are the one edge case: if your team disables merge commits entirely, use git log --first-parent main and filter by PR-number token in the commit message, or pull the merge list from the GitHub API instead. The important thing is the denominator counts work that shipped, not work that opened.

At minimum one full seven_day_opus cycle, because that is the rolling bucket the rate limiter cares about for Opus-heavy Claude Code work. Less than that and you get noise from whichever day you happened to pick. Four weeks is better for teams because it covers holidays, on-call rotations, and a release cadence. The utilization math stays valid at any window length as long as you also pull resets_at from each sample (Window.resets_at in models.rs line 6) and subtract across any rollovers that fell inside the window. ClaudeMeter stores resets_at on every sample, so the subtraction is automatable.

Your call, and you should be explicit about it in the report. The strict yield view counts a revert as 'didn't land' and removes it from the numerator. The shipped-once view counts it as landed because it did merge. Most teams want the strict view because the quota spent on a reverted PR produced negative value. If you are building an internal dashboard, surface both numbers so a manager can decide which one drives the conversation that week.

Code review sessions still burn the same four utilization floats and still show up in the same fetched_at timestamps. If you want to split them out, label your PRs with a marker in the commit message or branch name (feat/, review/, fix/) and bucket the deltas accordingly. The /api/organizations/{org_uuid}/usage endpoint does not know what the tokens were spent on, it only knows they were spent. The only place that distinction lives is your own tagging conventions.

Start with your plan's Opus weekly ceiling as 100 percent, sample seven_day_opus.utilization at the start and end of each calendar week, subtract to get weekly burn. Count merges to main that same week. Divide. That gives you a weekly cost-per-landed-PR in the only unit the rate limiter respects: fraction of weekly Opus quota. If you want a dollar projection on top of that, multiply the weekly burn by your plan price for the week. On Max 20x ($200 / month, roughly $50 / week) a weekly burn of 80 percent with 10 landed PRs equals about $4 per landed PR in subscription cost, compared to maybe $25 per landed PR on the API at the same token volume.

Yes. Landed means merged, regardless of which model did the work. The numerator splits cleanly: Opus-heavy work lives in seven_day_opus, Sonnet work lives in seven_day_sonnet, and both touch five_hour. So a team running 'plan with Opus, implement with Sonnet, review with Opus' will see the same count of landed PRs but different burns across the three utilization floats. The cost-per-landed-PR formula is really four formulas, one per bucket, and all four have the same denominator: merges to main in the window.

The utilization math does not change. What changes is the denominator baked into each utilization=1.0. Max 20x has roughly 20 times the per-seat ceiling of Pro; Team Premium is sized for several seats on one org. In practice a team that lands 40 PRs a week at 60 percent seven_day_opus burn on Max 20x will see the same 60 percent burn on Team Premium if they do the same work, because the ceiling scales with the plan. Cost per landed PR expressed as percentage of weekly Opus is portable across plans. Cost per landed PR expressed in dollars is not, because the subscription fee changes.

GET http://127.0.0.1:63762/snapshots returns the same JSON shape as claude.ai's server, plus the fetched_at timestamp and a list of orgs you are a member of. It is a plain HTTP endpoint on loopback, so curl + jq is enough to build a bash pipeline. If you want historical data outside the in-memory buffer, either subscribe to the bridge POSTs from the extension (extension/background.js line 2) or run the desktop Rust binary which logs to disk. The endpoint is the same in both cases, only the storage differs.