The errors look similar and mean different things. Getting this wrong leads to the worst possible response: waiting the wrong amount of time, then hitting the same wall again.
Here is how to read them.
The three constraints behind every message
Nearly every "limit" error you will see is one of these, wearing different words:
Short-window burst cap. You consumed too much inside the short rolling window. Recovery is proportional — you regain capacity as your oldest usage ages out. Waiting a short while genuinely helps.
Long-window cap. You have consumed too much over the longer period. Waiting a few minutes changes nothing. Only time passing on a scale of days, or a vendor reset, changes this.
Per-model cap. You have exhausted one specific model while others remain available. The fix is not waiting at all — it is switching.
Telling them apart
Three signals, in order of reliability:
Does the message name a model? If yes, suspect the per-model cap first. This is the single most actionable distinction, and it is the one people skip past.
Does it say "try again in X minutes", or does it name a date and time? A minutes-scale hint points at the short window. A named date points at the long cap. A message that gives no time at all usually means the long cap — the vendor cannot tell you when, because the answer depends on when you started consuming.
Does the usage panel show headroom? If the responsive short-window display says you are fine and you are still blocked, you are on the long cap. This is the check that resolves the most confusion, and it is the one most people do not think to run.
The responses, matched
| Reading | Wrong response | Right response |
|---|---|---|
| Short-window cap | Waiting all day | Wait, work shallowly, or switch model |
| Long cap | Retrying every ten minutes | Reorder the day; do work that does not need the tool |
| Per-model cap | Waiting at all | Switch model and continue |
The pattern worth noticing: only one of the three is fixed by waiting. Most of the frustration around limits is people applying a wait to a problem that waiting cannot solve.
Why the messages are vague
Partly product design — a precise error invites arguments about the exact threshold. Partly genuine complexity: with rolling windows, "when will this be available again" depends on your own consumption history, which the error handler often does not have at hand.
The practical consequence is that you should treat the error text as a category hint, not as information. It tells you roughly what you hit. It rarely tells you what to do.
Being early instead of precise
The one thing that reliably improves the situation is knowing earlier. Not more precisely — earlier.
A reset is the only event that changes your constraint without any action on your part. Everything else (windows, caps, model routing) is either arithmetic you can plan around or a switch you can flip. That is why a reset notification is worth having and why a "limit calculator" mostly is not.
ResetRemind emails you when a confirmed reset lands for the plans you selected — Codex, Claude Code, Grok, Gemini. Free, no account, one click to unsubscribe.