If you use Codex or Claude Code heavily, you have probably hit a wall that looked like a billing problem but was not. Your subscription was fine. Your card was fine. You had simply spent the allowance the plan gives you inside a rolling window, and the tool stopped until that allowance came back.
A reset is the moment that allowance comes back early.
That definition sounds trivial. It is not, because it separates two things people constantly conflate:
- The rolling window. A structural property of your plan. It moves continuously and it is predictable in the sense that you can reason about it.
- A reset. A vendor decision. Someone at the company decided to lift caps ahead of the normal schedule. It has no published cadence.
The first one you can plan around. The second one you cannot, and any product claiming to predict it is guessing.
Why vendors reset at all
Resets look like generosity. They are also a retention instrument, and understanding that explains their behaviour.
When a heavy user is blocked, the cost to the vendor is not the compute they would have consumed — it is the risk that the user opens a competing tool that afternoon and likes it. A blocked user is a user in the market. Lifting the cap for a few hours removes that risk at a cost the vendor chooses on purpose.
Three practical consequences follow:
- Resets cluster around competitive pressure. When a rival ships something, when a rival raises its limits, when usage numbers are being watched — those are the moments caps come off.
- Resets are announced, not scheduled. They arrive as a post from an executive, or quietly in the product, with no lead time. There is no calendar to subscribe to.
- A reset is not a rollover. Your normal window still exists. The reset is an extra, on top of it.
What a reset is not
This matters more than the definition, because most confusion comes from expecting resets to behave like something else.
It is not a fixed weekly rollover. Some plans do have a weekly cap that clears on a rolling basis. That is arithmetic, not a reset. It will happen whether or not anyone announces anything.
It is not a refund of usage. Resets restore your capacity to work. They do not give you back the tokens you already spent, and they do not change where you sit inside the rolling window.
It is not account-wide in a documented way. Whether a reset applies to one model, one surface, or every plan tier is decided case by case and communicated vaguely or not at all. Treat "reset happened" as a signal to try again, not as a guarantee that a specific endpoint will work.
How you find out
Three channels, in descending order of how early they tell you something:
| Channel | Latency | Reliability |
|---|---|---|
| Executive post on X | Minutes | High for "it happened", low for scope |
| In-product usage panel | Immediate once you look | Depends on which surface you check |
| Community relays (Discord, group chats) | Seconds to minutes | High volume, uneven accuracy |
The problem is not availability. It is that checking all three costs attention, several times a day, on a schedule nobody controls.
That is the entire reason a reminder exists as a product category. Not to predict anything — to remove the polling.
If you are deciding whether to build on this
A short note, because this is the question behind most searches for "codex reset".
The demand is real and it is not about curiosity. Every person who hits a cap is making a live decision — do I start this refactor now or wait? — and a reset changes the answer. That is a decision with a deadline attached, which is the strongest kind of notification trigger there is.
What is not real is the supply side of prediction. Any product selling "reset probability" is selling a number it cannot compute. The honest products do one thing: watch, confirm, and tell you.
ResetRemind tracks confirmed resets for Codex, Claude Code, Grok and Gemini and emails you when a window opens for the plans you selected. Free, no account, one click to unsubscribe.