The Claude Code 4.7 regression that shows up in your quota, not your benchmarks

The quota regression. 4.7 uses a new tokenizer that expands text roughly 1.0x to 1.35x compared to 4.6, and its adaptive thinking mode generates more hidden output tokens than 4.6 did. Both expansions are applied server-side before Anthropic writes the usage float to your seven_day_opus bucket. The result is that the same Claude Code session, run against the same repo, can fill your Opus weekly utilization 20 to 35 percent faster on 4.7 than it did on 4.6. This is not covered by any of the popular benchmark writeups on this release because it does not show up in accuracy scores or eval suites; it only shows up on claude.ai/settings/usage.

Those tools read the JSONL that Claude Code writes under ~/.claude/projects/. That file records a token count produced by the client before Anthropic applies the 4.7 tokenizer, and it excludes adaptive-thinking tokens when the client hides them (display: omitted). Anthropic's server applies the tokenizer expansion and counts the hidden thinking tokens after the JSONL is written, then writes the result to your seven_day_opus.utilization float. The local log and the server quota disagree by exactly the amount of the regression. The only way to close the gap is to read the server's /api/organizations/{org}/usage endpoint, which is what ClaudeMeter's src/api.rs does on every 60-second tick.

It's the seven_day_opus field on UsageResponse at src/models.rs line 23. The type is Option<Window>, where Window has a utilization float and a resets_at timestamp. The extension posts the parsed struct to 127.0.0.1:63762/snapshots as JSON on every tick, so any process on your machine can curl that URL and read the authoritative 4.7-inflated number. The menu-bar app renders the same float as '7d Opus' in extension/popup.js line 63.

Yes, and they're well-covered elsewhere. Anthropic's own release notes for 4.7 call out a regression in long-context recall above roughly 100K tokens, specifically in needle-in-a-haystack style tasks. Independent reports cite a 4.4 point drop on BrowseComp (83.7 to 79.3), higher latency than 4.6, and reduced stylistic flexibility on creative tasks. Those are real and worth knowing. The one I focus on here is the one that empties your weekly Opus bucket before Friday, because that's the one that stops your Claude Code session mid-refactor.

There's no published ratio because the expansion is per-prompt and content-dependent. Anthropic's own 4.7 documentation describes the tokenizer as using 1.0x to 1.35x more tokens for the same input text. Adaptive thinking on top of that adds a variable output-side cost that 4.6 did not have. In practice you can read the ratio yourself: run the same prompt on 4.6 and 4.7 back-to-back, then diff the seven_day_opus.utilization float returned by /api/organizations/{org}/usage before and after each call. ClaudeMeter's localhost bridge makes this a two-curl experiment.

No. The 5-hour window (usage.five_hour.utilization) is shared across every model. The Opus weekly window (usage.seven_day_opus.utilization) is Opus-only and independent. A 4.7 session can pin the Opus weekly float while leaving the 5-hour float at 30 percent, because Sonnet traffic doesn't contribute to seven_day_opus. The popular confusion is to watch only the 5-hour bar on claude.ai and assume the Opus weekly is in proportion. It isn't, and 4.7's tokenizer expansion widens the gap further.

This page is about the subscription quotas (Pro, Max 5x, Max 20x) that power Claude Code when it's signed into claude.ai. API billing uses different accounting: it bills per-token by the 4.7 tokenizer too, so the same text costs more on the API than it did on 4.6, but it doesn't land in a seven_day_opus bucket. If you run Claude Code on an API key, the regression shows up as a higher invoice rather than an earlier 429. The /usage endpoint ClaudeMeter reads is specific to the subscription plan.

Not directly. The /usage endpoint returns only the current utilization fractions and their reset timestamps, not per-request metadata. What you can do is compare deltas: poll /api/organizations/{org}/usage before a prompt, run the prompt on 4.7, poll again. The delta in seven_day_opus.utilization represents the server-side token count for that single call, already expanded. ClaudeMeter caches every snapshot the extension fetches, so you can diff two ticks that bracket your prompt and see the real cost.

Three of them. extension/background.js line 24 fetches /api/organizations/{org}/usage for utilization (seven_day_opus lives in that payload). Line 26 fetches /api/organizations/{org}/overage_spend_limit to see whether 4.7 requests will bill through to extra usage or hard-stop at 429. Line 28 fetches /api/organizations/{org}/subscription_details for the plan tier that sets the denominator. All three are undocumented and authed with your existing claude.ai cookies. No API key, no login flow.

Partially. Anthropic's 'What's new in Claude 4.7' page acknowledges the new tokenizer and the 1.0x to 1.35x range. Their Claude Code best-practices page warns that adaptive thinking can generate substantial hidden output. What Anthropic does not publish is a specific multiplier on seven_day_opus, so the quota regression is a behavioral fact you have to measure on your own account. ClaudeMeter's client is MIT and under 900 lines; src/api.rs and src/models.rs together are the entire trust surface.

Install ClaudeMeter (brew install --cask m13v/tap/claude-meter) and load the extension into any Chromium browser. The extension polls every 60 seconds and posts the snapshot to the menu-bar app's localhost bridge. Open the popup and the '7d Opus' row shows the current utilization with its resets_at delta. For a scripted check, curl http://127.0.0.1:63762/snapshots and read .[0].usage.seven_day_opus.utilization directly.