How the Codex reset prediction works

1. Two cadence engines, over global resets only

Cadence is modeled on global regular resets only — banked drops are tracked separately (see /banked-reset/) and excluded from every gap/cadence number on this page, because they're credited to accounts rather than clearing usage for everyone at once, and mixing the two cohorts together would blur two different things into one number. Take the last 10 gaps between distinct global-reset dates. Fewer than 2 gaps and the forecast is unavailable outright — both p24 and p48 come back null.

The anchor time is the last global reset's exact timestamp when known, otherwise midday UTC (T12:00:00Z) on its date. h is hours elapsed since that anchor; avg_gap_h is the mean of the recorded gaps in hours.

Memoryless engine (constant-hazard / Poisson process): p_memoryless(hours) = clamp(1 − e−hours / avg_gap_h, 0.01, 0.90). This one deliberately does not care how long it's been since the last reset — the odds of a reset in the next 24h are the same the day after a reset as they are three weeks later.

Cooldown engine ("the longer you wait, the likelier"): baseline daily hazard base = clamp(24 / avg_gap_h, 0.06, 0.55), a multiplier cool(h) = clamp(h / (avg_gap_h × 0.55), 0.18, 1.75) that suppresses the odds right after a reset and raises them as the wait stretches on, and cad24 = clamp(base × cool(h), 0.01, 0.90); cad48 compounds two independent 24h windows for either engine the same way.

Which engine actually drives the live number: whichever scores the lower walk-forward Brier score in the backtest below (see §4) — ties default to memoryless. Currently: memoryless — memoryless Brier 0.1565 <= cooldown Brier 0.1767. Both engines' numbers are still computed and exposed even when only one drives p24/p48, so you can compare them yourself via /api/v1/forecast.json's cadence block.

Other public Codex-reset trackers have independently reported similar findings in general terms — that a simple constant-odds model tends to out-predict a "longer wait, higher odds" model on this kind of data. This page doesn't name or link them; it states only what this site's own backtest below found on this site's own data.

2. Live signals

Three independent signals, each scored 0–1, decayed by age (half-life 24 hours, items older than 168 hours ignored entirely):

The combined signal S = 0.55 × x + 0.25 × status blends with whichever cadence engine is currently selected: p24 = clamp(1 - (1 - cad24) × (1 - S), 0.01, 0.95), and p48 the same way from cad48, floored at p24. Displayed as an integer percent; 95% shows as “≥95%”, 1% as “≤1%”. See /signals/ for the current value of each input. The X and status signals are not backtested — they have no history of their own yet, so §4's backtest only scores the cadence half of the formula, for whichever engine is selected.

Why GitHub complaint volume is weighted 0

It was tested and it doesn't help. An out-of-sample backtest over 385 days of openai/codex issues (titles matching usage-limit wording, about 88% precision on a hand-checked sample) against the 46 recorded global-reset days found that complaints only look elevated before resets because both grew over the same period — the repository's issue volume rose roughly sixfold in a year. Shuffling within each month removes the difference (p = 0.40), and adding the signal to a walk-forward forecast made the 48-hour Brier score significantly worse (+0.0038, 95% CI +0.0010 to +0.0072), with no gain at 24 hours. So it stays on the signals page as context and contributes nothing to the number. The analysis is archived with this site's source; it will be rerun as more resets are recorded.

Two rules specific to the X hints signal:

• Freshness is when the upstream monitor last polled the timelines, not the timestamp of the newest hint itself — hints are rare, so a quiet period says nothing about whether the source is actually being watched right now.
• Resolution: a hint posted before the most recently recorded reset (global or banked — any kind) is marked resolved and stops contributing to the score — it's shown on /signals/ for context, but a reset already happened after it, so it can't still be evidence of one still coming.

3. Confidence

Confidence is low by default. It only reaches medium when the full 10-gap window is available, the backtest below shows the selected engine beating plain climatology on Brier score, and every signal was fetched less than 6 hours before the number was generated. It is never “high.” The confidence note on the home page states which condition, if any, failed.

4. Backtest

Walking forward one day at a time from the 11th recorded global reset to yesterday, using only history strictly before that day: how well would each engine have called each day, compared to a naive baseline (constant hazard with no cooldown) and to climatology (the overall historical share of days with a reset)? Global resets only — banked drops never enter this walk.

196 backtested days, 2026-03-11 to 2026-09-22. Calibration buckets below use the selected engine (memoryless) only.

On the current history, the memoryless engine scores better than plain climatology (Brier 0.1565 vs 0.1619). The largest gap between predicted and observed sits in the 0-10 predicted-range bucket (49 days: predicted 7% vs observed 16%).

Boundaries

• This is a probability estimate from public data, never a schedule — OpenAI has never stated one.
• Banked drops are excluded from the cadence model entirely — they're a separate cohort with their own dynamics (credited to accounts rather than a global clear-out), and mixing them into the global-reset gap sequence would distort both.
• Signal scores are not themselves backtested; only the cadence half of the model is, and only for the selected engine.
• A thin history window (fewer than 10 gaps) makes every number noisier, and the forecast is unavailable at all below 2 gaps.
• The model only reads public data — it has no visibility into OpenAI's internal plans.