Your senior reviewer workflow is rationed by one float nobody writes about

A two-agent pattern. One agent, usually Sonnet, writes or refactors code. A second agent, usually Opus, reads the diff and returns a structured review before anything lands on main. In Claude Code this is most often wired through /agents with a senior-reviewer role, a slash command like /review, or a CI step that shells claude with a review system prompt. The division of labour is what people write about. The thing nobody writes about is that the reviewer pass is Opus-rationed on a weekly budget, and that budget is a single float on the usage endpoint.

Because every review is a full re-read of the diff plus the review system prompt plus any project context the reviewer agent pulls in. A Sonnet-only coding session can skate through five hours without touching Opus at all. A two-agent workflow touches Opus on every PR even when the code itself was Sonnet-written. If your team does 6 PRs a day, that is 6 Opus invocations a day that would not exist without the reviewer pass, and each one is larger than a typical chat turn because the entire diff is in the prompt.

seven_day_opus is a weekly utilization float scoped to Opus requests on your subscription. ClaudeMeter declares it as pub seven_day_opus: Option<Window> on src/models.rs line 23. The menu-bar formatter prints it as '7-day Opus' on src/format.rs line 19. It is populated verbatim from the /api/organizations/{org}/usage response that claude.ai/settings/usage also consumes, so the number you read from ClaudeMeter is the same number the rate limiter checks on your next Opus request.

Two ways. The CLI: /Applications/ClaudeMeter.app/Contents/MacOS/claude-meter --json | jq '.usage.seven_day_opus.utilization'. The persisted snapshot file: jq '.[0].usage.seven_day_opus.utilization' ~/Library/Application\ Support/ClaudeMeter/snapshots.json. Both return a single float. Either one is one line in a pre-commit hook, a GitHub Action, or a wrapper script that calls claude review. Local-log tools like ccusage have nothing to read here because the float is server-side.

Not for this. Both tools parse ~/.claude/projects/**/*.jsonl and count tokens client-side. Token counts are a cost signal, not a quota signal. The rate limiter does not read your JSONL; it reads its own server-side weekly float. You can spend a lot of tokens and still have headroom, or spend few tokens and still hit the gate. The only way to budget a reviewer workflow on server truth is to read the live seven_day_opus float, which ClaudeMeter surfaces and the local-log tools do not.

Yes, on bursty days. five_hour is shared across every model and every request, so a morning of heavy Sonnet coding followed by an afternoon of reviews can pin it before seven_day_opus does. In practice the five-hour gate is the one that stops a single marathon session; the seven_day_opus gate is the one that kills the workflow mid-week. A well-designed reviewer wrapper checks both before every invocation.

The next Opus request returns 429 with a resets_at timestamp that matches the Window struct at src/models.rs lines 3 to 7. Claude Code then surfaces the failure to whatever invoked it. In a /review slash command you will see the error inline. In a CI step shelling to claude it will exit nonzero. The review itself does not partially complete; the server rejects the request before the model sees the prompt.

Run the reviewer prompt on Sonnet 4.7 and explicitly note in the review output that it is a Sonnet pass, not an Opus pass. Humans reading the review can calibrate accordingly. Sonnet still catches the structural and correctness issues; the classes of feedback it misses are architectural comparisons that benefit from Opus's longer effective context reasoning. A shell wrapper that reads seven_day_opus and picks the model is the cleanest implementation.

Partly. If your account has overage billing enabled, Opus requests can continue past seven_day_opus by consuming extra_usage credits. Those have their own utilization float, extra_usage.utilization on the ExtraUsage struct at src/models.rs lines 10 to 16, and when that reaches 1.0 new requests stop even with the weekly float green. ClaudeMeter prints the extra-usage state next to the windows so you can see both limits at once.

Because the question is invisible to anyone who is not reading the /usage response directly. Settings renders a single 'weekly Opus' bar with no arithmetic for 'how many more reviews do I get this week.' And because token-based tools do not see the weekly Opus float at all, the writers using those tools do not know the float exists. The result is a genre of write-ups that describe the prompt pattern carefully and never mention that the pattern has a sustainability cliff.

Yes. Max 20x has a roughly twentyfold larger seven_day_opus denominator than Pro, which is the difference between running a reviewer pattern sustainably on a small team and running it for two days a week on a solo plan. Neither denominator is printed in the Settings page; both are read from the /usage response on every tick. ClaudeMeter does not care which plan you have; it reads the float and renders it at whatever scale the server returned.

If all three authenticate with your claude.ai cookies, yes. They share seven_day_opus and the rest of the weekly floats. If one of them authenticates via an OAuth app, its traffic lands in seven_day_oauth_apps instead, which is a separate hidden float declared at src/models.rs line 24. A reviewer workflow that runs through an OAuth-authorized IDE extension can trip a float the Settings UI does not draw at all.