Codex's Reset Tracker Hit 35. Why Is the Meter Still a Mystery?

When I inspected Codex Resets on July 19, 2026, the unofficial tracker showed 35 announced resets, an average interval of 8.9 days, and a longest gap of 67.7 days. The site follows reset announcements from OpenAI's Tibo Sottiaux on X and turns them into a 26-week calendar and announcement log.

My first reaction was amusement. Someone built a weather report for the Codex reset button. My second was less comfortable: if developers need a separate site to follow surprise refills, those refills have become part of how people understand the product. A reset can be a welcome apology, a promotion, or a quick mitigation. It is still a poor substitute for usage accounting that people can predict and audit.

Answer Snapshot

Question	My read
What does the site track?	Public reset announcements attributed to Tibo Sottiaux, displayed as a calendar and chronological log.
What did it show?	On July 19, it listed 35 resets, an 8.9-day average interval, and a 67.7-day longest gap.
Why do resets happen?	The logged announcements cite several reasons, including outages, latency, usage investigations, promotions, system changes, and user milestones.
What is my conclusion?	The tracker is useful, but the product needs clearer usage explanations more than it needs surprise generosity.

The tracker turns anecdotes into a pattern

The value of the submitted source is not that it reveals a secret policy. It does not. The site says it is not affiliated with OpenAI, uses Tibo's announcements as its data source, and classifies them automatically. That means I would not treat 35 as a complete accounting of every backend action or every account-specific benefit.

It does make the rhythm visible. The log includes resets tied to incidents, high latency, a billing-system rewrite, a promotional increase that failed to reach an estimated 9% of Plus and Pro users, and celebrations of user milestones. More recent entries also distinguish between a full reset applied automatically and a banked reset that a user can apply later.

A reset is doing several jobs at once

The same word now covers several different product functions. A reset can compensate users after degraded service, buy time during an accounting investigation, or promote a model or feature. Those are different events, even if the user sees the same weekly gauge jump back toward full.

That ambiguity matters because OpenAI's Codex plan documentation says task consumption varies with the size and complexity of the work, the model, and where it runs. Larger repositories, long-running work, and extended sessions consume more allowance. When someone reaches a limit, the available choices may include buying credits, upgrading, or waiting for the limit to reset.

Free usage can still create a planning cost

A reset sounds unambiguously good when the weekly allowance is nearly empty. The trade gets stranger when a reset arrives before a user planned to spend the remaining capacity, or when a banked reset has an expiry. In a recent r/codex discussion, users compared missing resets, resets that appeared not to apply, unclear expiry times, and frustration with the interaction between short usage windows and weekly capacity. These are user reports, not proof of a single system-wide defect, but they show why the mechanics need plain explanations.

The new rate card makes that need sharper. OpenAI says that on April 2, 2026, Codex pricing moved from per-message estimates to token-based credit accounting for Plus, Pro, Business, and new Enterprise plans, with the remaining existing Enterprise plans following on April 23. Input, cached input, and output tokens carry different credit rates. That is more legible than a vague message count, but only if the usage view helps a person connect a task to the meter movement.

The skeptical case is about evidence

The critique I find persuasive is not that resets are a trick. It is that a refill does not explain the drain. An open Codex GitHub issue from May 2026 reports weekly usage remaining dropping from about 70% to about 7% near a five-hour boundary. The reporter included local log details and possible explanations, but the issue remains an allegation under investigation, not a confirmed root cause.

Public reports can point to accounting bugs, cached-context behavior, background work, a display reconciliation problem, or simply a workload that cost more than the user expected. A blanket reset can reduce the immediate pain in all of those cases. It cannot tell the user which case occurred.

What I would want instead

I would keep the reset button. It is a sensible recovery tool when an outage or accounting issue hurts users, and a banked reset can be genuinely useful. I would also make every reset explain itself in the product: why it was issued, which pool it refills, whether it changes a rolling window, when it expires, and whether it was applied automatically.

The usage side needs the same treatment. A developer should be able to see which task, model, and execution surface moved the meter, with cached and output usage separated clearly enough to investigate a surprise. OpenAI already tells users to monitor the Usage panel, and its pricing now maps credits directly to token categories. The remaining work is to make that accounting understandable at the moment it matters.

My takeaway

Codex Resets is a clever little site, but its existence points to a larger product gap. Thirty-five tracked announcements do not prove that Codex is unreliable, and the tracker itself is explicit about being unofficial. They do show that resets have become a recurring language for incident response, promotions, capacity changes, and user reassurance.

I appreciate free capacity. I would trust it more if I did not need a tracker to understand when the button was pressed or a forum thread to guess what the refill changed. The reset should remain the safety valve. It should not become the user manual.