Your Claude weekly limit and extra usage are linked by one boolean

Only if you opted in. The /api/organizations/{org}/usage response carries an extra_usage block with an is_enabled boolean. If is_enabled is false (the default for fresh accounts) the weekly cap is a hard stop and you wait for the resets_at timestamp. If is_enabled is true, your next prompt is billed against your metered cap at standard API rates and the dollar figure on /settings/usage starts ticking. There is no automatic fall-through; you have to flip the toggle on Settings > Usage > Extra usage > Enable first.

Two places. The first is the extra_usage.is_enabled flag on /api/organizations/{org}/usage (typed as ExtraUsage in src/models.rs lines 9 to 16 of the open-source ClaudeMeter source). The second is the is_enabled flag on the dedicated /api/organizations/{org}/overage_spend_limit endpoint (typed as OverageResponse in src/models.rs lines 30 to 40). Both should agree; if they disagree, the overage endpoint is authoritative because that is what the Settings page reads when it draws the BLOCKED banner.

Three possibilities. First, your monthly credit limit is set to zero or near zero, so any spend trips it instantly. Read monthly_credit_limit on /overage_spend_limit (it ships in cents, divide by 100 for dollars). Second, used_credits already equals monthly_credit_limit because earlier sessions in this billing cycle ate the cap. Third, out_of_credits is true and disabled_until is in the future because Anthropic itself paused metered billing for your org (rare, but possible during incident windows). The literal BLOCKED string in the menu bar surfaces case three; cases one and two show as 100 percent on the dollar line without a BLOCKED suffix.

Not on its own. A card on file enables the metered billing capability; you still have to flip the Extra usage toggle. Once flipped, your card on file is what the cap is billed against at the end of the cycle. There is no usage gate for credits you have not pre-authorized: Anthropic does not charge per-prompt at the moment of overage, it accumulates the dollar count against monthly_credit_limit and bills the card on the next billing cycle (the next_charge_date field on /api/organizations/{org}/subscription_details).

Read three fields in this order. First, the worst utilization across five_hour and seven_day on /usage; if either is at or near 100 you are about to fall through. Second, extra_usage.is_enabled on /usage; if false, you will be blocked at the wall. Third, out_of_credits on /overage_spend_limit; if true, you are blocked even with extra usage enabled because the metered cap is hit. ClaudeMeter prints all three on consecutive rows so you read them top to bottom: 5-hour percent, 7-day percent, Extra usage dollars with the optional BLOCKED suffix.

Different fields, different states, different remedies. A 100 percent weekly bar means seven_day.utilization >= 1.0 on /usage, and the only remedy is waiting for seven_day.resets_at to pass. A BLOCKED extra usage line means out_of_credits = true on /overage_spend_limit, and the remedy is either raising monthly_credit_limit on Settings > Usage > Adjust limit, or waiting for the billing cycle to roll on next_charge_date. They can both be lit at the same time: weekly bar pegged, extra usage disabled or capped, you wait for whichever resets first.

Yes, in our reading. seven_day.utilization keeps climbing past 1.0 (so you can see 1.04 or 1.12 in the JSON when you have spilled into metered) but the included usage is already exhausted. The bar in the popup clamps to 100 visually because the width style uses Math.min(100, v ?? 0) on extension/popup.js line 37; the underlying float is uncapped. The dollar figure on overage_spend_limit is the more useful number once you are in fall-through.

Depends on your cycle. Anthropic bills extra usage at standard API rates (no plan discount), so a heavy week of metered spend can match or exceed the price gap between Pro and Max 5x. The honest comparison is: read used_credits at the end of a typical cycle and compare to (Max plan price - Pro plan price). If the dollar count is consistently higher than the price differential, the upgrade pays back. ClaudeMeter shows the running used_credits live so you can build that comparison from your own real numbers, not Anthropic's example invoices.

ccusage reads ~/.claude/projects/<project>/<session>.jsonl and sums input plus output tokens per turn, then multiplies by the public model price card. That is a faithful local-token estimate for Claude Code traffic only, and it cannot see either of the endpoints this page is about. ccusage at $4 of estimated spend next to ClaudeMeter at $17 of metered used_credits is normal: ccusage measures local token cost, the server measures actual billing with peak-hour multipliers and per-model weights folded in. Run both for the full picture.

Yes, if extra usage is enabled. The fall-through is keyed on the per-prompt rate-limit decision, not on which window tripped, so a 5-hour overrun and a 7-day overrun both spill dollars into used_credits when is_enabled is true. The 5-hour case is much shorter-lived (the window resets in minutes to a few hours) so most users feel the dollar tick on the 7-day overrun. Practically: a 5-hour overrun on metered billing is rare unless you are in a runaway agentic loop; a 7-day overrun on metered billing is the common case Anthropic introduced extra usage to handle.

On a personal Pro or Max account you control your own toggle. On a Team or Enterprise org, the admin owns the org-level extra usage cap and can disable it for the seat, in which case is_enabled returns false on /overage_spend_limit no matter what your personal preference is. The disabled_reason field on /overage_spend_limit names the cause when this happens (admin_disabled is the typical string). ClaudeMeter does not separately distinguish personal vs admin disablement; it surfaces the field as-is.