Claude Code limits, explained

On a subscription, Claude Code meters you with rolling allowances rather than a per-token bill, and there is more than one of them running at once. The mechanics are simple once laid side by side; what confuses people is that three separate ceilings can each stop a request, for different reasons, with different ways out. Everything below about Anthropic's behaviour is read from its own documentation, cited where it matters and checked on 2026-09-19 — limits change, and /usage is always the authority for your account.

The rolling 5-hour session window

The shortest ceiling is a session window, and Claude Code's status-line documentation is where its shape is written down: a rolling five-hour window, exposed to a status line as rate_limits.five_hour with a used percentage from 0 to 100 and a resets_at timestamp in epoch seconds. Rolling is the word that matters — it is not a daily quota, it has no calendar boundary, and several complete windows can pass inside one working day. Where yours ends is what resets_at reports, and what /usage shows as a reset time. (code.claude.com/docs/en/statusline, read 2026-09-19.)

The weekly window on top of it

Behind the session window sits a seven-day one, exposed in the same payload as rate_limits.seven_day. The two are consumed simultaneously, not in sequence, and Anthropic's error reference is direct about the consequence: a single burst of heavy activity — a large workflow fanout, say — can exhaust the weekly allowance before the session window has even reset. That is the case where waiting five hours does nothing for you, and it surprises people who have only ever met the shorter limit.

Both of these are shared across models. Switching from one model to another does not restore access to either, because neither is scoped to a model in the first place.

The per-model weekly limit

The third ceiling is scoped. Anthropic's usage API reports it as a weekly limit attached to a particular model family, labelled with that model's display name, and the corresponding error messages name the family directly — the documented examples are "You've hit your Opus limit" and "You've hit your Sonnet limit". Unlike the session and weekly windows, this one has an escape hatch that costs nothing: switching to a model outside that family with /model keeps you working. The documentation notes the price of doing so, which is that each model keeps its own prompt cache, so the first request after the switch re-reads the whole conversation with no cache hits.

Because the label comes from the API rather than from a hard-coded list, ccclub renders whatever family name it is handed. If Anthropic scopes a weekly limit to a model that did not exist when your copy of ccclub was published, the segment still appears with the right name.

What hitting a limit looks like

The messages are specific, and each one carries its own reset time — "You've hit your session limit · resets 3:45pm", "You've hit your weekly limit · resets Mon 12:00am". Claude Code blocks further requests until that moment. Recent versions can also warn you on the way down, with a line such as "You've used 85% of your session limit", and can hold an interactive session open and continue the interrupted task shortly after the reset rather than making you come back to it. (code.claude.com/docs/en/errors, read 2026-09-19.)

When the limits reset

Neither clock is tied to the calendar. The five-hour window rolls, and the weekly window runs on your account's own seven-day schedule; neither turns over at midnight. Both reset times are in /usage, and both are in the status-line payload as Unix timestamps, which is what lets a status line count down to them. If the usage endpoint is itself rate limited when you ask, Anthropic's cost documentation says /usage falls back to the last bars it loaded on that machine within the past 60 minutes and labels them as last-known rather than pretending they are live. (code.claude.com/docs/en/costs, read 2026-09-19.)

What the limits actually count

Anthropic does not publish a token quota per window, and effective capacity is not a fixed number anyway: it moves with model choice and with how much context each request carries. The practical shape of it is that a heavyweight model consumes the allowance far faster than a small one, and that long conversations are expensive in a compounding way, because every turn re-sends what came before. The percentages in /usage are the only authoritative measure of where you stand.

How ccclub reads your limits

ccclub does not scrape /usage or guess from your logs. During a sync it asks Anthropic's own usage endpoint for your percentages, authenticating with the OAuth credentials Claude Code already stored in the macOS Keychain — no second login, and the token is sent only to Anthropic, the service that issued it, and is never uploaded to ccclub. It reads the five-hour and seven-day utilisation figures from that response, plus any model-scoped weekly entry, and writes them to a small cache under ~/.ccclub/ with a five-minute freshness window. The Claude Code statusline then renders that cache without ever making a request of its own.

Three honest limitations follow from that design. It is macOS-only, because the Keychain is where the credential lives. It covers Claude only — no other agent ccclub tracks exposes an equivalent endpoint. And it is a periodic reading rather than a live monitor: past three hours the numbers render dimmed with a trailing marker, and past twelve they are not shown at all, since a percentage that old describes a window which has since emptied and refilled. If you want alerts or burn-rate predictions, a dedicated real-time monitor is the right tool, not this.

What to do when you are close

• Match the model to the task. Mechanical edits and lookups do not need your most capable model, and model choice is the single largest lever on how fast an allowance drains.
• Keep contexts short. Start a fresh session for an unrelated task and use /compact; re-sending an enormous conversation on every turn is what empties a window fastest.
• Batch related questions rather than trickling out many small turns, each of which pays the context cost again.
• Switch families if the limit is model-scoped. An Opus or Sonnet limit leaves the rest of the lineup available; a session or weekly limit does not.
• Buy or request usage credits. /usage-credits — previously named /extra-usage — turns on metered usage beyond the allowance on Pro and Max, or sends a request to an admin on Team and Enterprise.
• Let it wait. On recent versions Claude Code can hold the session and resume the interrupted task at the reset time, which is usually better than restarting the task cold.

Watching the pattern instead of the moment

Limits are a question about the next five hours; habits are a question about the last five weeks. The two need different instruments. /usage and a status line cover the moment. For the pattern, reading your own usage numbers over 7 and 30 days shows whether the sessions that cost you the most are the ones you would have guessed, and a shared board with friends is a blunter version of the same signal — it tells you quickly whether your consumption is ordinary or unusual for the way you work.

Last updated 2026-09-29. Corrections welcome on GitHub.