How the forecast is calculated

Every reset on this site was announced ad hoc — there's no published schedule. This is an open, hand-tuned formula that turns "how long since the last one" and a few live signals into a rough percentage. It updates live in your browser every minute.

The formula

  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:
    • cooldownC = 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.
    • memorylesscad24 = 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.

Why the issues signal was dropped

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.

Current inputs

Recomputed live in your browser every 60 seconds.

  • Average gap14.0 days
  • Hours since last reset445.0
  • Rhythm model in usememoryless
  • Baseline B0.0712
  • Cooldown Cn/a (memoryless model)
  • Rhythm term cad240.0687
  • Official signal0.0
  • Status signal0.2762
  • Issues signal0.0878
  • Combined signal S0.0691
  • p2413%
  • p4822%

Confidence & track record

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.0722
  • memoryless (selected)0.0691
  • naive baseline0.0691
  • climatology baseline0.0691

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.

Gap stats

  • Median gap10 days
  • Mean gap14.1 days
  • Shortest gap3 days
  • Longest gap47 days

Data quality: 9 of 11 global reset days on record come from the public claude-resets.com archive (no original post, no exact time — counted as 12:00 UTC that day, see /about/). 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.

Limits of this model

  • 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.

Frequently asked questions

Is this a prediction?

No — it's an estimate built from how often resets have happened before, how long it's been since the last one, and a few live signals. Anthropic has never committed to a schedule, so treat every percentage here as a rough reference, not a forecast you can plan around.

Why does the percentage jump around?

Two reasons: the rhythm term grows the longer it's been since the last reset, and the live signals it's combined with (an open status incident, an official hint) decay and refresh independently. A quiet day can look very different from one with an open incident. GitHub issue activity is tracked for context but no longer moves this number — see the formula page for why.

Why is confidence usually 'low'?

Confidence only reaches 'medium' when there's a reasonably large sample of past intervals, the rhythm part of the formula has been checked against history and actually beats a naive guess, and all three live signal sources were fetched recently. With as few resets as Claude has had so far, that bar often isn't cleared — see the track record below.