What actually triggers Claude's 5-hour limit (and the four ways around it)

A developer analyzed how Anthropic's Claude five-hour usage limit works, finding it is a rolling window that starts at the first message of a usage session rather than at midnight or at the moment of blocking, with a separate weekly cap resetting independently. The analysis notes that agent loops consume far more allowance than chat turns because each step re-sends accumulated context, and outlines four workarounds: waiting for reset, shrinking context, using usage credits, and moving workloads to a request-metered API gateway. The developer said they moved their own coding-agent work to a request-metered gateway after concluding the window model was the wrong shape for their workload.

If you have hit "You've reached your usage limit. You can resume in X hours" in the middle of a refactor, the useful question is not how many messages you get. It is what the clock is measuring and when it started. The five-hour limit is a rolling window. The timer starts at the timestamp of your first message in a usage session , not at midnight and not at the moment you get blocked. Two consequences follow, and they explain most of the confusion: There is also a separate weekly cap that resets independently of the five-hour window. Hitting the session limit does not mean you have exhausted the weekly allowance, and vice versa. Anthropic does not publish a universal message quota. Usage is weighted by several factors that compound: Published estimates put Claude Pro at roughly 45 messages per five-hour window, Max 5x around 225, and Max 20x around 900. Treat those as order-of-magnitude figures that vary with everything above, not as published guarantees. This is the part that surprises people, and it is mechanical rather than mysterious. A chat turn sends a prompt and gets a reply. The context is short and does not grow much. An agent loop is recursive. Every step re-sends the accumulated context: the same files, the same tool outputs, the same instructions. A fifty-step task can re-read the same context fifty times. Consumption grows with task length in a way a single chat turn never does, which is why one long coding session can consume an allowance that would have covered a week of chat. If you want to see where the allowance actually goes, the two levers that matter most are conversation length and model choice, in that order. 1. Wait for the reset. Free, and correct if the task can wait. The clock is already running from your session start, so check the reset time before assuming it is five hours away. 2. Shrink the context. Start a fresh thread rather than continuing a long one. Summarise tool output instead of pasting it. Cap the number of steps a single agent task may take, so a runaway loop cannot drain the window in one go. This is the highest-leverage fix and it costs nothing. 3. Use usage credits if you have them. When credits are enabled and available, sessions continue past the included limit rather than pausing. You keep working, and you pay for the overage. 4. Move that workload to an API key with a different limit model. This is the option people underweight, because it changes the shape of the constraint rather than the size of it. A subscription caps a window of time . An API key meters tokens or requests . Both are legitimate; they fail differently. A token-metered API gives you a large ceiling and an unpredictable bill. The cost of a task is only knowable after it finishes, which makes budgeting retrospective and per-project attribution a reconstruction exercise. A request-metered API bounds cost by the number of steps you allow. That converts budgeting from an accounting problem into a configuration decision, which is where it belongs if you are running agents rather than chatting. For a coding agent that runs long tasks, the second model is usually the better fit. For occasional chat and short jobs, token metering is often cheaper. Whichever you pick, check these before committing: 429 with Retry-After , or a dropped stream? A mid-stream drop loses the step and can leave a half-applied edit on disk. I run coding agents rather than chat, so the window model was the wrong shape for my workload and I moved that work to a request-metered gateway. The one I use is APIClaw https://apiclaw.biz/docs/ — OI -compatible, priced per request rather than per token, and it took a base-URL change to adopt. If you stay on a subscription, the context-shrinking advice above is the part worth doing regardless. The five-hour limit is a rolling window measured from your first message, weighted by conversation length, model, and attachments rather than a flat message count. Agents drain it fast because they re-send context every step. The fixes, in order of cost: shrink context, cap agent steps, use credits, or change the limit model entirely.