The Claude usage limit message is five messages wearing the same name.

It means the rate limiter on claude.ai returned a 429 against your org and the client substituted a friendlier banner. The banner you see comes from one of at least five distinct templates documented in Anthropic's troubleshooting article, plus the Claude Code CLI variant. Each template reads a different field. 'Approaching 5-hour limit.' reads five_hour.utilization above the warning threshold. '5-hour limit reached - resets [time].' reads five_hour.utilization >= 1.0 with overage either off or already exhausted. '5-hour limit resets [time] - continuing with extra usage.' reads the same float at 1.0 but with extra_usage.is_enabled true and out_of_credits false. 'Opus weekly limit reached' reads seven_day_opus.utilization >= 1.0. The CLI banner 'Claude usage limit reached. Your limit will reset at 3pm (America/Santiago).' is the Claude Code CLI's collapsed version that does not name which window tripped at all. The wording does not tell you which field fired. ClaudeMeter polls the underlying endpoint every 60 seconds so you can read the field directly.

It is accurate for the window the message names, not necessarily for the wall you actually hit. GitHub issue anthropics/claude-code#9236 documents a user who saw 'Your limit will reset at 3pm (America/Santiago)' and was still locked out 23 hours later. The 5-hour window did reset on schedule; the wall in front of them was a different field on a different endpoint (overage_spend_limit.disabled_until) that the CLI banner never references. The /api/organizations/{org_uuid}/usage payload returns its own resets_at per window, and /api/organizations/{org_uuid}/overage_spend_limit returns its own disabled_until. ClaudeMeter prints both clocks in the CLI output (src/format.rs lines 75 to 98) so the disagreement is visible.

Both messages fire when five_hour.utilization >= 1.0. The branch is on the overage_spend_limit endpoint. When is_enabled is true, out_of_credits is false, and disabled_until is null or already past, Anthropic switches the banner to '5-hour limit resets [time] - continuing with extra usage.' and meters subsequent prompts against your monthly extra usage cap. When any one of those three blocks, the banner stays at the harder '5-hour limit reached - resets [time].' wording and your prompts 429 outright. ClaudeMeter parses all three fields into the OverageResponse struct in src/models.rs lines 30 to 40 and renders the BLOCKED state inline so you see the branch, not just the banner.

The web banners (Approaching 5-hour limit, 5-hour limit reached, Opus weekly limit reached) name the specific window. The Claude Code CLI prints a collapsed banner: 'Claude usage limit reached. Your limit will reset at 3pm (America/Santiago).' That string does not say five-hour, weekly, Opus, or extra usage. It is a single template the CLI reuses across every 429 family. The reset time is whichever resets_at field the gateway returned, formatted in the local IANA zone of the user's machine. If the wall is overage-driven, the CLI still prints a five-hour-shaped reset because the response shape it parses does not include disabled_until. This is why the Claude Code CLI banner is the most ambiguous of the five and why a usage tracker that reads the underlying fields is more useful than the banner itself.

The popup uses an earlier threshold than Anthropic does. extension/popup.js line 31 picks the bar class as v >= 100 ? 'hot' : v >= 80 ? 'warn' : '' so the bar paints orange at 80 percent utilization, while the troubleshoot article confirms Anthropic only renders 'Approaching 5-hour limit.' once the gateway has decided to surface the warning. The 80 percent threshold catches you a tier earlier on the bar view because the bar is a compositional unit (it shares the popup with other rows and benefits from a stronger color step) while the menu-bar chip waits until 90 percent (src/bin/menubar.rs bg_for thresholds) because a chip flashing orange at 80 percent is noise.

It does not lie, but it reports only the named window. If five_hour.utilization is at 1.0 and seven_day_opus.utilization is also at 1.0, you will see one banner: usually whichever the gateway picked for that specific request. Switching to Sonnet may unblock you (because seven_day_sonnet is its own float) even though the Opus banner suggested every model was capped. The /api/organizations/{org_uuid}/usage payload returns eight separate utilization floats (UsageResponse in src/models.rs lines 19 to 28); the banner only references one. A tracker that renders all eight tells you which models still have room.

Yes. Open DevTools on claude.ai/settings/usage, refresh, and look for the XHR to /api/organizations/{org_uuid}/usage. The response body has utilization floats per window. Or run /Applications/ClaudeMeter.app/Contents/MacOS/claude-meter --json to get the same payload pretty-printed in your terminal. The CLI prints the per-window resets_at in your local timezone next to each percent so you can compare what the banner said with what the field actually says. ClaudeMeter never reads, parses, or sees the banner text itself; it only reads the JSON.

No. The API surface returns 429 with structured headers (anthropic-ratelimit-requests-remaining, anthropic-ratelimit-tokens-remaining, retry-after) documented at platform.claude.com/docs/en/api/rate-limits. The claude.ai web banner and the Claude Code CLI banner are user-facing translations of a 429 from the per-org rate limiter on the web stack. They share the underlying mechanism (you have hit a quota) but the surfaces are different: API consumers parse the headers themselves, web and CLI users see the banner. The /api/organizations/{org_uuid}/usage endpoint is the closest a web user gets to a structured view, and it is the one ClaudeMeter calls.