The Opus cost of a PR is one field, and the menu-bar badge is showing you a different one

It is the delta on seven_day_opus.utilization between your first and last commit on the branch, read from claude.ai/api/organizations/{org_uuid}/usage. Not a dollar figure, not a token count, not the shared 5-hour number. If that field was 0.62 when you started the PR and 0.66 when you merged, the PR cost you 4 percent of your weekly Opus ceiling. That is the only number the rate limiter checks before it decides whether to let your next Opus request through.

The badge is intentionally tied to five_hour, not seven_day_opus. Look at claude-meter/extension/background.js lines 80-87: const five = worstPct(snaps, 'five_hour'); then chrome.action.setBadgeText and setBadgeBackgroundColor both branch on that five variable. There is no branch on Opus. A PR that is 90 percent Opus planning will push seven_day_opus hard while five_hour might be resetting every few hours. The glance-layer reading from the badge is the 5-hour number; if you care about Opus cost per PR, you have to open the popup (popup.js line 63) where seven_day_opus is listed, or hit the local bridge at 127.0.0.1:63762 and read the field yourself.

A general cost-per-PR reading returns four deltas: five_hour (shared across all models), seven_day_opus (Opus only, weekly), seven_day_sonnet (Sonnet only, weekly), and extra_usage.used_credits (overage). Opus cost per PR collapses that to one number: the delta on seven_day_opus alone. A PR with heavy Sonnet cleanup can have a big five_hour delta and a tiny seven_day_opus delta, which is exactly the mix most cost-conscious teams aim for. Budgeting weekly Opus PRs is a different problem from budgeting shared 5-hour headroom, and it uses a different field.

Only Opus requests. Every Claude Code call on Opus 4.7 increments seven_day_opus AND five_hour on the server. Sonnet calls increment seven_day_sonnet AND five_hour, but leave seven_day_opus untouched. This is why teams that switch the small steps (formatting, unit-test generation, type fixes) to Sonnet see their Opus weekly drift up more slowly across a PR. The struct declaration is in claude-meter/src/models.rs lines 18-28 — seven_day_opus is a sibling of seven_day_sonnet, not the same field.

Yes. Opus 4.7 runs adaptive thinking with display set to omitted by default. The thinking tokens are generated server-side and billed against seven_day_opus in the same way normal output tokens are. They are often not written in full to the local JSONL that ccusage reads. So for an Opus-heavy PR, the delta on seven_day_opus will be measurably larger than the delta a local-token tool projects. The utilization field already incorporates them; that is one of the reasons the server-truth read is the correct per-PR number on a subscription.

Divide the remaining Opus headroom by your measured Opus cost per PR. If the extension popup says 7d Opus is 64 percent, you have 36 percent left. If your last three merged PRs cost 3, 4, and 5 percent respectively (averaging 4 percent), you have roughly 9 more Opus PRs of similar scope this week before the float hits 1.0 and you flip to overage. This is a rolling 7-day window, not a calendar week; the resets_at timestamp on the same Window struct tells you exactly when the oldest usage rolls off.

ccusage answers 'if I had paid Anthropic at the API list rate, what would this session have cost?' That is a useful number for API accounts; it is a phantom number on a subscription. seven_day_opus.utilization answers 'how close am I to the Opus wall the rate limiter actually enforces?' Subscribers need both answers to different questions. Most teams use ccusage to watch model-mix trends and seven_day_opus to watch 429 risk, specifically on the Opus bucket that Sonnet does not share.

The design choice in background.js was single-number simplicity. The badge is a 2-to-3 character widget; it can only show one percent. five_hour was picked because it is the first thing to 429 you in a burst. That works for a Sonnet-heavy Claude Code user, it undersells risk for an Opus-heavy one. If you want an Opus-first badge, you can fork background.js to change line 80 to worstPct(snaps, 'seven_day_opus'), rebuild the extension, and load it unpacked. The popup already reads the field.

Yes. The extension posts each snapshot to http://127.0.0.1:63762/snapshots (extension/background.js line 2). A post-commit hook that curls that URL and writes snapshots[0].usage.seven_day_opus.utilization to a file, plus a branch-close step that subtracts first and last, gives you Opus cost per PR in CI. The JSON shape is guaranteed by the Rust struct at claude-meter/src/models.rs line 23 (pub seven_day_opus: Option<Window>), so the parse is a one-liner in jq: .[0].usage.seven_day_opus.utilization.

The next Opus Claude Code request returns a 429 specifically about the Opus limit. If extra_usage is enabled, subsequent Opus calls start spending overage credits instead of the Opus bucket, and seven_day_opus stops climbing because it is already at 1.0. extra_usage.used_credits on the overage_spend_limit endpoint starts climbing instead (see claude-meter/src/models.rs line 30-40). So for a PR that crossed the Opus ceiling, the full Opus cost is: (1.0 minus starting seven_day_opus) plus the delta on extra_usage.used_credits divided by your per-credit Opus rate. Two fields, not one.

Yes, and this is the subtle point. The numerator and denominator of seven_day_opus.utilization both depend on which plan you are on. A Max 20x subscriber and a Pro subscriber can both see 0.62, but the absolute Opus token budget behind those two readings is very different. ClaudeMeter reads utilization verbatim from the server, which is why the delta math works identically for every plan: it is a fraction of whatever your personal ceiling is, and the cost-per-PR delta is 'how much of my personal ceiling did this PR spend.' That is the only number that predicts your own next 429.