The Claude rolling window cap is seven windows, not one
Every other guide on this topic writes about a single 5-hour rolling window plus a weekly budget. Anthropic's own endpoint returns seven separate utilization buckets. If you have ever been rate-limited while the headline bar sat at 30%, it is because one of the buckets nobody drew for you pinned at 100.
The setup: what the existing playbooks get right
Most articles about this explain two things correctly. First, the 5-hour window is rolling, not fixed, so it advances continuously from your earliest unexpired message. Second, weekly caps arrived on 2025-08-28 and apply to heavy Pro and Max users, shared across claude.ai chat and Claude Code. Those two facts are not wrong. They are just two out of seven.
The reason everyone stops at two is simple. The Help Center documents two. The Settings page draws two big bars. If you have never opened DevTools on claude.ai/settings/usage and read the JSON the page fetches, you would have no reason to think there are more.
The anchor fact: 0 utilization fields, one endpoint
Here is the exact response shape the endpoint returns. The field names are not invented. They come straight out of src/models.rs in the ClaudeMeter repo, which deserializes the live JSON Anthropic ships to its own Settings page:
Seven Window objects, plus an extra_usage object for metered billing on top. Every single one has its own utilization and its own resets_at. The rate limiter fires when any single one of them hits 100, not when the aggregate does.
The schema, verbatim
Here is the struct ClaudeMeter deserializes into. If a future Claude release adds an eighth bucket, this is where it would land:
What each bucket actually tracks
Eight entries (seven windows plus the extra-usage meter). Names preserved exactly as Anthropic returns them.
five_hour
The rolling 5-hour session. Starts counting from your first message in a window, resets continuously. This is the one every article writes about. It is also the least interesting because it rarely pins alone.
seven_day
The all-model weekly aggregate Anthropic introduced on 2025-08-28. This is the big bar on the Settings page. It tells you nothing about which model burned the budget.
seven_day_sonnet
Per-model weekly cap for Sonnet. Counts against the aggregate and has its own reset. If you only chat in Sonnet, this one pins before seven_day does.
seven_day_opus
Per-model weekly cap for Opus. Pins first for heavy Opus users because the per-model allowance is tighter than the aggregate.
seven_day_oauth_apps
Separate weekly bucket for traffic from apps you authorized over OAuth (Claude Code running against your plan, third-party tools). When this one pins, your browser chat keeps working but your tools get throttled.
seven_day_omelette
Internal Anthropic codename. Undocumented. Shows up in the schema alongside the others, with its own utilization and resets_at. Likely tied to Claude Code background work.
seven_day_cowork
Another internal codename. Likely the Projects / Artifacts collaboration bucket. Same shape as the others. The name hints at the intent; the docs stay silent.
extra_usage
Metered billing on top once the weekly buckets fill. Returns used_credits, monthly_limit, currency, and a utilization of its own. Reset is monthly, not weekly.
Why every bucket has its own reset clock
The 5-hour bucket rolls continuously, which is why its resets_at timestamp moves forward every time you send a message. The weekly buckets roll at a fixed wall-clock time per account, which is why they tend to share a resets_at with each other. But they do not have to. If Anthropic ever decouples them, the response format already supports it: every window carries its own reset field independently.
ClaudeMeter renders whatever the server returns, timestamp by timestamp, without interpretation. If you see a reset 18 hours from now on one bucket and 4 days on another, that is what the server said.
The 0-to-1 vs 0-to-100 gotcha
One trap if you want to hit this endpoint yourself: utilization is returned on either a 0-to-1 scale or a 0-to-100 scale, and which one depends on the bucket. We have seen the same account return 0.94 on five_hour and 94.0 on seven_day_opus in the same payload. ClaudeMeter normalizes with a single clamp:
If you roll your own tooling, you will want the same clamp. Otherwise a bucket at 0.94 renders as “less than 1%” and you get rate-limited seconds later.
Reproduce it yourself in one curl
You do not need ClaudeMeter to verify any of this. Open DevTools on claude.ai/settings/usage, copy your cookie header, and hit the endpoint directly:
How a request becomes a rate limit
Your message, versus the seven counters it increments
The whole path, end to end
Browser session identifies you
Your claude.ai cookies carry the org_uuid. The endpoint path is /api/organizations/{org_uuid}/usage. Without the session, the server refuses to return anything.
Server computes all seven buckets at once
Anthropic runs every one of your messages through multiple counters: the 5-hour window, the all-model weekly, the per-model weeklies, the OAuth-apps bucket, and the internal omelette/cowork buckets. They are accumulated independently.
Response carries utilization + resets_at per bucket
The JSON returns each Window as { utilization, resets_at }. Utilization may be 0-1 or 0-100. Reset timestamps are ISO 8601 UTC and are not identical across buckets.
Rate limiter fires on the first bucket to hit 100
Anthropic does not wait for the aggregate. Any single bucket reaching its ceiling is enough to throttle you. The 429 message itself does not name which bucket tripped.
Only the Settings page renders the numbers
The same JSON powers claude.ai/settings/usage, but that page visually surfaces only the headline bars. The tighter sub-windows are there in the payload, just not drawn on screen.
Why this matters if you are trying not to get cut off
What you miss by watching the wrong bar
- If you only watch the headline 5-hour bar, you will get surprise-429'd by a weekly sub-bucket nobody rendered for you.
- If you only watch the weekly aggregate, you will miss that seven_day_opus pinned at 96 while the aggregate sat at 41.
- If you only watch local token logs (ccusage, Claude-Code-Usage-Monitor), you see tokens you spent. You do not see the seven buckets Anthropic is counting against you.
- If an OAuth app you authorized burns your oauth_apps bucket, your browser chat keeps working while every tool you built looks broken.
- The only place all seven numbers exist is the JSON response from /api/organizations/{org}/usage. ClaudeMeter renders them continuously.
Local-log tools vs. server-truth
ccusage and Claude-Code-Usage-Monitor read local Claude Code logs. That is a different question from what the server is counting.
| Feature | Local-log tools | ClaudeMeter |
|---|---|---|
| Knows your rolling 5-hour utilization | No. Infers from local logs. | Yes. Direct from the server. |
| Knows your weekly aggregate | No. | Yes. |
| Knows per-model weekly (Sonnet / Opus) | No. | Yes. |
| Knows OAuth-apps weekly | No. | Yes. |
| Surfaces internal buckets (omelette, cowork) | No. | Yes. |
| Knows when Anthropic will cut you off | Best-effort estimate from tokens. | Reads the same JSON Anthropic's own Settings page reads. |
| Auth setup | None (local files only). | Browser extension forwards your existing session. No cookie paste. |
The honest caveat
The usage endpoint is internal. Anthropic has never documented the field names we listed. The two internal codenames (seven_day_omelette and seven_day_cowork) could be renamed, consolidated into the aggregate, or removed in any release. When that happens, ClaudeMeter breaks loudly (the Rust deserializer returns an error, and the menu bar shows a “schema mismatch” state) and we cut a patch. Until then, these are the buckets that are really out there.
See all seven buckets live
ClaudeMeter sits in your macOS menu bar and polls every 60 seconds. Free, MIT licensed, no cookie paste required.
Install ClaudeMeterFrequently asked questions
So is there one rolling window cap or seven?
Anthropic advertises two: a 5-hour rolling window and a weekly budget. The internal usage endpoint actually returns seven utilization fields per organization: five_hour, seven_day, seven_day_sonnet, seven_day_opus, seven_day_oauth_apps, seven_day_omelette, and seven_day_cowork. Hitting 100% on any one of them can rate-limit you even if the others look fine.
What are seven_day_omelette and seven_day_cowork?
They are internal Anthropic project names surfaced in the JSON schema. Our guess, based on naming and when they started appearing, is that omelette is the Claude Code background work bucket and cowork is the Projects/Artifacts collaboration bucket. Anthropic has never documented either publicly. ClaudeMeter reads them because they come down with every /usage response; we do not ping anything else.
Why do I hit a cap when Settings says I am at 30 percent?
The Settings page shows one or two headline bars. The server is tracking all seven buckets. You probably hit 100 percent on a narrower bucket (for example seven_day_opus) while the aggregate seven_day stayed low. That is not a bug on Settings, it is just that a top-line aggregate cannot surface a tighter per-model sub-window.
Is utilization returned as 0 to 1 or 0 to 100?
Both, inconsistently. ClaudeMeter normalizes with `u <= 1 ? u * 100 : u` because some responses come back as 0.94 and others as 94.0. If you call the endpoint yourself, do not assume a single scale.
Where does the resets_at timestamp come from?
Each window in the response carries its own ISO 8601 resets_at field. The 5-hour one moves forward continuously as you send messages, which is why it looks sticky near your active session. The weekly buckets roll at a fixed wall-clock time per account. ClaudeMeter renders whichever the server returns, verbatim.
Can I read these numbers without ClaudeMeter?
Yes. GET https://claude.ai/api/organizations/{org_uuid}/usage with your browser session cookies. You will get back the same JSON. ClaudeMeter exists so you do not have to paste a cookie into curl every hour.
Does hitting seven_day_oauth_apps affect my claude.ai chat?
Separately, in theory. The OAuth-apps bucket appears to track usage driven by apps you authorized to your account over OAuth (for example Claude Code running against your plan). If that bucket is pinned, requests from those apps get throttled without touching your browser chat budget. We have not seen Anthropic document this, but the schema has a distinct utilization and resets_at for it.
Why do ccusage and Claude-Code-Usage-Monitor disagree with the Settings page?
Because they read local JSONL files under ~/.claude/projects and estimate token spend. That tells you what Claude Code burned on your machine, not what Anthropic is counting toward any of these seven server buckets. The server truth lives only at /api/organizations/{org}/usage.
Does the endpoint ever hide buckets?
Yes. Fields are optional. If Anthropic has not enabled a specific bucket for your plan or org, that key comes back null or missing. ClaudeMeter skips missing ones in the menu bar and shows only the buckets your account actually has.
Is this likely to change?
Probably. The endpoint is internal and undocumented. New bucket names have been added over time. ClaudeMeter deserializes into an explicit struct so unknown fields do not crash, but if Anthropic renames or removes a bucket we patch the schema and ship a release.
Keep reading
How ClaudeMeter reads your plan usage
The precise dance between the browser extension, the localhost bridge at 127.0.0.1:63762, and the internal usage endpoint.
ClaudeMeter vs ccusage
They measure different things. ccusage reads local Claude Code JSONL files. ClaudeMeter reads the plan quota Anthropic enforces.
FAQ: safety, Safari, terms of service
Whether Anthropic allows it, what the extension can and cannot see, and what happens when the endpoint shape changes.
Got a weirder bucket name than these seven?
Send the payload. If your endpoint is returning something we have not seen, we want to map it.
Book a 15-minute call →