DEV Community: Jimmy AI

Banked resets changed the meaning of "waiting" — what I learned logging Codex limits for five months

Jimmy AI — Mon, 12 Oct 2026 02:00:00 +0000

Part 3 in my notes on reading public Codex reset signals. This one is about how my own habits changed, not about a product feature.

The thing I thought I understood

When I started logging public Codex reset signals in late April, I had a simple mental model. Quota runs down, time passes, quota comes back. Waiting was one long continuous stretch that you endured until it ended.

That model was fine for about five weeks. Then a banked reset showed up in the log — a one-off credit that doesn't follow the normal 5-hour or weekly cycle at all — and quietly broke the assumption.

Banked resets don't wait, they stack

A banked reset is a credit that loads into an account. You don't wait for it. It arrives when it arrives, possibly because of something entirely unrelated to your usage (a milestone, a product rollout, an incident, a "we're giving one for every day you didn't have access" promotion). It isn't tied to your clock.

Once I understood that, "waiting" split into two very different experiences:

Waiting for a window to refill. Fixed, predictable-ish, boring. You know roughly when it ends.
Waiting for a banked credit you didn't earn by waiting. Unpredictable, and frequently not about you at all.

The second one is the interesting one, because it inverts the old logic. Under the old model, usage bought waiting. Under the new one, something outside your control could hand you capacity regardless of how carefully you rationed — and it could just as easily skip your plan entirely.

The five-month arc, in three acts

The full log runs April 28 → October 10, 2026: 44 public signals across 36 unique reset days, a 4.7-day average gap, and one 37-day silence in the middle.

Act one — the quiet months (late April to June). Three signals, and the gaps between them were 37, 8, and 27 days. An average of 24 days. In this period, "waiting" literally meant waiting, because there was almost nothing else happening. This is the stretch my mental model was built on, and it's the least representative part of the log.

Act two — the regime change (July onward). The average gap dropped to 2.8 days and it stayed there. Signals started arriving in clusters: 12 unique reset days in August, 10 in September. The log stops reading like a metronome and starts reading like a calendar with events on it.

Act three — the banked-credit era (late September to now). The recent entries are dominated by banked reset and reset-card activity — Tibo posting about banked credits loading for paid accounts, reset cards tied to launches, and one banked-reset rollout that landed with enough of a kerfuffle that it was logged twice on the same day. The 28-day "improvement or full reset" window announced on October 5 is logged as an upcoming watch signal, not a landed reset, precisely because of this distinction.

What actually changed for me

Three real shifts, none of them about prediction:

I stopped treating a banked reset as the thing I was waiting for. It's not part of a cycle; it's an event that may or may not include me. Assuming it lands is how people talk themselves into a bad week.
I stopped reading long gaps as "nothing is happening." The 37-day stretch wasn't a broken tracker; it was the real shape of the early log. And it could happen again. A tracker that only knows how to describe busy periods is a tracker that will confidently mislead you the next time it's quiet.
I got more disciplined about "for whom." A reset card for paid accounts is a rollout claim. Some of my logged signals are specifically paid-plan. Whether a specific credit reached a specific account is, by construction, not something a public log can know.

None of this made me better at predicting resets. It made me better at not being surprised by them — which, for planning around a tool, turns out to be the thing I actually needed.

The honest caveat: I only observe public signals. I have no visibility into anyone's actual quota, plan, or credit balance. Everything above describes the pattern of reports, not the behavior of any account.

If you're reading this thread

The reasoning behind the confidence labels is on the methodology page. If you want to check my work rather than take my word for it, the raw log is public — every event with its date, source, and confidence is on the history page, and the same data as JSON is at reset-events.json. The running summary I publish is reset-status.json.

If my read of the pattern is wrong, you can find the exact entry that shows it.

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

Jimmy AI — Sat, 10 Oct 2026 15:08:42 +0000

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:

The 5-hour window — the short-term usage window that comes back a few hours later.
The weekly window — the plan quota that replenishes on a much longer cycle.
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.

I logged 39 public Codex reset signals so I could tell fresh from re-shared

Jimmy AI — Fri, 02 Oct 2026 05:55:19 +0000

Codex reset posts are easy to find and hard to use. A signal gets logged,
then re-shared two days later by someone who read it as live, and by then
"the weekly window reset" and "a one-off reset card" are sitting in the
same feed using the same word.

I wanted a single place to answer one narrow question: is this reset
claim new, or am I reading a two-day-old repost?

That turned into a small read-only tracker for public Codex usage-limit
reset signals — Codex Reset Radar.
Each event carries a date, a source, a confidence label, and a summary;
older events stay visible so the history doesn't reset itself every time
something lands.

The problem: "reset" is three different clocks

Reading these threads, the same word covers at least three events:

the 5-hour usage window coming back,
the weekly plan window replenishing,
a one-off reset card that only some plans see.

Same word, three different clocks. A repost from three days ago reads
exactly like breaking news, and a signal that was true for one plan gets
read as "my quota should be back too."

What the log actually records

Every entry is a publicly reported signal, not a verified reset. As of
writing (October 2, 2026, UTC):

39 public signals logged since April 28, 2026
across 33 distinct reset days (events ≠ days; several signals landed the same day)
4.8-day average gap between consecutive signal days
longest wait so far: 37 days (April 28 → June 4)
confidence split: 32 high / 7 medium
latest public signal: 2026-09-30 01:48 UTC (GPT reset card for paid users)

"High confidence" means a strong public source said something — not
that your quota went back. For the "strong signal, nothing changed on my
account" case, the site keeps a reset-failed checklist: rollout lag,
plan scope, 5-hour vs weekly windows, and banked-reset confusion.

What it is not

Not affiliated with or endorsed by OpenAI — unofficial by design.
No OpenAI login, no API keys, no cookies, no session tokens. It never touches your account and can't see your plan or workspace.
It does not predict your quota. Nothing public can. Your own Codex usage UI is the only account-level source of truth — the site says so in almost every state it's in.

If you'd rather pull the data than read it

Three read-only endpoints, no key required — a status file with derived
stats, a full event list, and an RSS feed:
the API page.
Fine for dashboards, status bots, and home-lab monitors. They carry the
same unofficial disclaimer as the site.

The full history lives at
the reset history page.

If something in the log is wrong, or the source ranking looks off, tell
me in the comments — that correction is worth more to me than the post
itself. Happy to walk through how the confidence labels are assigned,
too; that part took the most time to get right.

(Unofficial, not affiliated with OpenAI. Your Codex usage UI is still
the source of truth.)