The single most common mistake people make about AI coding limits is reading them as a daily quota.

Once you see them as rolling windows, most of the confusing behaviour stops being confusing — why your allowance came back at 3pm on Tuesday but 11am on Wednesday, why a light day did not give you a light afternoon, why two people on the same plan hit the wall at completely different times.

Daily quota versus rolling window

A daily quota is a bucket that empties and refills at a fixed moment. Spend it all at 9am and you are blocked until midnight. Spend nothing and you lose it. The state resets wholesale.

A rolling window works differently. There is no refill moment. There is a lookback: at any instant, the system asks how much you consumed in the last N hours, and compares that to a cap.

The behavioural consequences are the opposite of a daily quota:

  • Nothing is ever lost. Unused capacity is not banked, but it is also not wasted — it simply leaves the window.
  • Recovery is continuous and proportional. You do not wait for a moment. You wait for your oldest consumption to age out.
  • A heavy morning determines your afternoon. This is the part that surprises people. If you burn the full cap between 9 and 11, you are not blocked until midnight — you are blocked, partially, until those requests age past the edge of the window.

Why vendors use rolling windows

Because a daily quota creates a burst pattern that is bad for the vendor and bad for you.

With a daily quota, the rational behaviour for every heavy user is to spend everything as early as possible, because holding it back has no value. That concentrates load into the first hours after refill and leaves the rest of the day idle. Rolling windows spread demand, because spending now has an immediate cost to your own future capacity.

The side effect is a soft form of fairness: the person who works in a steady rhythm gets more usable hours out of the same nominal cap than the person who sprints.

Where the second cap comes in

Beyond the short window, most serious plans also carry a longer cap — commonly expressed as a weekly figure — on top of it.

These are not two versions of the same limit. They constrain different things:

  • The short window is about burstiness. It stops a single agent run from monopolising capacity.
  • The long cap is about total consumption. It stops a script from using a personal plan as an API tier.

You can be comfortably inside the short window and still blocked by the long cap. That mismatch — "my usage panel says I have headroom, but I am blocked" — almost always means you have hit the outer cap, not the inner one.

What this means for how you work

Three habits that follow directly from the mechanics, not from folklore:

Front-load the expensive, uncertain work. Refactors, large codebase sweeps and long agent runs are the things that consume unpredictably. Do them at the start of a window, not after you have already spent an hour on chat.

Watch the tail, not the total. Your recovery rate is set by what you consumed earliest in the window, not by the average. A single heavy burst leaves a shadow that lasts exactly as long as the window is wide.

Do not treat the panel as the truth about the outer cap. The short-window display updates continuously and feels responsive. The long cap often becomes visible only when you cross it.

The part you cannot plan

Rolling windows are arithmetic. They are predictable, and with a bit of observation you can model your own.

Vendor-issued resets are not. They sit on top of the arithmetic, they are announced without schedule, and they are the reason a reminder is useful at all. If you want to stop checking three places a day to find out whether today is a good day to start something big, that is the problem worth solving — and it is the only problem a reset tracker can honestly claim to solve.

ResetRemind watches for confirmed resets and emails you when one lands for the plans you pick. No prediction, no account, no charge.