The five-hour limit, the weekly ceiling, and what each one actually costs you

Subscription AI plans advertise a message allowance. What they enforce is a set of overlapping limits that interact, and the interaction is what ends your session. This breaks down the three that matter and how to tell which one you hit.

The three limits, in order of how often they fire

1. The rolling window. A short window (commonly five hours) with a message cap that resets on a rolling basis. This is the one people notice first because it fires mid-afternoon. It is not a daily limit: the window slides, so waiting two hours can free capacity even though the day is young.

2. The weekly ceiling. A longer allowance that the short windows draw from. This is the limit that actually ends a heavy week, and it is the one least visible in the UI. You can be inside every five-hour window and still be out of weekly capacity.

3. The model multiplier. Not all messages cost the same. Requests routed to a larger model consume the allowance faster, so the same number of prompts can be comfortable on one model and ruinous on another.

The failure mode is that these compound. A user who hits the weekly ceiling on Thursday experiences it as "the five-hour limit got worse," because the short window is the only counter they can see.

How to tell which one you hit

The signal is in the reset time, not the error message:

• Resets in ~5 hours → rolling window. Wait it out, or reduce model size.
• Resets on a named day → weekly ceiling. Waiting a few hours will not help.
• Resets immediately but fails again on the next long request → context size, not the cap. A single large request can be refused when the window looks open.

That last case is the one people misdiagnose most often. A 200k-token request against a nearly-empty window can still fail, and the error reads like a rate limit.

What the limits are actually protecting

These caps exist because a long agent run has a cost profile a chat message does not. An agent loop re-sends its accumulated context on every step, so one task can consume more input tokens than a hundred chat turns. Providers cap it because the tail of that distribution is expensive and hard to predict.

That is a reasonable thing to cap. The problem for anyone running agents is that a message-count limit is the wrong unit: it does not tell you how many agent steps you can afford, and the answer changes with context length and model choice.

The practical workaround

If your workload is agents rather than chat, the useful question is not "how many messages do I get" but "how many requests can I issue, and what happens at the limit." A request-based allowance answers that directly:

• You can compute steps per task, and therefore tasks per day, before you start.
• The ceiling is a count rather than a moving token budget, so scheduling work becomes arithmetic.
• A clean refusal at the boundary lets your client back off instead of degrading mid-task.

The gateway I use for this is APIClaw — [OI]-compatible, priced per request rather than per token, with published request limits per plan and separate keys per client. Per-tool setup for Cursor, [CC], Codex and about twenty other clients is in the docs.

What to check before you switch anything

• Are request limits published per plan, or only token limits? A plan with no request cap has no upper bound you can plan against.
• What happens exactly at the ceiling? A 429 with Retry-After is workable. A dropped stream wastes the attempt.
• Can you attribute spend per client? If several clients share one key, you cannot compute cost per task for any of them.
• Does the provider separate the rolling window from the weekly ceiling? If not, you will keep misdiagnosing which one you hit.

Measure your own workload before committing to any of it. The limits on the pricing page describe the plan; the limits you hit describe your job.