Claude Max plan still hitting limits? It is eight buckets, not one.

Because Max is a higher cap, not no cap. Anthropic enforces eight independent server-side limit buckets. Seven live on /api/organizations/{org_uuid}/usage (five_hour, seven_day, seven_day_sonnet, seven_day_opus, seven_day_oauth_apps, seven_day_omelette, seven_day_cowork) and the eighth lives on /api/organizations/{org_uuid}/overage_spend_limit (out_of_credits when you have metered billing on). Any one of them at 100 percent will 429 your next prompt. Max raises the caps; it does not collapse the gates into one bucket.

The big bar on claude.ai/settings/usage is the seven_day aggregate. It does not show seven_day_opus, seven_day_sonnet, or seven_day_oauth_apps as their own rows in prose. A Max user running Claude Code can be at 30 percent on seven_day and 100 percent on seven_day_oauth_apps and the Settings page will not mention the second number. The 429 fires anyway. ClaudeMeter polls the raw JSON every 60 seconds and renders each bucket as its own row, so you can see which one is hot.

It is a separate weekly bucket that only counts traffic from OAuth-authenticated clients (Claude Code, MCP host loops, agentic CLIs that signed in through the OAuth flow). Max sells itself on agentic Claude Code workloads, so most Max subscribers are pushing traffic into this bucket all week. seven_day_oauth_apps can be at 91 percent while five_hour is at 12 percent and seven_day is at 30 percent. The 429 fires against whichever window crosses 100 first. The field name is in models.rs lines 18 to 28 of the open-source repo.

Yes. The endpoint returns seven_day_opus and seven_day_sonnet as their own utilization fractions with their own resets_at. A Max session that mostly drives Opus on hard tasks will saturate seven_day_opus before seven_day_sonnet, and the 429 message names the model bucket that fired. Anthropic's November 2025 announcement about Opus 4.5 confirmed Sonnet now carries its own bucket separate from the all-up weekly. The endpoint has actually returned both fields independently for longer than that.

Open claude.ai/settings/usage, hit DevTools, watch the network tab refresh. The response of /api/organizations/{org_uuid}/usage is the raw JSON. Look for whichever utilization is at or above 1.0 (some responses ship 0 to 1, some ship 0 to 100; the numbers are the same scale internally). If every bucket on /usage looks fine, fetch /api/organizations/{org_uuid}/overage_spend_limit and check out_of_credits. That is the eighth gate. Or skip the manual loop and install ClaudeMeter; the menu bar shows the active gate continuously without DevTools.

No. Each clock is independent. five_hour.resets_at rolls 5 hours after your first message of the rolling window. seven_day.resets_at rolls 168 hours after your first message of the cycle. seven_day_oauth_apps has its own resets_at. The metered-billing cap on /overage_spend_limit resets on your billing cycle boundary as disabled_until. Riding out a 5-hour reset does not push the weekly clock and does not unlock the OAuth bucket. ClaudeMeter shows each reset time as a relative duration ('in 4h', 'in 3d 15h') next to the percent bar.

It can. Enabling extra usage on Max lets the next prompt proceed past plan caps at standard API prices, but only until you hit the monthly_credit_limit you set. Once used_credits crosses that cap, out_of_credits flips true on /overage_spend_limit and a disabled_until timestamp appears. So metered billing converts a 429 from the rolling-window gate into a 429 from the dollar gate. ClaudeMeter shows both. The terminal version prints '$200.00 / $200.00 (100%) BLOCKED until Sun May 14' on the Extra usage row when the dollar cap fires.

ccusage reads ~/.claude/projects/<project>/<session>.jsonl on disk and sums input and output tokens against a model price card. That is local truth: tokens that left your machine. Plan limits live on Anthropic's servers as utilization fractions on the buckets above. The two are not the same number and were never supposed to be. ccusage is a great cost calculator. It is not a plan-quota reader, because the plan quota is not in the local logs. ClaudeMeter and ccusage are complementary: one reads server quota, the other reads local token spend.

Yes, the caps are higher, but they are not absent. Heavy daily Claude Code users on Max 20x still report hitting the weekly Opus limit by Thursday or Friday. The five_hour window also fires for Max 20x users running back-to-back agentic loops. The bucket schema is identical across Max 5x, Max 20x, and Pro: same field names, different cap values. ClaudeMeter renders the percent against whatever your plan's cap actually is, because it reads the server's already-computed utilization fraction.

The browser extension piece in extension/background.js calls fetch('/api/organizations/' + org + '/usage', { credentials: 'include' }). Manifest V3 lets the extension run with the live claude.ai cookies the browser already holds, so no copy-paste, no keychain prompt, no expiring token. The Rust core in src/api.rs does the same call with a cookie header it pulls from the system store on macOS. Either path is read-only. There is no chat traffic, no prompts sent, just two GETs per minute against endpoints the Settings page already calls.