The Claude rate limit dashboard for Pro and Max does not exist. Here is what a real one has to render.

No. The Claude Console analytics surface (activity, suggestion accept rate, lines-of-code accepted, spend) is documented as available to Team and Enterprise seats only. Individual Pro and Max subscribers see claude.ai/settings/usage, which renders four bars (5-hour, 7-day, 7-day Sonnet, 7-day Opus) but no analytics view, no per-prompt history, no projection. The endpoint that backs that page (GET /api/organizations/{org_uuid}/usage) returns eight utilization floats, so a third-party dashboard that re-renders the same payload locally has more to work with than the Settings page does.

Per account: the four utilization bars Anthropic also renders (5-hour, 7-day, 7-day Sonnet, 7-day Opus), each paired with its own resets_at countdown. Plus the extra_usage block (utilization, used credits in dollars, monthly limit if set, and a BLOCKED flag when out_of_credits is true). Plus the subscription block (status, next_charge_date, payment method last4 if you want to surface a billing-failure case). The dashboard then needs a top-line summary chip you can read at a glance from a menu bar or browser toolbar without expanding anything; that chip has to compress two numbers (5-hour percent, 7-day percent) into a six-character format and color-code them when they cross thresholds.

ClaudeMeter's bg_for() function at src/bin/menubar.rs lines 942-950 picks three states: utilization >= 100.0 paints RGB (215, 58, 73), a saturated red. Utilization >= 90.0 paints RGB (219, 118, 32), an orange. Below 90 paints no background (the chip stays plain text). The popup uses a related rule with a different threshold: extension/popup.css declares .bar.warn { background: #b26a00 } at >= 80 percent and .bar.hot { background: #b00020 } at >= 100 percent. The 80 percent threshold catches you a tier earlier on the bar view because the bar is a compositional unit, not a glance unit; the menu-bar chip waits until 90 because a chip in the corner of your screen flashing orange at 80 percent is noise.

Because the data lives in two places. The browser extension can call /api/organizations/{org_uuid}/usage with credentials: 'include' (the user's already-logged-in claude.ai cookies are attached automatically), but a native menu-bar app cannot. A native app sees the macOS keychain and the system network stack but has no way to ride the browser's session. ClaudeMeter solves that by running a tiny tiny_http server on 127.0.0.1:63762 (BRIDGE_PORT in src/bin/menubar.rs line 349) that accepts POST /snapshots from the extension. The extension polls the API, posts the parsed snapshot to the bridge, and the menu bar redraws. No cookie ever leaves your machine; the bridge only listens on the loopback interface.

Each snapshot keys on (browser, account email). The merge logic at src/bin/menubar.rs lines 840-895 walks each new snapshot, finds the matching persisted entry by that key, and prefers the fresher one (or the live one over a stale one). The menu bar then renders one Submenu per surviving snapshot, with the email or org_uuid as the submenu label. The top-line title chip switches format: a single-account user sees '5h 92% · 7d 45%', a multi-account user sees 'M: 5h 92% · 7d 45% P: 5h 30% · 7d 12%', where 'M' and 'P' are the first letter of each account email (account_tag at lines 952-958).

Three endpoints on claude.ai, fetched per account: GET /api/organizations/{org_uuid}/usage returns the eight utilization floats and their resets_at timestamps. GET /api/organizations/{org_uuid}/usage/overage returns the extra_usage block (out_of_credits, used_credits, monthly_credit_limit, disabled_until). GET /api/organizations/{org_uuid}/subscription returns subscription status and next charge date. ClaudeMeter parses the three responses into a single UsageSnapshot struct (src/models.rs lines 60-73) and the dashboard renders all three side by side. A 429 can fire because of any of the three: a saturated 5-hour float, a tripped weekly opus float, or extra_usage.utilization at 1.0 with overage enabled.

Because the Settings page is a plan-summary view, not a debugging view. It picks the four floats most users care about (five_hour, seven_day, seven_day_sonnet, seven_day_opus) and skips three weekly buckets that are rarely the gating limit (seven_day_oauth_apps, seven_day_omelette, seven_day_cowork) plus the extra_usage utilization float. The full eight-float payload is still in the response body if you open DevTools on that page; the page just does not render the back four. A self-hosted dashboard can render whatever subset its surface can hold.

Yes. /Applications/ClaudeMeter.app/Contents/MacOS/claude-meter --json prints the parsed UsageSnapshot to stdout in JSON. /Applications/ClaudeMeter.app/Contents/MacOS/claude-meter (no flag) prints a human-formatted block via the format_window() function at src/format.rs lines 75-98, which renders each window as 'X.X% used -> resets <local clock> (in Nh)'. The same data is reachable over the bridge: curl http://127.0.0.1:63762/snapshots returns the live snapshot the menu bar is currently drawing.

The browser extension's chrome.alarms tick is set to POLL_MINUTES = 1 (extension/background.js). One full poll per minute, every minute, while the browser is awake. The native menu bar refreshes whenever the bridge accepts a new snapshot, plus an internal poll loop at the same one-minute cadence as a fallback. There is no exponential backoff, no on-focus poll, no jitter; the cadence is fixed because the rolling window is a sliding boundary and you want the countdown to re-derive at a predictable interval.

It means out_of_credits in the OverageResponse came back true. ClaudeMeter renders that as the literal string ' BLOCKED' appended to the dollar line (src/format.rs lines 26 and 30, src/bin/menubar.rs line 710). It is the case where the user has enabled metered billing, has consumed the entire monthly_credit_limit, and Anthropic is now refusing overage-billed calls until disabled_until passes (or the user raises the limit). The 5-hour and 7-day bars can still look green in this state; the dashboard surfaces it specifically because a green bar plus a BLOCKED line is the harshest debugging case in the whole UI.