Claude Code rolling 5-hour vs weekly quota: what they actually are, and which one 429s you

It is a sliding 5-hour budget that fills as you prompt and drains as your oldest prompts age past the 5-hour mark. The clock starts on your first prompt of a session, and at any moment the bucket measures the cost of all activity in the last 5 hours, weighted by model class, attachments, tool calls, and a peak-hour multiplier Anthropic announced in late 2025. On the server it is the float in the five_hour.utilization field of /api/organizations/{org_uuid}/usage. When that float crosses 1.0 every further request from your org returns 429 until the earliest unexpired prompt ages out.

It is a 7-day rolling ceiling on total compute hours across your account. Anthropic introduced the weekly cap on August 28, 2025 and tightened enforcement through early 2026. Pro is roughly 40 to 80 hours per week, Max 5x is 140 to 280, Max 20x is 240 to 480. On the server it is the seven_day field in the same JSON; on Max plans you also get seven_day_sonnet and seven_day_opus as sub-buckets. The weekly quota is shared: claude.ai chat, the IDE extension, and Claude Code all draw from it.

Window length and what they cap. The 5-hour window caps burst usage in a sliding 5-hour band; it is meant to keep one user from saturating the cluster in a sprint. The weekly quota caps total compute hours over a sliding 7-day band; it is meant to keep heavy users from saturating the cluster across an entire workweek. Practically, the 5-hour window resets visibly throughout the day (you watch its resets_at slide forward in real time), while the weekly bucket basically never falls because seven days is long enough that even an idle weekend barely moves the boundary. Either one can independently 429 you, even if the other is at zero.

On Pro, it is overwhelmingly the rolling 5-hour. Pro lets through enough weekly hours that most people only run out of them on extreme weeks. On Max with Claude Code agentic loops, both happen, often in the same session. People hit the 5-hour wall during a long refactor at hour three, then come back the next day and hit the weekly cap by Tuesday afternoon because the agentic loops chew through compute hours faster than any chat workflow does. The seven_day_opus sub-bucket is the most common Max-plan failure: Opus is heavier per byte, so an Opus-heavy week pegs that one even when seven_day overall is fine.

No, not directly. ccusage walks ~/.claude/projects/*.jsonl on disk and totals input_tokens + output_tokens for sessions on this machine. That is a reasonable proxy for raw token spend on Claude Code only, but the 5-hour and 7-day floats are server-side, weighted, and include browser-chat usage that is not on disk anywhere. ccusage at 5% of estimated spend while the 5-hour bar is at 100% used is a real, frequent state. ccusage is excellent for cost attribution; it is not a faithful proxy for the limits the server actually enforces.

claude.ai/settings/usage in a browser tab is the official surface; both rows render there. /usage inside Claude Code is a one-shot dump that scrolls off as soon as you keep prompting. For an always-visible readout, ClaudeMeter polls /api/organizations/{org_uuid}/usage every 60 seconds (POLL_INTERVAL at src/bin/menubar.rs:18, POLL_MINUTES at extension/background.js:3) and pins both rows plus the Opus and Sonnet sub-buckets to the macOS menu bar. Same endpoint, same numbers, different surface.

No. They each carry their own resets_at field in the JSON. The 5-hour resets_at slides every time you stop prompting and an old message ages out; in a quiet hour you can watch it tick down. The 7-day resets_at also slides, but in 7-day chunks of activity, so it usually looks more like a hard wall than a sliding window. ClaudeMeter prints both timestamps in the dropdown (-> resets Tue May 5 18:00 (in 2h)) and you trust those, not your wall clock.

Per Anthropic's March 2026 statement, the company has been adjusting the 5-hour window during peak hours of 5 to 11 a.m. Pacific on weekdays, while leaving overall weekly limits unchanged. So during peak hours the 5-hour bucket fills faster than the same prompts would fill it at midnight, but the seven_day bucket does not get the same multiplier. If you keep getting 5-hour walls before noon Pacific and they go away at night, that is the peak-hour multiplier, not your prompts changing.

Per-account, more precisely per-organization. The five_hour bucket is computed on the server and keyed off your org_uuid. If you run Claude Code on a laptop and a desktop logged into the same Anthropic account, both deplete the same bucket. If you also chat in a browser, that adds to the same bucket. Same applies to the seven_day bucket. ccusage on one machine cannot see the other machines or the browser, which is one reason its number drifts from the server number on multi-machine days.

Once you opt in to metered overage on Max, you keep getting prompts after the 5-hour bucket pegs at 100%, but the requests draw from your extra_usage credit balance instead. The seven_day bucket still applies. ClaudeMeter has a separate Extra usage row in the menu bar dropdown, so you can tell rolling-window-pegged-but-spending-dollars-fine apart from rolling-window-pegged-and-fully-blocked. Without that distinction the surprise is figuring out at month end that you spent 200 dollars on overage you did not realize you were on.