Mid-refactor, 100% weekly: the 90-second recovery playbook

Because the weekly bucket Claude Code charges against is not the same bucket your web chat charges against. Anthropic returns multiple weekly buckets on /api/organizations/{org_uuid}/usage: seven_day is the all-up roof, seven_day_oauth_apps is the OAuth-app subset (where Claude Code lives), and seven_day_sonnet and seven_day_opus track per-model. Hit the seven_day_oauth_apps ceiling and your terminal stops while web chat keeps going on the same plan. ClaudeMeter shows all of them in one popup so the next prompt does not surprise you.

Two rows of interest. The first is '7-day · Xd' where the percent comes from seven_day.utilization (multiplied by 100 if it is a 0 to 1 fraction in the JSON) and the countdown comes from seven_day.resets_at, formatted by fmtResets() in extension/popup.js. Under one hour shows minutes. Under 48 hours shows hours. Otherwise days. The second is '7d Opus' or '7d Sonnet' when Anthropic returns those fields. The toolbar badge keeps showing the 5-hour percent because the badge has room for one number and the 5-hour bucket usually fires first; the weekly number is in the icon tooltip and the popup body.

Sometimes. Claude Max raises the weekly cap (per Anthropic's July 2025 hours framing, Pro is roughly 40 to 80 Sonnet hours per week, Max 5x is roughly 140 to 280, Max 20x is 240 to 480). If you keep landing at 100% on a Wednesday, the bucket size is the bottleneck and Max is the answer. If you land at 100% because one runaway agentic loop spent the whole week's quota in a four-hour stretch, a bigger bucket will only make the next runaway loop more expensive. Read the rolling rate (percent moved per hour while the loop ran) on the popup before paying for more bucket.

No, and this is the trap that catches every team that tries. Local-log tools like ccusage and Claude-Code-Usage-Monitor walk ~/.claude/projects/*.jsonl and sum inputTokens and outputTokens per session. The numerator is real. The denominator (Anthropic's plan ceiling) is not on disk. The same prompt run at 11 PM Pacific and at 11 AM Pacific moves the local token total identically but moves the server fraction by different amounts because there are peak-hour multipliers and per-model weights on Anthropic's side. ccusage at 5% with claude.ai at 91% is the predictable mismatch when this happens. ClaudeMeter reads the server-truth fraction the settings page reads.

seven_day.resets_at on the same Window struct that returned the utilization. It is an absolute UTC ISO timestamp, not a rolling clock-time interval, so two parallel agents read by two different shells converge on the same wake-up moment. Sleep until that timestamp, add a 30-second grace period, then resume. claude-meter --json prints it directly; src/models.rs declares it as Option<chrono::DateTime<chrono::Utc>>. Setting an arbitrary 'wake up in 4 hours' instead is wrong for two reasons: (a) the rolling window does not refill on the hour; it refills the moment the oldest charge inside the trailing 168-hour window ages out, and (b) you waste minutes you could have been refactoring through.

No. The seven_day_oauth_apps bucket is per-account, not per-process. Five agents in five panes all stack into the same fraction. ClaudeMeter's dedupe_by_account in src/lib.rs collapses snapshots that share account_email or org_uuid into one row, so the popup shows the one shared percent every parallel agent on that account is racing to fill. Local-log trackers read ~/.claude/projects/*.jsonl per process and report N separate per-session totals that do not sum to the server number.

Two things. First, commit any half-done work locally before the wall (a git commit -am 'WIP: refactor checkpoint' so Claude Code's next session can read the intermediate state out of git diff). Second, store the conversation thread URL or a short brief that names the file paths, the current cursor in the refactor, and the test that should pass when it lands. When you resume, paste the brief plus 'continue from the WIP commit' instead of replaying the original 'refactor X to Y' prompt; replaying the original prompt re-spends the same weekly minutes for a result you already have on disk.

Conditionally. Anthropic's metered billing flag (the extra_usage object on the usage endpoint) is_enabled tells you whether the account has it on. If it is on and used_credits is below monthly_limit, prompts that would have hit the weekly wall instead bill against extra usage. If it is off, or you are out of credits (overage.out_of_credits is true), the wall is the wall. ClaudeMeter renders extra_usage as a third row when the field is present, so you can see the live dollar burn during a heavy refactor instead of finding out at the end of the cycle.

Three things. (1) On your laptop, install ClaudeMeter (brew install --cask m13v/tap/claude-meter, then load the extension folder at chrome://extensions, then visit claude.ai once). The menu bar lights up within a minute. (2) Read the '7-day · Xd' row on the popup. The number is your real percent. The countdown is when the wall lifts. (3) Drop the four-line bash guard from this page into the wrapper around your Claude Code loop so the next refactor batch sleeps on seven_day.resets_at instead of bouncing off another wall.

Free and MIT licensed. Source at github.com/m13v/claude-meter. The browser extension runs one HTTPS request per minute to claude.ai using your existing session cookie (the same cookie your browser already sends to the settings page). The data goes to a localhost bridge at 127.0.0.1:63762 that the menu bar app listens on. Nothing leaves your machine. There is no cloud account, no telemetry, no analytics ping.