Reset Beacon
HOW IT WORKS

How the forecast works

Checked every day against what happened

The estimate is the chance of at least one reset from OpenAI in the next 24 hours, and in the next 48. It says nothing about your own windows.

Inputs

Three things move the number. Biggest first: what OpenAI’s own accounts post, problems and fixes on the status page, and how far apart past resets have been. Product launches have come before make-good resets in the past, so we watch and show them, but the record doesn’t justify letting them move the number.

Visitor reports never move the number. We show them separately because they’re useful for seeing when a reset reaches people, and because they’re easy to fake.

Decay rules

Every signal decays. An official announcement keeps counting for 36 hours after it is posted. A status incident keeps counting for 48 hours, and its weight halves every 48 hours. Base-rate spacing does not decay but is recomputed whenever a classification changes.

If the newest input is more than 45 minutes old, the page says so and shows when it last updated, instead of passing off an old number as current.

The classification bar

An event is a reset only if a primary source names the affected population. “Reset for all paid subscriptions” qualifies. “Resets are going out” doesn’t. That gets recorded as acknowledged with the scope unverified, and it counts as a weaker signal for good.

We say ‘likely’ when the chance for that window is at least 80%, or 70% if OpenAI has promised a reset. When OpenAI’s Codex lead names a day for a reset, it has arrived 7 of the last 9 times.

Corrections

Classifications are corrected in place, dated, and listed on the history page. Affected forecasts are re-scored. No correction email is sent.

Limitations

The model is tuned to how often resets have happened. It can’t see inside OpenAI, so a reset decided and shipped within an hour will always catch it out. Its record is public, day by day.

At a glance
Model
calibrated-baseline-v1
Frozen record
reset-history-frozen-2026-08-26
Windows
24 h and 48 h
Update cadence
every 5 minutes
Stale after
45 minutes
48 h base rate
32% of 175 windows
Scored forecasts
149
What it is not

It doesn’t predict your own five-hour or weekly reset. OpenAI hasn’t promised anything. And if your Usage page says you’re out, believe the Usage page.

Privacy note

We store an email address only to send the four alerts. Unsubscribing stops the mail and keeps a suppression record so we do not send again by mistake. We can’t see your account, and there are no tracking pixels.

Full privacy policy

Early signs we watch

These six signs have shown up before resets. We check the live ones every five minutes. The ones that don’t make the forecast better stay here for context and don’t change the chance. When neither of the two that do is active, the chance rests on how long it’s been since the last reset.

Official status incident started

The first investigating update on the official status page starts this sign. It can be checked before a reset announcement, stays active for 48 hours, moves only the 48-hour chance, and never triggers an email by itself.

An official post hinted at a reset

This starts the first time OpenAI promises a reset, hints at one with a time, or answers complaints by saying a reset is coming. It can be checked before a reset announcement, counts toward both the 24-hour and 48-hour chances, can trigger one likely email, and stays active for 48 hours. A hint with a time in it uses the tested 3.15 weight, fading over 18.6 hours.

A Codex product or plan launched

A Codex plugin, plan, app or platform feature announced on an official channel starts this sign for 120 hours. It can be checked before a reset announcement. In the scored record, a launch inside five days was followed by a reset 33.3% of the time, against 33.8% when none was active, so it does not change the chance.

Reports that usage drained too fast

A rise in new reports that usage drained too fast starts this sign for 24 hours. It can be checked before a reset announcement. We count them from OpenAI’s public Codex repository, without naming anyone. The record is too short to let it change the chance.

An active-user milestone was reached

A user-count milestone has come before a reset, but the count only appears in the reset post itself. Nobody publishes it ahead of time, so we can’t check this one in advance.

A limits or billing bug was fixed

A bug in how usage was counted has come before a reset, but we only find out when OpenAI mentions it in the reset post itself. We can’t check this one in advance either.

How our account reading works

Every fifteen minutes the site reads the usage clocks on one paid Codex account of its own. If the weekly clock jumps to a later reset time before the old one arrives, and no banked credit was spent, a reset landed on that account. We wait for the next reading to agree, then email everyone: “A Codex reset is landing”.

An email from our account says “Seen” and the time we saw it. An email from a post says “Posted”. Accounts update at different times, so check your own Usage page. On the history page a reading sits beside the reset it belongs to as supporting evidence. The post is what confirms it.

Method changes

Dated changes to how the forecast is worked out and how the page words it. Newest first.

Three entries stopped being counted as separate resets

On 29 and 30 August, posts that gave a reset's landing time, explained what the published Pro limits mean, and recorded one account's own usage clocks restarting were each named as a reset of their own. They are now named for what they are: a schedule, a limits clarification, and a propagation observation attached to the reset they followed. Nothing was deleted and each correction is recorded against the entry it changed.

The number of confirmed resets is unchanged, because same-day entries were already counted once. The history page names each entry correctly.

The word “likely” has one rule

We say ‘likely’ only when the chance for that exact window is at least 80%.

The current page uses the same threshold for the same exact window.

Visitor wording only. Forecast percentages did not change.

The answer line says whether anything has happened

“A reset is possible within 48 hours” is gone. The line now reads “No signs of a reset yet” when nothing is live, and “Early signs of a reset” when an official signal is pushing the number up and it is still under 80%.

A reset is always possible, so that line told a reader nothing. It should say what has actually happened.

Wording only. The numbers did not change.

The home page shows the next 24 and 48 hours only

The seven-day strip was taken off the home page and off the share card, and a line was added giving the chance of no reset in the next 48 hours.

A reset from OpenAI is announced a day or two ahead at most, and bars covering a whole week read as day-by-day predictions.

Display only. The data feed still publishes the seven-day figures.

The track record page is described as a replay

The 149 scored days are described as today’s method replayed over the past record, forecasting each day with only what was known that day. The verdict wording is gone, and each number is shown with a plain explanation of what it means.

Wording only. The numbers did not change.

The chance is steadied against the longer record

The published chance is now three parts recent pace to one part the average of the last 120 days.

The recent-pace estimate on its own leaned on a few weeks of record.

The 48-hour figure read 46% before this change and 43% after it.

The forecast method was replaced

calibrated-baseline-v1 replaced empirical-hazard-v4. It measures the recent rate of resets on a 14-day half-life, corrects for the lag between a reset happening and being recorded, and uses one live signal: status-page incidents.

The old method leaned on three adjustments the record does not support, and one of them was the only thing moving the number.

The 48-hour figure read 57% under the old method and 46% under the new one.