How the forecast is calculated

claudereset.org, agentresets.com, codexreset.ai and whenreset.app now share one forecasting engine so readers don't see different numbers on different sites. The model is climatology: the fraction of historical reset intervals that fall within a given window, and it does not change based on how long it's been since the last reset. See the method page and the live backtest at whenreset.app/tools/backtest/.

whenreset has backtested this model on Codex; there isn't enough Claude history for a separate Claude backtest yet.

1. Gaps. Take the hour gaps between the most recent (up to 8) non-partial, non-banked global reset days. Banked credits are excluded from this list entirely: a banked reset is credited to an account and redeemed by the user whenever they choose, not something Anthropic clears for everyone at the same time, so it isn't a data point about the rhythm of global resets. Days with no exact announcement time are anchored at 12:00 UTC. avg_gap_h = their mean. Fewer than 3 gaps → forecast unavailable.
2. Baseline B = clamp(24 / avg_gap_h, 0.06, 0.55) — how much of a "reset day" 24 hours represents, given the typical gap.
3. Rhythm term — two variants, picked by backtest. This site tests two ways of turning the baseline into a same-day probability, and uses whichever one has actually scored better against history (below), not a fixed choice:
   • cooldown — C = clamp(hours_since_last / (avg_gap_h × 0.55), 0.18, 1.75), cad24 = clamp(B × C, 0, 1). Low right after a reset, rising the longer it's been — assumes resets get more likely the longer the wait.
   • memoryless — cad24 = 1 − e−24/avg_gap_h, the chance a Poisson process with mean gap avg_gap_h produces at least one arrival in the next 24h. No cooldown term at all: the same probability every day regardless of how long it's been since the last reset (deliberately not just B — it's a different curve, not merely the un-multiplied baseline).
   Currently selected: memoryless — chosen automatically because it backtested a lower (better) Brier score than the other variant (see the track record below); a tie would pick memoryless. This isn't a stylistic choice: our own walk-forward backtest of Claude's reset history, plus a competitor's published backtest and a third-party benchmark, all found the cooldown multiplier doesn't reliably outperform a memoryless baseline — so the formula now checks at every build instead of assuming cooldown is right.
4. Signals (each 0–1, decayed with a 24h half-life, discarded past 7 days old):
   • Official (weight 0.55) — the strongest scored candidate post: negated ("no reset"/"won't reset") = 0; future tense with a specific time word (a weekday, "today", a clock time) = 1.0; future tense alone = 0.6; otherwise 0.
   • Status (weight 0.25) — sum of relevant open/recent incident impact weights (minor 0.35, major 0.7, critical 1.0), each decayed by its own age, capped at 1. Never backtested (below only backtests the rhythm term) — kept as a hand-set heuristic, untested against history.
   • Issues (weight 0, context only — not used in the forecast) — GitHub issue surge: clamp((recent_24h / max(baseline_per_day, 0.5) − 1) / 3, 0, 1), no time-decay. Still shown on Status and the homepage signal strip, but no longer feeds S — see the note below.
   S = 0.55·official + 0.25·status (issues weight is 0, and the two remaining weights are not renormalized to sum to 1 — 0.55+0.25=0.80 on purpose).
5. Combine. p24 = clamp(1 − (1−cad24)(1−S), 0.01, 0.95). Probability composition, not a multiplicative boost: with cad24 near zero (e.g. right after a reset), a multiplicative form (B×C×(1+S)) would make even a strong live signal barely move the number. Composing them as independent-ish probabilities keeps a real signal meaningful no matter where the rhythm term sits.
6. 48h. p24′ = the same formula evaluated 24h from now (cooldown further advanced, signals further decayed). p48 = clamp(1 − (1−p24)(1−p24′), p24, 0.95) — never less than p24.

Until 2026-09-23 the GitHub-issues surge contributed 20% of the combined signal S. It no longer does — its weight is 0, and it isn't renormalized away. We ran a walk-forward backtest of the issues signal against actual global resets, using a much bigger sample than Claude has on its own: openai/codex's 385-day history, 46 global resets. Results, in our own words:

• Complaints did look elevated before a reset at first glance — but that turned out to be two unrelated trends both rising together (issue volume grew roughly 6× year over year, and resets happened to cluster more recently too). Shuffling reset dates within the same month made the apparent effect disappear (p=0.40).
• Scored honestly, out-of-sample, walking forward day by day: adding the issues signal didn't improve 24h predictions, and made 48h predictions measurably worse (Brier score +0.0038, 95% CI [+0.0010, +0.0072] — the whole confidence interval is on the "worse" side of zero).
• Claude's own history (12 global reset days) was too small a sample to show anything either way on its own — this isn't "Claude looked different," it's "not enough data to tell."

We'll reconsider this once Claude has 30+ global resets with precise timestamps: rerun the same backtest on Claude's own data, and only bring the issues signal back if both the Brier-score and log-loss improvements are confidently better than zero (confidence interval entirely on the "better" side) and a random-noise placebo test comes back clean (p<0.05). Until then it's tracked and shown for context, not used to compute anything.

The status signal (open incidents) has never been backtested either — it's kept as a hand-set heuristic, not because it's been shown to work, but because nothing has shown it doesn't.

• Average gap11.9 days
• Hours since last reset1548.9
• Rhythm model in usememoryless
• Baseline B0.0841
• Cooldown Cn/a (memoryless model)
• Rhythm term cad240.0807
• Official signal0.0
• Status signal0.3446
• Issues signal0.0
• Combined signal S0.0861
• p2416%
• p4826%

Confidence is low right now. There is no "high" tier. Medium requires all of: at least 10 historical non-partial, non-banked (global) gaps, the selected rhythm variant (memoryless) beating the climatology baseline in backtesting (below), and both signal sources the forecast actually uses — official and status — fetched within the last 6 hours with no failure. (Issues is tracked but no longer part of the forecast, so a failed issues fetch doesn't affect this.) Otherwise it's low.

• the selected rhythm model (memoryless) doesn't yet beat the climatology baseline in backtesting

Track record (rhythm term only)

Walk-forward backtest over 95 historical UTC days: for each day, four candidate predictions were computed from only the reset days known before that day, then scored against whether a reset actually happened, using the Brier score (lower is better). Only cooldown and memoryless are ever used to compute a live forecast — whichever of those two scores lower here is the one used live (above), a tie picks memoryless. naive and climatology are reference baselines only, not candidates the site would ever serve; by construction here they're the same "reset days so far / days observed so far" rate — naive is kept under the original spec's name for continuity, climatology is what confidence checks against.

• cooldown0.0823
• memoryless (selected)0.0781
• naive baseline0.0781
• climatology baseline0.0781

The selected rhythm variant does not currently beat the climatology baseline. This comparison is our own backtest of Claude's own reset history, not a third party's numbers. Only the rhythm term is backtested — the live signals (official/status/issues) have no historical record of what they looked like on past days, so they're never backtested, only explained above.

• Median gap8 days
• Mean gap12.8 days
• Shortest gap3 days
• Longest gap47 days

Data quality: The longest stretch with no recorded reset runs 47 days, 2026-07-16 → 2026-09-01 — that could be a gap in what got recorded rather than a real quiet stretch, which would inflate avg_gap_h above and, with it, the whole rhythm term.

• Small sample. Claude has had a handful of recorded resets so far — every statistic here can swing a lot with one more data point.
• Resets are discretionary. Anthropic announces them ad hoc, often tied to a release or an incident — there's no underlying schedule for a formula to actually be estimating.
• Weights are hand-set, not fitted. The 0.55 (official) and 0.25 (status) signal weights and every clamp above are chosen heuristics, not the output of fitting a model to data.
• No backtest of the signal part. Only the rhythm term is checked against history (above) — the live-signal contribution is untested against the past.