Claude Max plan bar vs extra usage: two parallel meters, not before and after

No. They live on two different endpoints and they spend different units. The plan bar reads /api/organizations/{org_uuid}/usage and renders a utilization float (0.0 to 1.0+, displayed as a 0 to 100 percent meter). The extra usage line reads /api/organizations/{org_uuid}/overage_spend_limit and renders a dollar amount in cents-divided-by-100 form. The bar keeps ticking after 100 percent (we have seen 1.04, 1.12 in the JSON) for cosmetic and historical reasons; the actual gate moves to a different field on a different endpoint. Two parallel systems, not two phases of one.

Because the underlying fields are different. format.rs line 112 prints '{:>5.1}% used' for any window where utilization is the meaningful number. format.rs line 31 prints '${:.2} / ${:.2} ({:.0}%)' for the overage line because used_credits and monthly_credit_limit ship as integer cents and the relevant question is dollars over the cap. The percent in parentheses on the extra usage row is a courtesy, not the primary number. Mixing them into a single percentage would hide the dollar amount you actually want at month end.

Yes, and it is the most common state on a Max account. If extra_usage.is_enabled is false on the usage endpoint, your prompts hard-429 the moment seven_day.utilization crosses 1.0; used_credits stays at 0 because no metered traffic ever runs. If is_enabled is true but you have not yet exhausted the rolling 5-hour or 7-day buckets, all your prompts bill against the plan and used_credits also stays at 0. The metered ledger only spends when the per-prompt rate decision says the plan window would have 429d.

Yes, and this is the surprising one. After the rolling 5-hour bucket pegs and metered overage takes over, the popup clamps the visible bar with Math.min(100, v) for cosmetic reasons (extension/popup.js line 37), so the bar reads 100 percent on the 5-hour but the seven_day bar can still look green if you are not heavy on the weekly budget yet. Meanwhile, every new prompt is incrementing used_credits by some integer cents on the next poll. The bar keeps you safe from the rolling 5-hour wall, the extra usage line keeps you safe from the surprise bill at month end. They guard different things.

No, they live on different clocks and that matters. The plan bar resets on rolling-window timestamps (resets_at on each Window struct in models.rs lines 3-7); the 5-hour resets_at slides every time an old prompt ages past the 5-hour mark, the 7-day slides similarly across a 7-day band. The extra usage clock is the monthly billing cycle: used_credits accumulates across the cycle and zeroes when Anthropic invoices, with disabled_until carrying any admin-imposed pause window. So even on a quiet Sunday, the 5-hour bar can fall while the extra usage stays exactly where it ended Friday.

BLOCKED appears on the extra usage row only, never on the plan bar rows. It is hardcoded as exactly ' BLOCKED' (two leading spaces, all caps) in format.rs line 26 and menubar.rs line 960. It prints when out_of_credits comes back true on the overage_spend_limit endpoint, which means metered billing is on, you have spent the whole monthly_credit_limit, and Anthropic is now refusing further overage-billed calls until disabled_until passes. The 5-hour and 7-day bars can still look green when this happens, which makes BLOCKED the diagnostic for one specific 'green windows but my prompt 429d' state.

Because the page splits the two surfaces vertically. You see the rolling and weekly bars in a top section, and the extra usage block lives below as a separate card with its own Enable toggle and balance meter. On a phone or short laptop screen the extra usage block is below the fold, and you can read the page top to bottom believing the bar is the whole story. ClaudeMeter sits at the menu bar level: the 5-hour, 7-day, 7-day Sonnet, 7-day Opus, and Extra rows are all peers in the same dropdown, so the dollar string sits two lines below the percent string. You cannot read one without seeing the other.

Correct. With extra_usage.is_enabled = false, the overage_spend_limit endpoint returns 404 for most orgs (free workspace orgs, team orgs without metered billing, fresh paid accounts that never opted in). ClaudeMeter wraps the call in a try/catch (extension/background.js line 26-27, src/api.rs lines 31-45) and just omits the Extra row entirely. So if you do not see an Extra row in the menu bar, your org has not opted in to metered. The bar is your only meter; once seven_day.utilization hits 1.0 you hard-429 until reset.

Yes, and this is the field that surprises people. seven_day.utilization keeps climbing past 1.0 after metered traffic kicks in (we have observed 1.04 and 1.12 in real JSON). The plan bar is, in a sense, just a counter once you cross 100 percent; the gate moved elsewhere. ClaudeMeter still renders it because the trajectory tells you whether the next billing cycle is shaping up to be heavier than this one, even though the first 100 percent is now meaningless from a 429 perspective.

Yes, with two curls. Open DevTools on claude.ai/settings/usage, copy the Cookie header, then run curl with -H 'Cookie: $YOUR_COOKIE' -H 'Referer: https://claude.ai/settings/usage' against https://claude.ai/api/organizations/$ORG_UUID/usage for the bar JSON, and the same against /overage_spend_limit for the dollar JSON. Pipe both through jq. ClaudeMeter just automates the cookie wrangling, the org enumeration, and the 60-second poll cadence so you do not retype the curl every minute.