Claude Code meters you on a rolling 5-hour window that opens with your first message and expires exactly five hours later, plus a separate weekly allowance counted in model-hours. This planner runs the constraint math: how long is left in the current window, how many prompts your plan's published allowance is actually worth once Opus weighting and prompt size are applied, when your current pace hits the ceiling, and which of the two limits binds first. Everything is computed locally in your browser. No pricing, no currency, purely quota arithmetic.
For your target volume and prompt size, this is the highest Opus share each tier can absorb inside one 5-hour window before the weighted demand exceeds the allowance, and the largest window a tier supports at your current Opus share.
| Tier | Per-window band | Max prompts at your mix | Max Opus share at your volume | Verdict |
|---|
The window is not a fixed clock grid. It opens at t0, the timestamp of your first message
after the previous window expired, and it resets at t0 + 5h. So the time you have left is
simply
remaining = 5h - (now - t0) reset = t0 + 5h
That is why two people starting at 09:10 and 09:40 have completely different reset points, and why an idle gap does not extend anything: the clock runs from the first message, not from your last one. The timeline above projects the day's successive windows assuming you keep working straight through.
Anthropic publishes the per-window allowance as a range, not a number, because the real meter is token consumption. This tool keeps it a range and never invents a false midpoint precision. Two corrections turn the published Sonnet-prompt band into your effective prompt count:
tokenMultiplier = avgTokens / referenceTokens weight = (1 - o) + w * o o = Opus share, w = Opus weight (~5) effectivePrompts = allowance / weight / tokenMultiplier
The weight term is a mixture: a prompt is Sonnet with probability 1 - o costing 1 unit,
or Opus with probability o costing w units, so the expected cost per prompt
is (1 - o) + w·o. At 30% Opus and w = 5 that is 2.2, meaning each
prompt burns 2.2 Sonnet-equivalents and your effective prompt count is 1/2.2 of the published band.
The token multiplier is linear: doubling average prompt size halves how many prompts fit, which is
exactly why large-repo sessions hit limits far sooner than the headline numbers suggest.
Your pace is measured from the window itself, not assumed:
elapsed = now - t0 rate = promptsUsed / elapsed (prompts per hour) capTime = now + (effectivePrompts - promptsUsed) / rate
If capTime lands after t0 + 5h, the window resets before you exhaust it and
the window is not your binding constraint. If it lands before the reset, the gap between the two is
dead time you will spend throttled.
The weekly cap is denominated in model-hours, tracked separately for Sonnet and for
Opus, and it accumulates across your whole schedule rather than one session. With
H = hoursPerDay × daysPerWeek, weekly demand splits as
H·(1 - o) Sonnet-hours and H·o Opus-hours. Each is checked
against its own allowance, and the binding constraint is whichever runs out first in coding-hours
from now:
weeklyHoursLeft = min( sonnetAllowance / (1 - o), opusAllowance / o ) windowHoursLeft = (effectivePrompts - promptsUsed) / rate binding = min(windowHoursLeft, weeklyHoursLeft)
Heavy Opus users almost always bind on the weekly Opus-hour cap rather than the 5-hour window, because the Opus weekly allowance is roughly a tenth of the Sonnet one. Sonnet-only users on a small plan typically bind on the 5-hour window instead.
A tier stops throttling you when its allowance covers your weighted demand. Setting
P · ((1 - o) + w·o) · m ≤ A for target volume P,
token multiplier m and allowance A, and solving for the Opus share:
o* = ( A / (P * m) - 1 ) / (w - 1) clamped to [0, 1]
Above o* that tier throttles you at your target volume; below it you fit. When
A / (P·m) < 1 the tier cannot carry your volume even on pure Sonnet, so no Opus
share works and the answer is fewer or smaller prompts, a higher tier, or the API, which has no
5-hour window at all and is bounded only by per-minute request and token rate limits.
Per 5-hour window, expressed as Sonnet prompts at reference size: Pro 10 to 40, Max 5x 50 to 200, Max 20x 200 to 800. Weekly: Pro 40 to 80 Sonnet-hours with no Opus access in Claude Code; Max 5x 140 to 280 Sonnet-hours plus 15 to 35 Opus-hours; Max 20x 240 to 480 Sonnet-hours plus 24 to 40 Opus-hours. These are Anthropic's published planning ranges, and they are estimates by design: the underlying meter is tokens, so your mileage moves with repo size, context reuse and tool output. Anthropic does not publish a distinct per-window band for Team premium seats, so this tool uses the Max 5x band as an explicit proxy for that option. Treat every output here as a planning estimate, not a guarantee.