The weekly cap stacked on the 5-hour window: two caps, one binary indicator

The bigger shift: a weekly cap on top of the rolling 5-hour window

For most of 2024 and early 2025, the only Pro cap that mattered in practice was the rolling 5-hour window. People built mental models around 45 messages every five hours, the number drifted around in Help Center copy, and the in-app indicator hinted at it. In late 2025 Anthropic introduced a server-side weekly cap on top of the existing 5-hour window and tightened enforcement progressively over the next few months. By early 2026 the weekly bucket was binding for many heavy Pro users on Opus.

The shift is subtle because the Settings page UI did not change to match. The 5-hour bar still draws the same shape, and the auxiliary label still flips between “usage is low” and a reset notice. But the underlying JSON has new keys, and the rate limiter compares against all of them.

The anchor fact: the JSON has all the percents

Hit GET /api/organizations/{org_uuid}/usage with your logged-in claude.ai cookies. This is the same endpoint the Settings page fetches to draw the bar. Verbatim shape:

Three weighted utilization fractions, each with their own ISO 8601 reset timestamp. The Settings page renders one of them as a bar (5-hour) and elides the other two behind a binary label. The rate limiter sees all of them.

One struct, every bucket

ClaudeMeter deserializes every bucket into the same struct. When Anthropic adds another cap (it has happened twice in the last six months), the type system catches it as a parse error rather than silently misrendering:

One Opus prompt, three buckets ticked

A single Opus completion increments the 5-hour bucket, the 7-day bucket, and the 7-day Opus bucket. The rate limiter trips on whichever of them hits 1.0 first.

Why the in-app indicator only flips between low and reset

The Settings page indicator is a category badge layered on top of a single bar. The bar is rendered from five_hour.utilization (a continuous fraction), but the badge text collapses every other bucket into one of two states: roughly “usage is low” or “usage will reset at X”. The continuous percents on seven_day and seven_day_opus do not get a bar of their own.

The result is a UI in which two genuinely different states (78 percent on weekly, 5 percent on weekly) look identical to the user. The first will 429 your next prompt, the second will not. The bar gives no signal because the bar is the 5-hour bucket and the 5-hour bucket might be empty either way.

What feeds each weekly bucket

Why pricing moved from tokens to quota

For a long time, Pro pricing copy was framed in tokens. You would see numbers like “roughly N million tokens per week”, and people would estimate from there. In late 2025 the wording moved to language about server-side utilization and rolling windows. That is not a marketing tweak. It reflects an actual change in how enforcement works. The cap is no longer a token estimate. It is a weighted utilization fraction with its own multipliers.

Two consequences. First, calculators that estimate “I have N tokens left” are now unreliable, because the server-side weighting (peak-hour multiplier, attachment cost, tool-call cost, model class) drifts the conversion ratio. Second, the only number that maps cleanly to a 429 is the utilization float in the JSON. There is no published formula and no token count to back-derive.

Reproduce it yourself in one curl

You do not need a tool to see the gap. Open DevTools on claude.ai/settings/usage, copy the cookie header from the Network panel, and call the endpoint:

The first time someone runs this and sees seven_day_opus at 0.91 while the bar on the Settings page sits at 0.42, the reaction is usually a flat “oh”.

The whole verification path, end to end

Why the binary indicator misses 78 percent

Real-time menu-bar tracker vs in-app indicator

Both read the same endpoint. They render different slices of the response.

Common myths to drop

What a real-time tracker actually shows

Where ClaudeMeter fits, and where it does not

ClaudeMeter is one option. It happens to be the one we maintain, so it is the one this site documents in detail. It is a small Rust menu-bar app with a browser extension that forwards your existing claude.ai session to a localhost bridge, polls the usage endpoint every 60 seconds, and renders every bucket. Free, MIT licensed, no cookie paste.

It is not the only option. ccusage, ccburn, Claude-Code-Usage-Monitor, and a handful of other open-source tools cover adjacent surfaces (local token attribution per project, JSONL parsing, cost forecasting). For weekly-cap visibility specifically, you want a tool that reads the server endpoint rather than your local logs. Anything that ships its own clamp on five_hour.utilization and persists snapshots for later analysis is a fine choice.

The honest caveat

The endpoint is internal and undocumented. The field names have been stable for many months but Anthropic could rename, add, or remove buckets in any release. ClaudeMeter deserializes the response into a strict Rust struct in src/models.rs, so when the shape changes the menu bar surfaces a parse error and a release ships the same day. Until then, this is where the weekly cap lives, and these are the numbers the rate limiter compares against.