How Codex & Claude reset odds are calculated

Current numbers, via whenreset.app

Pulled from https://whenreset.app/api/forecast at the time of this build; the numbers on this page refresh once more in your browser against whenreset.app's own live (5-minute-cached) values.

These are estimates, not predictions — vendors have never committed to a reset cadence. Numbers, model name, and backtest scores above all come from whenreset.app; this site never substitutes a number it computed itself. See whenreset.app's own method & backtest page for the full derivation.

Independent backtest (research only — not used for the numbers on this site)

Before 2026-09-24 this site ran its own three probability formulas and picked whichever backtested best on this product's own recorded history. That engine selection is still recomputed on every build and published below for comparison — it no longer drives any number shown anywhere on this site, including the "Current numbers" section above.

Formula

Reset events for the product are deduped by date first (multiple announcements on the same day only count once). Three methods are computed from that deduped history:

Memoryless model

Takes the mean of the most recent 10 deduped gaps (in days), converts it to an average gap in hours (avg_gap_h), and treats a reset as a constant-odds ("memoryless") process:

P(reset within h hours) = 1 − e−h / avg_gap_h

This number deliberately does not depend on how long it's already been since the last reset — that's the entire point of "memoryless": the odds of a reset in the next 24 hours are the same the day after a reset as they are a month later, under this model. With fewer than 2 historical intervals, this candidate has no result.

Conditional model

Turns the most recent 30 deduped gaps into a lookup table indexed by how many days you've already waited (t, today minus the most recent reset date). The probability of a reset within h more days (h = 1, 2, or 7):

P(reset within h days | already waited t days) = #{historical intervals g : t < g ≤ t+h} ÷ #{historical intervals g : g > t}

The denominator is how many historical intervals held out at least t days without a reset; the numerator is how many of those then reset within h more days. With fewer than 5 historical intervals total, this candidate has no result. There's a second guardrail too: even with enough intervals overall, if the denominator — intervals that lasted longer than the current wait — is below 5, no result is scored either; something like 1-out-of-1 would only mislead.

Climatology (base rate) model

The plain historical frequency of a reset landing on any given day — total deduped reset days divided by the number of days spanned since the first recorded one — extrapolated to each horizon as daily_rate × h days, capped at 100%. Uses the full history, no window. With fewer than 2 distinct dated events, this candidate has no result. This is also the formula whenreset.app itself currently publishes (see the "Current numbers" section above) — the two are independent implementations of the same public method, not the same computation.

Banked resets are excluded from every method above — only global (immediate) resets count toward the historical intervals, since a banked credit is issued now but redeemed later and would understate how long the wait for an actual reset has been.

This site's own walk-forward backtest

Every time this site rebuilds, it re-runs a walk-forward backtest: for each day in a product's own recorded history, using only data available strictly before that day, it asks all three methods above for the probability of a reset landing within 24 hours and within 48 hours of that day, then scores every method's prediction against what actually happened (Brier score — lower is better). This is not a predictive model itself — it's a historical scoring exercise used only to evaluate the three formulas against each other.

Recomputed from scratch on every build, over this product's own real recorded history. It is not used to pick any number shown on this site — see the "Current numbers, via whenreset.app" section above for that.

Limitations

• Small sample: each product currently has at most 30 usable historical intervals to work with (the memoryless model uses the last 10), so backtest scores shift as the sample changes — products with fewer recorded intervals are less stable.
• Cadence can change: reset policy, release schedules, and incident response can all shift without any advance notice, so a past frequency doesn't necessarily hold going forward.
• Resets tend to track releases or incidents, not a clock: a new model, an incident recovery, or a milestone can all trigger an extra reset, and none of that shows up in a plain day-count.
• This is a frequency estimate over past announcements, not a forecast of anything not yet announced.

This is not a predictive model — it's an empirical frequency estimate. Neither OpenAI nor Anthropic has committed to a fixed reset cadence, so treat it as a rough reference, never a timetable.