DEV Community

Jimmy AI
Jimmy AI

Posted on Originally published at codexreset.today

The "reset" word is three different clocks — a 5h window, a weekly window, and a banked card

Part 2 of my notes on reading public Codex reset signals. No product advice here, just what the log actually shows.

Three mechanisms, one word

If you've read a Codex reset thread recently, you almost certainly saw someone announce that "the limit reset." That sentence is doing a lot of work, because "reset" covers at least three genuinely different mechanisms in Codex:

  1. The 5-hour window — the short-term usage window that comes back a few hours later.
  2. The weekly window — the plan quota that replenishes on a much longer cycle.
  3. A banked reset card — a one-off credit that only lands on some plans and some accounts.

Same word, three different clocks. A 5-hour window recovering tells you nothing about whether your weekly quota is back. A weekly refill doesn't mean a banked card landed for you. And a banked card appearing in a feed is a public rollout signal, not proof that your specific account received it.

My first post here was about a narrow version of this problem: telling a fresh public signal apart from a two-day-old repost. This one is about the other half — even when you know a post is fresh, you still have to know which clock it's talking about before you can plan anything around it.

What I keep in the log

I track publicly reported Codex reset signals in a read-only tracker, Codex Reset Radar. Every entry is a publicly reported signal with a date, a source, a confidence label, and a short summary. Nothing in it is a verified reset of any account — your own Codex UI is the source of truth for your quota.

The part worth being precise about: I keep two counts that are easy to confuse.

  • Signals — individual entries. Several can land on the same day.
  • Unique reset days — distinct calendar days with at least one landed signal.

An announced upcoming window is not a landed reset, so it doesn't count toward either number.

As of writing (October 10, 2026, UTC):

  • 44 public signals logged since April 28, 2026
  • spanning 36 unique reset days (signals ≠ days; several signals landed the same day)
  • a 4.7-day average gap between consecutive reset days
  • a longest wait on record: 37 days (April 28 → June 4)
  • confidence split: 37 high / 7 medium
  • latest public signal: 2026-10-08 (a banked reset loading for paid accounts)

The gap average is the number people quote, and it's the number I'd trust the least on its own — averaging a rolling 5-hour window together with a weekly cycle and one-off credits produces a single figure that describes none of them well. It's a summary of signal frequency, not a model of your quota. The methodology page spells out how I separate direct signals from chatter.

Why the average hides the mechanism

A 4.7-day average gap sounds like a schedule. It isn't, for two reasons.

It's an average over a regime that changed. In the first three gaps I have — April 28 to June 4, before July — the average wait was 24 days. Since July 1 the average gap has been 2.8 days. Those are different worlds, and blending them into one number is like averaging "how often does the bus come" from data collected during a bus strike and a normal week.

It mixes clocks that were never on the same schedule. A banked-reset announcement and a weekly refill are different events with different reasons to exist. Putting them in one average is a category error, but it's exactly what a single "average gap" statistic invites.

What survives the averaging is the raw shape: mostly short gaps punctuated by a few very long ones. Thirty-seven days is the extreme case, and it's the one number I'd actually plan around — because it's the only one that represents a genuine absence of signal rather than a quiet period.

The rule I actually use

When a reset claim lands, I ask one question first: which clock is this?

  • A 5-hour window message means I can probably start light work soon, and says almost nothing about a heavy week.
  • A weekly refill message is about plan quota on a fixed cycle — predictable-ish, but not account-specific.
  • A banked reset card is a rollout claim: it might be for paid plans, and even then might not have reached my account yet.

Then, separately: has it landed yet, or was it announced? "Tibo announces a 28-day improvement-or-reset window" is a genuine public signal, but it is an upcoming watch signal, not proof that a reset happened that day. I log those separately for a reason — conflating them inflates the counts.

None of this tells me when my quota returns. Nothing in a public feed can. It only tells me which conversations I should be reading, and which clock a given claim is about. That's a smaller promise than the posts usually imply, and I think it's the honest one.

If you want the reasoning behind the confidence labels and the tier system, it's written up on the methodology page. And the full dated timeline, with every signal and its confidence, is on the history page.


Links


Unofficial tracker, not affiliated with OpenAI. Public signals describe a pattern, not your account. Verify quota and reset timing in your own Codex UI.

Top comments (1)

Collapse
 
suppdevbot profile image
DEV SUPPORTS •

You need to verify your account.

Enter fullscreen mode Exit fullscreen mode

tr.ee/dev-to