The only dollars-per-PR number that is real money on Claude Code lives in one undocumented endpoint

On any subscription plan (Pro, Max 5x, Max 20x, Team Premium, Enterprise), the only Claude Code activity that produces a real card charge is overage. Anthropic exposes that number at one undocumented endpoint: GET https://claude.ai/api/organizations/{your_org_uuid}/overage_spend_limit. Look at the used_credits field, divide by 100 to convert cents to dollars, snapshot it at first commit, snapshot at last commit, subtract. That delta is the dollars-per-PR figure that will appear as an extra Stripe charge separate from your flat monthly fee. Until at least one rolling-window utilization passes 1.0, that delta is exactly $0.00, no matter how many tokens ccusage says you spent.

ccusage reads ~/.claude/projects/**/*.jsonl, sums the tokens, and multiplies by Anthropic's public API list price ($15 per million input, $75 per million output for Opus 4.7). That math is right for an API account because Anthropic actually bills you per million tokens. On a $20 Pro plan or a $200 Max plan you do not pay per million tokens, you pay flat. The dollar figure ccusage prints is what the same work would have cost you if you had been on the API. It is a counterfactual, not an invoice line. The real invoice line is in Stripe and is driven entirely by the overage_spend_limit endpoint described above.

claude-meter/src/format.rs at line 25 reads `let u = ov.used_credits.unwrap_or(0.0) / 100.0;` and lines 27 to 30 do the same for monthly_credit_limit. The reason is that Anthropic returns both fields denominated in cents on the /api/organizations/{org_uuid}/overage_spend_limit endpoint, the same convention Stripe uses internally for amounts. ClaudeMeter's menu-bar dollar reading (`$3.42 / $40.00 (9%)`) is literally `cents / 100.0`. If you write your own client and forget to divide, you will report 100x your real overage spend.

Sort of. The /api/organizations/{org_uuid}/usage payload has an extra_usage object (declared at claude-meter/src/models.rs lines 9 to 16) with a used_credits field that mirrors the overage endpoint's used_credits. It is the same number expressed two ways: extra_usage.used_credits on /usage is the running cents-spent counter, while /overage_spend_limit returns the same counter alongside the cap and currency. Either source works for the dollars-per-PR delta as long as you remember the cents-to-dollars conversion. ClaudeMeter samples the overage endpoint so it can also surface the cap and the disabled_until lockout date.

Yes, if you have already burned through the rolling windows by the time the PR starts. On Pro, once any of the four utilization fractions on /usage hits 1.0 (typically five_hour or seven_day_opus), Claude Code requests start drawing from extra_usage.used_credits instead of refusing. That is when the dollars start counting. A heavy Opus session that runs after your weekly bucket is exhausted can post genuine dollars to the same Stripe customer the subscription is billed against. The overage_spend_limit endpoint includes monthly_credit_limit (also in cents), which is the cap you set so this cannot run away.

Look at claude-meter/src/format.rs lines 24 to 39. The render is shaped like `Extra usage $3.42 / $40.00 (9%)` if you set a cap, or `$3.42 used (no cap)` if you did not. If Anthropic flips out_of_credits to true, ClaudeMeter appends `BLOCKED`. If a disabled_until is set (because you tripped the cap), it appends `until <date>`. Every value in that line comes from the same overage_spend_limit response, divided by 100 where needed. Watching that line move during a PR is the live, honest dollars-per-PR signal.

Because the endpoint requires your live claude.ai session cookies; it is not part of the public API. ccusage and Claude-Code-Usage-Monitor read your local JSONL files instead, which is auth-free and works offline. ClaudeMeter is the path that calls the cookie-protected endpoint directly. The browser extension calls it from extension/background.js (the same browser is already authenticated to claude.ai), and the desktop client calls it from src/api.rs after lifting cookies from your local browser keychain. There is no way to get the real dollar figure from your local logs alone, because the local logs do not know your subscription state.

It still returns. The OverageResponse struct at claude-meter/src/models.rs lines 30 to 40 has is_enabled (bool), monthly_credit_limit (Option<i64>, in cents), used_credits (Option<f64>, in cents), currency (Option<String>), disabled_reason (Option<String>), disabled_until (Option<DateTime<Utc>>), and out_of_credits (bool, defaults false). When overage is off, is_enabled is false, used_credits stays at 0.0, and out_of_credits is irrelevant. Your dollars-per-PR is then guaranteed to be $0 and the question collapses; what you really care about in that case is the four utilization fractions on /usage, which is the rate-limiter signal.

It accumulates within a billing period and resets at the next charge. The reset cadence is on the subscription endpoint, not the overage endpoint; check subscription_details.next_charge_date (declared at claude-meter/src/models.rs line 53). For dollars-per-PR you only care about the delta between two snapshots in the same period, so the reset is mostly a footnote unless your PR straddles a billing rollover. ClaudeMeter snapshots both endpoints together so it can detect a reset and not report a negative delta.

currency is a lowercase three-letter ISO 4217 code on both the overage_spend_limit response and the subscription_details response. For individual Pro and Max subscribers it almost always returns 'usd' regardless of where you are in the world (your card network handles FX on the way to your bank). For Team and Enterprise plans it can return 'eur', 'gbp', and so on. Either way, the used_credits value is in the smallest unit of that currency: cents for usd, eurocents for eur, pence for gbp. Dividing by 100 is correct in all three cases.

Within seconds, server-side. ClaudeMeter samples it once a minute (POLL_MINUTES = 1 at extension/background.js line 3), which is dense enough to capture per-PR deltas accurately. If you want sub-minute resolution for a forensic read on one specific PR, point your own polling at /api/organizations/{org_uuid}/overage_spend_limit at any cadence; the endpoint is read-only and idempotent and Anthropic does not rate limit it harshly.