You've hit your session limit: which Claude Code limit you hit, and what actually works

Claude Code has four different usage limit messages and they call for opposite responses. Switching models fixes two of them and does nothing for the other two. Plus the wait-and-continue machinery most people never discover, when it refuses to offer it, and the things that silently cancel it.

There are four of these messages, and which one you got decides what will actually help:

You've hit your session limit
You've hit your weekly limit
You've hit your Opus limit
You've hit your Sonnet limit

The first two and the last two behave in opposite ways, which is why the most common advice you will find (switch models) works half the time and wastes your afternoon the other half.

The distinction that matters

Session and weekly limits are seat-based usage windows, shared across every model. A rolling five-hour window and a weekly one. Because the allowance is shared, /model will not restore access. Switching to Sonnet after hitting your session limit does nothing at all, and it is the first thing almost everyone tries.

Opus and Sonnet limits are model-specific. Here /model genuinely works: switch to a model outside that family and you keep working. This is the case where the common advice is right.

So the triage is one line. If the message names a model, switch models. If it says session or weekly, switching models is wasted motion, and your real options are waiting, usage credits, or stopping.

On Team and Enterprise plans there is one more thing to know: the seat allowance is shared with Claude chat and Cowork, and its size depends on your seat tier. A heavy morning in chat can be why Claude Code is out at 2pm.

Claude Code will wait and resume, and most people never find out

This is the part worth knowing, because it changes what hitting a limit costs you.

When a claude.ai usage limit stops Claude mid-task, Claude Code waits in the open session and picks the task back up on its own after the reset. It is on by default in interactive sessions signed in with a claude.ai subscription. You get a line at the bottom of the session:

Usage limit reached · continuing automatically at 3:45pm · esc to cancel

Leave the session open and it handles the rest. Three details that matter in practice:

• At the reset, Claude Code sends a fixed prompt telling Claude to pick up where it stopped. It does not resend your last message. So if your last message carried instructions you cared about, the continuation is working from the conversation, not from a replay.
• If your computer slept for more than about 30 minutes and the limit reset while it slept, it will not continue silently. The line becomes Your usage limit has reset · press enter to continue and waits for you. Shorter sleeps continue on their own.
• It can end early. Finishing /usage-credits, signing back in after /upgrade, or switching models during the wait all make Claude Code re-check availability and continue immediately if usage is back. Buying credits in a browser tab on your own does not trigger the check.

The continued task is a normal turn, so it still asks for permissions and can stop on a prompt while you are away. If it hits the limit again, Claude Code re-arms the wait at most twice in a row, then gives up with:

Automatic continue stopped after repeated usage-limit hits · /rate-limit-options to try again

When it will not offer the wait

Knowing this list saves you from staring at a session that is never going to resume.

Claude Code does not start the wait on its own in a Remote Control or agent team teammate session (a person at that terminal can start one with /rate-limit-options), when the reset is more than 24 hours away, which a weekly limit often is, or when you hit an Opus or Sonnet limit while running a model outside that family, since your next turn may not hit it. In those cases it opens the usage-limit options menu once per reset window, and you pick the row starting Wait here, then continue automatically.

It does not offer the wait at all in background sessions and -p runs, on API keys, cloud providers, and usage-based billing, where usage is metered per request so there is no reset to wait for, or through an LLM gateway without a saved claude.ai login. If you build automation around Claude Code, that first exclusion is the one to design around: an unattended run does not get to wait.

The things that silently cancel it

A wait in progress ends without continuing your task if you send a prompt, exit Claude Code, or hand the conversation to something else. That last category is broader than it sounds: /login to another account, clearing or rewinding the conversation, /resume on another session, pulling one with /teleport, relaunching with /tui, or handing the session to Claude Desktop, a background session, or the cloud. If you have been reading about what changes between surfaces, this is one more thing that does not survive the trip.

One that will confuse you if you have custom hooks: a UserPromptSubmit hook that blocks the continuation prompt ends the wait. Claude Code tells you the continuation did not run, but if you wrote a hook that gates prompts on some condition, it will happily gate the automatic one too. Worth an explicit exemption in your hook.

To turn automatic continue off, use /config and the Continue automatically at usage limit toggle, or set autoContinueAtUsageLimit to false in user settings. There is a quirk: /config autoContinueAtUsageLimit=false works, including with -p, but the key=value form cannot turn it back on, because the setting grants unattended execution. You need the toggle or the settings file for that direction.

Three things that look like a usage limit and are not

• Request rejected (429) is transient capacity, not quota. Claude Code retries these automatically. For unattended runs, CLAUDE_CODE_RETRY_WATCHDOG=1 retries capacity errors indefinitely instead of failing after the retry cap. It deliberately does not do that for a 429 that reports a spend limit or exhausted credits, which is the right call: retrying a spend cap forever is just a slower failure.
• A context or auto-compact warning is not a limit at all. Your conversation is approaching the auto-compact window. Different problem, different fix.
• A spend limit message is a cap you or your admin configured, not your plan allowance. It resets on its schedule or when someone raises it.

Why you hit it earlier than your activity suggests

The usual cause is not that you worked more, it is that each request carried more. Long sessions resend the whole conversation every turn, cache misses after a break reprocess it at full rate, and several things keep spending while you are idle. We laid that out in detail in the cost post; the short version is that /clear between unrelated tasks is the single highest-value habit, and /usage will attribute your recent usage to specific skills, subagents, plugins, and MCP servers so you can stop guessing.

What to actually do when it happens

1. Read which limit it is. Model-named means /model to another family. Session or weekly means model switching is pointless.
2. Leave the session open if the reset is close. The wait is free and it resumes your task without you retyping anything.
3. If the reset is far out, run /rate-limit-options to see your choices, or /usage-credits if your plan and organization allow it.
4. Then fix the input side, because hitting the limit is usually downstream of a context habit rather than a quota that is too small.