Claude Code's 5-hour limit, explained

Claude Code's five-hour limit is a rolling window: it starts at your first message in a session and resets exactly five hours later, at the time the lockout message shows you, not at the top of the next hour. It doesn't pause while you're away from the keyboard, either - scheduled tasks, cross-session messages, and a handful of other things Anthropic's own docs name keep drawing against it whether you're typing or not, which is the real reason two sessions that ran the same number of hours can hit the wall at very different points.

What actually starts the five-hour clock

Claude Code's cost-management docs confirm the mechanic for Team and Enterprise seats in plain terms: usage "resets on a rolling five-hour window and a weekly window." Pro and Max run the same two-gate structure - a five-hour session budget plus a separate weekly one, with Opus metered on its own weekly ledger apart from every other model, per the plan's own usage limits breakdown. "Rolling" is the part worth sitting with: it isn't tied to the wall clock the way a daily limit resetting at midnight would be. It starts counting from your first message and runs five hours from that exact point, and the lockout message tells you the exact reset time rather than a round number.

What Anthropic's current docs don't spell out is the precise event that starts a new window once one has reset, or whether a long idle gap between messages resets it early on its own. The error reference is explicit that the window "resets at the time shown in the error message" and nothing more granular than that - so treat the reset time in your own lockout message as the one number that's real, not a guess built from someone else's session.

Both budgets count at the same time, not in sequence. That matters more than it sounds: a single burst of heavy activity, like fanning a task out across several parallel subagents, can exhaust the weekly allowance before the five-hour session window ever resets - the weekly clock doesn't wait its turn.

The six things burning your window while you're not typing

This is the part that doesn't show up in most explanations of the limit, and it's stated directly in Claude Code's own docs rather than estimated: a session that's been open for hours can use far more of your window than your actual typing suggests, for reasons that have nothing to do with how much you asked Claude to do.

Three of them fire while you're away from the session entirely. A scheduled task runs on its interval whether the session is idle or not, and each run sends the full context along with it, not just the task's own instruction. A message from another one of your sessions gets delivered as a new turn by default when this session is sitting idle, carrying the same full context. And an agent teammate - a parallel Claude Code instance spawned to help - keeps its own context window and keeps consuming tokens for as long as it stays alive, whether or not you're watching it.

The other three hit the moment you come back. Prompt caching keeps a recent conversation cheap to resend, but the cache lifetime is one hour on a subscription (five minutes once you're drawing on usage credits, unless ENABLE_PROMPT_CACHING_1H is set) - miss that window and your next message reprocesses the entire conversation from scratch at full price, not the cached rate. Every request in a long session resends the whole conversation plus your project context regardless, so a one-line question late in a four-hour session still carries everything that came before it. And when the context finally gets large enough to trigger /compact, the compaction step itself has to read everything it's about to summarize - shrinking your context is not a free operation, it's a large request that happens to buy you smaller ones afterward.

Two sessions, same length, wildly different burn

Picture two sessions that both run close to the full five hours. Session A gets /clear'd between unrelated tasks, has no scheduled tasks or agent teammates attached, and its longest gap between messages stays under an hour. Session B runs one continuous conversation across a lunch break, has a scheduled task firing every 30 minutes in the background, and spawns a couple of agent teammates to parallelize a refactor.

| | Session A | Session B | | --- | --- | --- | | Cleared between unrelated tasks | Yes | No - one long thread | | Longest gap between messages | Under 1 hour (cache stays warm) | Over 1 hour (cache misses on resume) | | Scheduled tasks attached | None | Fires every 30 min, full context each time | | Agent teammates | None | 2, running in parallel | | What the five hours actually bought | Mostly the work itself | The work, plus every drain above stacked on top |

Neither session did anything wrong, and neither is a bug - Session B just spent real budget on things that never showed up as a prompt it typed. If your own lockouts feel earlier than the work you did should justify, this is the more likely explanation before assuming the window itself is too small: check what else was attached to the session, not just how much you asked it to do.

What to actually do when the wall is coming

Run /usage before you're blocked, not after - it shows progress toward both the session and weekly windows against your real account, and a custom status line can surface the same rate_limits fields continuously so you see the wall coming instead of hitting it. Once you do get a lockout message, which one you got changes the answer: an Opus-only block means /model gets you working again immediately on Sonnet or another model, because that limit doesn't touch the shared session and weekly budgets. A session or weekly block is shared across every model, so switching doesn't help - /usage-credits (Pro and Max buy directly; Team and Enterprise members request it from an admin) lets you keep working past it without waiting for the reset time.

If you're mid-task when the warning appears rather than already blocked, /clear between unrelated threads and matching the model to the job are the fastest ways to stop paying for context you don't need right now - the full breakdown of which setup habits drain a session fastest is in the usage-limit-reached guide, and it's worth reading alongside this one since the two lists rarely overlap.

Where the five-hour window doesn't apply

Not every Claude Code session runs on this clock. API key billing through the Claude Console and usage through Amazon Bedrock, Google Cloud, or Microsoft Foundry is metered per token with no five-hour gate at all - you're billed for what you use, full stop, and the controls that apply are workspace spend limits and rate limits instead. On Team and Enterprise plans the five-hour and weekly windows are real, but they gate a per-seat allowance rather than the same shared consumer pool Pro and Max draw from, and its size depends on whether the seat is Standard or Premium tier.

And across every plan tier, Anthropic confirms the two-budget structure exists without publishing an exact message count, token count, or size figure for either one. Any number you see attached to "how many messages in five hours" - including older figures still circulating from earlier in Claude Code's life - is an estimate layered on top of a mechanic Anthropic documents, not a spec Anthropic states. /usage against your own account is the only number in this whole picture that's actually real.

FAQ

• Does the 5-hour Claude Code limit reset at a fixed time, like midnight? No. It's a rolling window that starts at your first message in a session and resets exactly five hours after that specific point - Claude Code shows the exact reset time in the lockout message, and it's different for every session.
• Does the 5-hour window keep counting down while I'm not using Claude Code? The window itself doesn't pause, but what drains it while you're away comes from specific sources: a scheduled task firing on its interval, a message delivered from another session, or an agent teammate still running - not idle time by itself.
• Why did I hit the limit almost instantly after stepping away and coming back? Most likely a cache miss - the prompt-cache lifetime is one hour on a subscription (five minutes on usage credits), so a break longer than that makes your next message reprocess the full conversation at full price instead of the cached rate.
• Does switching models with /model reset or avoid the 5-hour limit? Only for an Opus-specific lockout. The session and weekly limits are shared across every model, so switching doesn't restore access to those - it only helps when the message names Opus specifically.
• Is the 5-hour limit the same on Pro, Max, Team, and Enterprise? The mechanic is the same rolling 5-hour-plus-weekly structure on every tier. The size differs (Max gets more room than Pro), and Team/Enterprise runs it as a per-seat allowance rather than the individual pool Pro and Max use - none of the tiers publish an exact number.
• Does the 5-hour limit apply if I'm paying through the API instead of a subscription? No. API key billing through the Claude Console, and usage through Bedrock, Google Cloud, or Microsoft Foundry, is metered per token with no five-hour session gate - spend controls there are workspace and rate limits instead.

None of this tells you which of the six drains above is actually the one eating your own sessions - the free scan reads your real Claude Code history and shows exactly where a session's window went instead of leaving you to guess from a docs page. If the setup habits matter more than the window's mechanics for your own case, the usage-limit-reached guide covers those, and the usage limit calculator projects your own headroom across Pro, Max 5x, and Max 20x from a baseline you give it.

Made by Neo

UsageCut by ClockedCode - not affiliated with Anthropic. The figures on this page are measured on real Claude Code sessions and labeled measured or estimated where it matters.