What a Claude Code PR actually costs is a delta on seven_day_opus.utilization, not a dollar amount

On a Pro or Max subscription, open claude.ai/settings/usage (or run ClaudeMeter) right before you start the session that becomes your PR, and record seven_day_opus.utilization and five_hour.utilization. Do the same right after the last commit. The delta on seven_day_opus is what the PR cost you against the Opus-only weekly ceiling. The delta on five_hour is what it cost against the shared 5-hour ceiling. You are not looking for dollars. You are looking for two fractions, both of which have to stay under 1.0 for your next Claude Code request to succeed.

ccusage reads ~/.claude/projects/**/*.jsonl and multiplies the tokens it finds by the public API list price. That number is correct for API usage, where Anthropic actually bills you in dollars per million tokens. Subscribers do not pay that. You pay a flat $20, $100, or $200 a month. The 'dollar cost' your PR rang up is genuinely $0 beyond your subscription fee. The resource it consumed is a percentage of your rolling windows. That is what can run out mid-PR, and that is what ccusage has no way to read.

GET https://claude.ai/api/organizations/{your_org_uuid}/usage, the same endpoint the Settings page calls. The browser extension calls it at claude-meter/extension/background.js line 24 and polls every minute (POLL_MINUTES = 1 on line 3). The desktop Rust client calls the same URL at claude-meter/src/api.rs line 19. Both deserialize into the struct declared at claude-meter/src/models.rs line 19 to 28, so five_hour, seven_day, seven_day_sonnet, and seven_day_opus land in the same response.

For a realistic PR, yes. The two floats that matter on Opus 4.7 both update server-side within seconds of the request landing, and the resets_at rollover is either 5 hours out or days out. A PR that spans 20 minutes of Claude Code time gets sampled roughly 20 times by the extension. The math only breaks if your session crosses a five_hour resets_at, in which case the 5-hour float snaps back to 0 mid-session. seven_day_opus resets weekly so that almost never happens inside one PR.

It shows up in a different field, not in seven_day_opus. Look at extra_usage.utilization in the same payload (field declared at claude-meter/src/models.rs line 10 to 16). Once your subscription floats hit 1.0, requests start burning overage credits instead of the weekly bucket, so seven_day_opus stops climbing and extra_usage.used_credits starts climbing. For an end-to-end PR cost on a subscriber who flipped to overage mid-session, you need three deltas: seven_day_opus, five_hour, and extra_usage.used_credits.

No. Sonnet requests flow into five_hour (shared) and seven_day_sonnet (Sonnet-only weekly). seven_day_opus is untouched. That is why 'switch the small edits to Sonnet' is the most common cheap optimization, and why the cost of a PR depends heavily on which model ran which step. A PR with 10 percent Opus planning and 90 percent Sonnet cleanup can be cheaper on the Opus weekly float than a single deep Opus session even if the Sonnet run logged more tokens in ccusage.

Yes, and they are invisible to ccusage. Opus 4.7 runs adaptive thinking by default, with display set to omitted. Thinking content is generated server-side and billed against seven_day_opus, but it is not always written to your local JSONL in full. So the delta you read off the server endpoint is larger than the token sum ccusage would report for the same session. Both are real numbers, they just answer different questions: ccusage reports what your model output; the endpoint reports what your plan's rate limiter saw.

There is no honest universal answer because it depends on model mix, plan, effort level, and how agentic the session was. What the product gives you is the ability to measure your own number. Run ClaudeMeter during a single PR, note the delta, and you have your personal cost-per-PR on that plan. Published benchmarks that quote 'about 3 percent per PR' or 'Max 20x gets 100 PRs a week' are converting messages to floats through guesses; the delta on your own account is the only number the rate limiter cares about.

Yes. The extension posts every snapshot to a local bridge at http://127.0.0.1:63762/snapshots (extension/background.js line 2). If you run the desktop binary, it exposes the same data on the same loopback port. A git hook on post-commit that curls the bridge and appends seven_day_opus.utilization to a log file gives you a per-commit trail, and diffing the first and last sample for a branch gives you cost-per-PR directly. The endpoint returns JSON so the hook is about four lines of shell.

Yes, because the endpoint is per-organization. On a Team or Enterprise org, /api/organizations/{org_uuid}/usage still returns the same four utilization floats under the org you are authed into. Different plans just change the denominator baked into each utilization fraction. ClaudeMeter reads the fraction verbatim, so whatever plan you are on, the delta math is the same.

The next Claude Code request returns 429, the session pauses, and the delta you measured up to that point is the partial cost of the PR so far. When five_hour rolls over (see resets_at in the same payload), the float drops and you can resume. The seven_day_opus float does not reset at that time, so the resume cost keeps accumulating on the weekly bucket. This is the main reason subscribers care about the delta, not about dollars: a PR that rang a 429 mid-session does not cost more money, but it did cost you real minutes of blocked Claude Code time.