Claude Max rolling 5-hour weekly limit: the two limits are actually four.
Most write-ups frame the Claude Max plan as having two limits, a rolling 5-hour window and a weekly cap. The endpoint Anthropic enforces returns at least four Window objects for Max, each with its own utilization float and its own reset clock. Any one of them at 100% returns a 429. The May 6, 2026 doubling moved one of them. Here is the field list, the source, and the live read path.
Direct answer (verified 2026-05-13)
On Claude Max, the rolling 5-hour and the weekly limit are floats, not prompt counts. The server returns a utilization value between 0.0 and 1.0 on each of seven independent buckets at claude.ai/api/organizations/{org_uuid}/usage. Four are commonly hot on Max: five_hour, seven_day, seven_day_sonnet, seven_day_opus. Any one at 1.0 fires the next 429. The May 6, 2026 rate-limit doubling applied to five_hour only; the weekly caps were not doubled.
The JSON you would see right now
A Max 20x account, Wednesday afternoon, mid-refactor. The 5-hour bar on settings/usage says 21 percent and the weekly bar says 62 percent. The 429 will not come from either of those. Watch seven_day_opus.
The struct that names every field
The open-source claude-meter Rust app deserializes the same response. Seven Window fields on the struct: every bucket Anthropic enforces on your plan, named, in one place. Pro plans return three of these; Max plans return all seven (github.com/m13v/claude-meter, models.rs lines 18-28).
Rolling 5-hour vs weekly, on Max, in one table
The two limits sound parallel but behave differently. The May 6, 2026 rate-limit change is the cleanest illustration: same announcement, one bucket moved, the other did not.
| Feature | seven_day family (weekly) | five_hour (rolling 5-hour) |
|---|---|---|
| What it is | Rolling 5-hour window. Tracks every message you send across claude.ai chat, Claude Code, and any OAuth client on a 5-hour clock. | Weekly cap. Tracks the same message stream on a 168-hour clock, split into all-up, Sonnet-only, Opus-only, and OAuth-app-only buckets. |
| Field name on /usage | five_hour.utilization (float, 0.0 to 1.0) | seven_day.utilization plus seven_day_sonnet, seven_day_opus, seven_day_oauth_apps |
| When the clock starts | 5 hours after your first message of the rolling window. Each message ages off on its own clock; resets_at is the next age-off boundary. | 168 hours after the first message of the weekly cycle. Same rolling shape, longer clock. Independent per bucket. |
| May 6, 2026 change | Doubled. Max 5x roughly 50-200 prompts per window became roughly 100-450. Max 20x roughly 200-800 became roughly 400-1800. | Unchanged. Anthropic announced the doubling applied to the 5-hour limit only; weekly caps were not adjusted. |
| What the 429 looks like | 5-hour wall. Wait a few hours, the bucket drains as old messages age off. Continue when utilization drops below 1.0. | Weekly wall. Wait a few days, or drop to Sonnet if seven_day_opus is the hot bucket while seven_day_sonnet has headroom. |
| Where the Settings page shows it | Horizontal bar near the top of claude.ai/settings/usage. Visible percent on this one only. | Implicit. The same Settings page surfaces seven_day in prose ('your weekly usage resets at...'), but not seven_day_opus or seven_day_oauth_apps as their own bars. |
What the live menu bar shows
Same response, formatted as one row per bucket. This is what claude-meter status prints on the CLI, and what the macOS menu bar dropdown renders. Each row carries its own reset clock so you can see which one bites first.
How to read your own state in 60 seconds
You do not need claude-meter installed to check. The endpoint is public to your cookie, and the JSON is human-readable. Here is the shortest path.
Open the live JSON.
Visit claude.ai/settings/usage, open DevTools (F12 or Cmd+Option+I), switch to the Network tab, filter for /usage. The fetch on page load returns the seven Window fields. Click the Response tab; that is the entire enforcement state.
Read every utilization, not just the headline bar.
The percent on the page is seven_day. The other six fields live in the JSON. Whichever utilization is closest to 1.0 is the bucket that will 429 your next message. On Max with Opus-heavy workloads, seven_day_opus is usually the highest by Wednesday.
Note the resets_at for the hot bucket.
Each Window has its own resets_at. The 5-hour clock and the weekly clocks are independent. If seven_day_opus is the hot bucket, the 5-hour reset will not help; you wait until the listed seven_day_opus.resets_at or drop to Sonnet for the rest of the week.
Decide the right exit, not the reflex one.
five_hour at 1.0 wants a few-hour pause. seven_day at 1.0 wants days. seven_day_opus at 1.0 wants Sonnet for the rest of the cycle. seven_day_oauth_apps at 1.0 wants you off Claude Code and onto claude.ai web. Same 429, four different correct moves.
Or skip the manual polling.
claude-meter (MIT, github.com/m13v/claude-meter) pins each bucket to the menu bar and refreshes every 60 seconds. The browser extension hands the live claude.ai session to the macOS app, so there is no cookie paste, no expiring token. brew install --cask m13v/tap/claude-meter, install the extension, visit claude.ai once.
Frequently asked questions
What are Claude Max's rolling 5-hour and weekly limits?
They are floats, not prompt counts. Anthropic enforces utilization fractions between 0.0 and 1.0 on each of these buckets on Max: five_hour (rolling 5-hour window across all models), seven_day (overall weekly), seven_day_sonnet (weekly Sonnet-only), seven_day_opus (weekly Opus-only), seven_day_oauth_apps (weekly Claude Code + MCP traffic), seven_day_omelette, and seven_day_cowork. Any one bucket at 1.0 fires the next 429. The endpoint is GET claude.ai/api/organizations/{org_uuid}/usage. Anthropic does not publish prompt counts; independent estimates put Max 5x at roughly 50 to 200 prompts per 5-hour window and Max 20x at roughly 200 to 800, before the May 6, 2026 doubling.
Are the 5-hour and weekly limits two separate clocks?
Yes. The 5-hour clock rolls 5 hours after your first message of the rolling window. Each weekly clock rolls 168 hours after the first message of that weekly cycle, independently per bucket. A fresh 5-hour reset does not push the weekly clock, and a weekly reset does not unlock the 5-hour bucket. Both timestamps live on the same JSON response as resets_at. ClaudeMeter renders each as a relative duration ('in 4h 12m', 'in 4d 19h') so you can see which one bites first.
Did the May 6, 2026 rate-limit doubling apply to both?
No. Anthropic doubled the 5-hour rate limit on Pro, Max, Team, and seat-based Enterprise plans on May 6, 2026 (announcement: 'Increased rate limits on Claude Code for Pro, Max, Team and Enterprise users'). The weekly caps were not doubled. So a Max 20x user who used to get ~200 to 800 prompts per 5-hour window now gets roughly ~400 to 1800, but the weekly Opus bucket still saturates on the same workload. The most common Max surprise after May 6 is the 5-hour bar looking healthy while seven_day_opus quietly climbs past 90 percent.
I am on Max 20x. My 5-hour shows 21 percent. Why am I rate limited?
Because the 429 follows whichever bucket is highest, not the one labeled biggest on the Settings page. The most common pattern on Max 20x is seven_day_opus at 0.94 while five_hour sits at 0.21 mid-week. claude.ai/settings/usage shows a single horizontal bar that maps to seven_day (the overall weekly), not to seven_day_opus. So the page reads '62 percent' while the actual blocking bucket is at 94 percent. ClaudeMeter polls the raw JSON every 60 seconds and renders each bucket as its own labeled row, so the hot one is the one you stare at.
What does claude.ai actually return for these windows?
A small JSON object on GET /api/organizations/{org_uuid}/usage. Each field is a Window with two members: utilization (float, 0.0 to 1.0) and resets_at (ISO 8601 UTC timestamp). The exact Rust struct that deserializes this lives at models.rs lines 18 to 28 of the open-source claude-meter repo (github.com/m13v/claude-meter). Seven Window fields plus one ExtraUsage. Six of the seven are visible on Max. The Pro plan returns five_hour, seven_day, seven_day_opus; Max plans add seven_day_sonnet, seven_day_oauth_apps, seven_day_omelette, and seven_day_cowork.
What is seven_day_opus and why does it catch Max users specifically?
It is the weekly Opus-only bucket. Every Opus 4.5 and Opus 4.7 message you send through claude.ai chat, Claude Code, or any Anthropic OAuth client charges this bucket on a 168-hour rolling clock. Adaptive thinking is on by default for Opus 4.7, so thinking tokens count as real output tokens for the float. A Max 20x user doing heavy refactors with Opus eats seven_day_opus four times faster than they eat seven_day_sonnet. The Settings page does not name this bucket. ClaudeMeter prints it as a row called '7-day Opus'.
Can ccusage or Claude-Code-Usage-Monitor show these floats?
No. ccusage and Claude-Code-Usage-Monitor read ~/.claude/projects/<project>/<session>.jsonl on your disk and sum tokens against a model price card. That gives you accurate local token counts and dollar estimates. The Max plan utilization floats are server state: weighted by peak-hour multipliers, fold in browser chat traffic the JSONL never sees, and reflect overall plan-bucket pressure. The numbers are different by design. ClaudeMeter and ccusage are complementary tools, not replacements: one reads server quota, the other reads local Claude Code token spend.
How do I see the live state without installing anything?
Open claude.ai/settings/usage with DevTools open, Network tab filtered on /usage. Refresh the page. The response of /api/organizations/{org_uuid}/usage is the raw JSON with all seven Window fields. Look at every utilization, not just the headline bar. Whichever is closest to 1.0 is the wall you will hit next. Or run claude-meter status from the CLI if you have the open-source tool installed: it prints the same rows the menu bar app shows, one bucket per line.
If I turn on metered billing, do these limits stop applying?
No, they convert. Metered billing (extra usage / pay-as-you-go) lets the next prompt go through past plan caps at standard API prices, but only until you hit the monthly_credit_limit you set. When used_credits crosses that cap, the /overage_spend_limit endpoint returns out_of_credits: true and a disabled_until timestamp. So you go from being rate-limited by a plan bucket to being rate-limited by a dollar cap. Both are still 429s. ClaudeMeter shows the dollar cap as a separate 'Extra usage' row with the BLOCKED suffix when it fires.
What is the quickest install if I want to watch this live?
brew install --cask m13v/tap/claude-meter to install the macOS menu bar app, then install the browser extension from github.com/m13v/claude-meter/releases, then visit claude.ai once. The extension hands the live session to the menu bar app, no manual cookie paste. Numbers refresh every 60 seconds and match claude.ai/settings/usage exactly because the source is the same internal endpoint.
Stuck on the wrong bucket every week?
Book 15 minutes. Walk through your live JSON, find the bucket that is actually bottlenecking you, and pick a Sonnet/Opus split that holds for the week.
More on the rolling-window enforcement primitive.
Related guides
Claude Max plan still hitting limits? It is eight buckets, not one
Max raises the cap on each bucket but does not collapse them. Here is the triage that maps the 429 to the bucket and the fix.
Claude rolling 5-hour reset: each message ages off on its own clock
The 5-hour window does not reset to zero at one moment. Each message has its own 5-hour age-off clock. Why people show up at resets_at and find the bar still at 60 percent.
Claude Max weekly quota enforcement: three gates, two endpoints
The 5-hour, weekly, and metered-billing caps fire as three sequential gates. Two server endpoints, one BLOCKED string. The exact data path from server state to your menu bar.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.