Claude Code Opus token usage: two numbers that never match, and only one decides your next 429

No. The endpoint is GET https://claude.ai/api/organizations/{org_uuid}/usage, the same one claude.ai/settings/usage renders behind the bar charts. Per ClaudeMeter's Rust model in src/models.rs lines 3-7, the Window struct that represents each bucket has exactly two fields: utilization (f64) and resets_at (Option<DateTime<Utc>>). The seven_day_opus key on the response uses that same Window. There is nowhere on the response to read 'tokens used' or 'tokens remaining' as integers. Any tool that claims to read your live server-side Opus tokens is reading something else (typically your local JSONL).

ccusage reads ~/.claude/projects/**/*.jsonl on your machine and sums the input, output, cache_creation, and cache_read token counts that Claude Code wrote to those files when it streamed. With --model opus it filters to records where model is claude-opus-* and shows that subset. Those numbers are accurate as a local accounting of what your CLI sent and received, but they are not the number Anthropic checks before deciding whether to 429 your next Opus request. Two different ledgers.

Three reasons documented in Anthropic's Opus 4.7 release notes and visible in actual usage data. First, the 4.7 tokenizer maps the same text to 1.0x to 1.35x as many tokens as 4.6 did. That expansion runs server-side, after Claude Code has already written its JSONL line. Your local sum sees the pre-expansion count. Second, adaptive thinking on Opus 4.7 generates thinking tokens that count against your seven_day_opus float; those tokens are not always written to JSONL in full. Third, your Opus quota is also touched by browser-chat sessions on claude.ai, which never write to a Claude Code JSONL at all. ccusage cannot see those.

Read both numbers, side by side, and treat them as different signals. ccusage --model opus shows what your Claude Code CLI sent on this machine, in tokens. claude.ai/settings/usage (or any tool that polls /api/organizations/{org}/usage, like ClaudeMeter) shows the seven_day_opus utilization the rate limiter actually checks, in a fraction. The first answers 'what did I send'. The second answers 'will my next Opus request 200, meter to overage, or 429'. Both are useful. Neither is a substitute for the other.

No. Typing /usage inside an active Claude Code session prints a snapshot of your session and weekly percentages, but it interrupts the loop and gives you a fraction, not a token count. It also reads through Claude Code's own session, so it does not see browser-chat usage, and it cannot see what other Claude Code sessions on other machines have used against the same org. It is fine for a one-off check. It is not a continuous meter.

Claude-Code-Usage-Monitor and similar tools also tail ~/.claude/projects/*.jsonl. They are slightly different presentations of the same local data ccusage reads. They share the same blind spots: no tokenizer expansion, no full thinking-token accounting, no browser-chat visibility. A user who relies on a local-only tool and then gets rate-limited mid-session almost always sees this gap close to zero on the local count and close to 1.0 on the server fraction.

Not reliably. The 1.0x to 1.35x expansion is not a fixed multiplier. It varies by content type (code, prose, JSON, markdown all hit different ratios) and Anthropic does not publish the per-content-type weighting. On top of that, the seven_day_opus fraction is not raw tokens divided by a fixed ceiling: it is utilization, and the denominator depends on your plan tier (Pro, Max 5x, Max 20x). Multiplying ccusage by 1.35 gives a worst-case input estimate. It does not reproduce the server fraction.

From the same JSON returned by GET https://claude.ai/api/organizations/{org}/usage, then it deserializes that into the UsageResponse struct in src/models.rs. The relevant key is seven_day_opus, which is an Option<Window>. The popup at extension/popup.js line 63 conditionally renders that window if present. The Rust CLI exposes the same field via claude-meter status. No raw Opus token count appears anywhere in the pipeline because the server does not return one.

Anthropic computes extra-usage credits server-side from the same token counts they use to update utilization, but they only expose used_credits and monthly_limit on the overage_spend_limit endpoint, not the raw tokens. So you can see your overage spend tick up in dollars without ever seeing how many extra Opus tokens that came from. ClaudeMeter pulls overage_spend_limit alongside the usage payload (src/api.rs lines 31 to 45) and shows the dollar figure. The token-to-dollar ratio is not exposed.

Same shape, different magnitude. seven_day_sonnet exists on the same usage payload. Sonnet token usage from ccusage and the seven_day_sonnet fraction also disagree, but the gap tends to be smaller because Sonnet adaptive thinking is less aggressive than Opus 4.7's. The structural answer is identical though: the server returns utilization, never raw tokens, for any model.

Two commands. brew install ryoppippi/tap/ccusage gives you the local JSONL summary. brew install --cask m13v/tap/claude-meter plus the browser extension gives you the live seven_day_opus fraction in the macOS menu bar. The extension picks up your existing claude.ai session, so there is no cookie paste step. Run ccusage when you want the raw token breakdown by model and project. Glance at the menu bar to know whether your next Opus request will go through.