Claude Code's Opus 4.7 limit lives in one server field called seven_day_opus

Partially. Every Claude Code request, regardless of model, counts against the shared five_hour bucket on /api/organizations/{org_uuid}/usage. Opus 4.7 requests also count against a separate seven_day_opus bucket that Sonnet requests do not touch. That second bucket is why you can have plenty of Sonnet headroom and still get rate-limited on Opus: the Opus-only float hit 1.0 while the shared float was nowhere near. It is declared in claude-meter/src/models.rs line 23 as pub seven_day_opus: Option<Window>.

Anthropic's what's-new doc for Opus 4.7 says the new tokenizer maps the same text to 1.0x to 1.35x as many tokens (up to ~35% more, varies by content). The tokenizer change does not add a new field to the usage payload. It makes seven_day_opus.utilization climb faster for the same prompt. If a coding session used 40% of your Opus weekly on 4.6, the same session can use 40% to 54% on 4.7. The server does not tell you which factor applied; only the aggregate utilization number moves.

Yes, and it is the bigger effect for most Claude Code users. Opus 4.7 uses adaptive thinking by default when the caller opts in, and burns more thinking tokens than 4.6 at the same effort level. Thinking tokens are real output tokens from the server's point of view and flow into the same seven_day_opus float. Anthropic announced they raised plan rate limits to offset this, but the weighting still lands on one opaque utilization number. You cannot back it out after the fact.

In the JSON at GET https://claude.ai/api/organizations/{your_org_uuid}/usage under the key seven_day_opus. The shape is { utilization: number, resets_at: ISO8601 } — same Window struct as five_hour and seven_day, defined at claude-meter/src/models.rs lines 3-7. The bar on claude.ai/settings/usage labeled 'Opus weekly usage' is drawn from this exact field.

No. Those tools read ~/.claude/projects/**/*.jsonl and sum local tokens. Local token counts miss three things the server applies before it writes to seven_day_opus: the 4.7 tokenizer's 1.0x to 1.35x expansion (counted server-side), thinking tokens (generated server-side and not always written to JSONL in full), and any peak-hour weighting Anthropic has layered on. The only number that matches what the Opus-rate-limiter checks is the one returned by /api/organizations/{org_uuid}/usage.

Because Claude Code running in a background agentic loop keeps sending requests while you are not in the chat. Opus 4.7 also tends to produce more regular progress updates and fewer subagents by default, which changes the shape of a session's token bill without changing anything you typed. ClaudeMeter polls the endpoint every 60 seconds so you see the float move while the session runs.

It frees up seven_day_opus, yes. It does not free up five_hour, because five_hour aggregates across models. So if a Sonnet-heavy day burns five_hour, you can be Opus-healthy and still locked out of Claude Code because the shared 5-hour float is pinned. Two floats, one AND gate. Both have to stay below 1.0.

Both, inconsistently, across buckets in the same payload. We have seen five_hour returned as 0.72 next to seven_day_opus returned as 94.0 in the same response. The extension normalizes with one clamp at popup.js:6-11: u <= 1 ? u * 100 : u. If you write your own client and skip that clamp, a bucket at 0.94 will render as 'less than 1 percent' and you will walk into a 429 on your next Opus 4.7 request.

Yes, but only indirectly. task_budget is an advisory token cap the model sees as a running countdown; effort=medium cuts adaptive-thinking spend. Both reduce the output tokens the model generates, so they reduce what the server writes to seven_day_opus. Neither tells you how much you saved. The honest way to measure savings is to compare seven_day_opus.utilization between two comparable sessions with and without the budget or with different effort levels.

Yes. There is a seven_day_sonnet field as well (Sonnet-only weekly) and a shared seven_day (all models combined), but no per-model 5-hour bucket and no per-version bucket for 4.7 vs 4.6. From the server's perspective, Opus 4.7 and Opus 4.6 both write to seven_day_opus. The only way to tell 4.7 apart is indirectly: your float rises faster than it did on 4.6 for the same workload.

The field names are the same. What changes is the denominator baked into utilization. Max 5x and Max 20x have higher ceilings, so the same absolute workload produces a lower fraction. ClaudeMeter reads the fraction verbatim, so the plan is implicit in the numbers you see. The rate limiter trips at utilization >= 1.0 regardless of plan.