'Heavy use' on Claude Pro is utilization ≥ 80% on any of seven weekly buckets

Anthropic's support article on usage limits gives a range, not a counter: roughly 40 to 80 hours of Sonnet 4 per rolling 7-day window on the $20/month Pro plan, with a smaller 5-hour rolling sub-window inside it. The reason it's a range is that the limiter scores prompts by model weight, peak-hour multiplier, and message complexity, then writes the result into a utilization fraction. You hit the wall when that fraction crosses 1.0 on any bucket, not when you cross a fixed hour count.

Operationally, utilization at or above 80% on any weekly bucket. That is the threshold ClaudeMeter's popup paints amber, and it's the threshold the toolbar badge switches color on. Source: extension/popup.js line 31 `v >= 100 ? "hot" : v >= 80 ? "warn" : ""` and extension/background.js line 87 (the same numbers driving the badge background color). Anthropic doesn't publish a 'heavy' tier, but 80% is the inflection where you have to start budgeting the rest of the rolling 168 hours.

No. The /api/organizations/{org}/usage JSON has up to seven separate 7-day buckets: seven_day (overall), seven_day_sonnet, seven_day_opus, seven_day_oauth_apps, seven_day_omelette, seven_day_cowork, and the rolling 5-hour bucket that interacts with all of them. Source: src/models.rs lines 20-26 in the ClaudeMeter repo. Each has its own utilization and resets_at. The badge picks the worst-case across all of them because any one at 100% throttles your next prompt with the same generic 'rate_limit_error' string.

Two reasons. First, Claude Code traffic lands in seven_day_oauth_apps in addition to seven_day. If oauth_apps is at 100% you get throttled even though the overall row reads 70%. Second, the 5-hour rolling sub-window resets independently; you can be fine on the weekly view and still hit the wall mid-refactor because five_hour spiked from a long Opus run. ClaudeMeter renders both rows so you can see which bucket actually fired.

Open claude.ai, sign in, open DevTools (Cmd+Option+I), Network tab, visit claude.ai/settings/usage. Filter for 'usage'. Open the request to /api/organizations/<uuid>/usage and look at the JSON response. Each bucket has a utilization field (0 to 1, sometimes 0 to 100; popup.js normalizes with `u <= 1 ? u * 100 : u`) and a resets_at ISO timestamp. The Settings page shows you the same numbers in human form, but rounds them; the JSON has the float.

No. ccusage reads ~/.claude/projects/<project>/<session>.jsonl on disk and sums tokens per Claude Code turn. That is a faithful local-log signal for Claude Code only, and it has no access to the per-model weights, peak-hour multiplier, or browser-chat usage the server folds into the weekly utilization fractions. ccusage at 5% next to claude.ai at 71% is normal: two ledgers, two ledger sources, neither replaces the other. ClaudeMeter is a separate tool for the server-side number; the two coexist.

It slows it. seven_day_opus and seven_day_sonnet are weighted differently inside the overall seven_day bucket, and Opus consumes the cap faster per minute of generation. But seven_day is a single fraction across both models, and seven_day_sonnet still has its own cap that can fire on its own. Switching to Sonnet for grunt work extends the window; it doesn't make the wall impossible. The honest planning move is to watch the seven_day bar tick and pace against the resets_at countdown.

It's the only free, open-source way that reads the same server-truth fields claude.ai/settings/usage renders. ccusage and Claude-Code-Usage-Monitor read local JSONL logs from Claude Code, which is a different data source (local token counts, not server-enforced quota). The claude.ai Settings page is the canonical source but you have to refresh it manually. ClaudeMeter polls the same endpoint once a minute and surfaces it in the menu bar.