Claude 的 5 小時用量限制由甚麼觸發，以及四種應對方法

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 window is rolling, not daily

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:

• Two people on identical plans hit their limits at completely different clock times.
• The five hours you wait is measured from when you started, so a burst that begins at 09:00 unlocks at 14:00 even if you hit the wall at 09:40.

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.

It is not a fixed message count

Anthropic does not publish a universal message quota. Usage is weighted by several factors that compound:

• Conversation length — longer threads consume more of the allowance, because each turn carries the accumulated context.
• Model choice — the larger models draw down the allowance faster than the smaller ones.
• Attachments and file contents — reading a large file into context counts against you.
• Tools, effort level, and artifacts — extended thinking and tool loops are not free.

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.

Why agent sessions drain it so much faster than chat

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.

The four options when you hit the wall

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.

Choosing between token-metered and request-metered APIs

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:

• What happens exactly at the ceiling: a clean 429 with Retry-After, or a dropped stream? A mid-stream drop loses the step and can leave a half-applied edit on disk.
• Are limits enforced per key or per account? Per-account limits let one runaway agent starve every other job.
• Can you issue separate keys per client or environment, so attribution is a query rather than a reconciliation?

What I actually use

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 — [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.

Summary

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.