Where does reset history come from?
Records are synchronized through the Codex Resets public API . That tracker aggregates @thsottiaux’s public posts and observations using automated classification. We keep provenance, post links and retrieval times, labeled “Archived”. This does not mean we independently verified each post.
Posts explicitly granting banked resets are counted separately from immediate global resets. The July 12 and 13, 2026 posts describe banked grants; their upstream regular-reset classification was corrected here. Announcements containing both are counted once as global, with details noted.
How is “time since last reset” calculated?
It counts days, hours, minutes and seconds from the latest global reset announcement or first observation. Banked resets do not restart it. This is elapsed time, not a prediction of the next global reset.
Average and longest intervals use gaps between consecutive global records with precise times. They describe the archived history, which may be incomplete, and do not set a deadline for the next reset.
Which events can be marked “Verified”?
Evidence must support the event, scope and time. A global reset needs an explicit first-party statement that it took effect. Planned resets remain “Announced”.
Help pages explain reset rules, not whether a particular reset occurred. GitHub issues, community posts and individual account screenshots are signals only.
Three source categories
- Official sources:OpenAI announcements, official release notes and service status.
- First-party statements:Original posts by team members, with identity and context checked by a maintainer.
- Community signals:GitHub issues and user reports; these cannot directly establish a verified global reset.
From collection to verification
- Check a fixed set of public sources and preserve the results and timestamps.
- Queue relevant new messages for review instead of immediately publishing them as resets.
- A maintainer checks the original source and records event type, scope and time.
- Confirmed events enter history and the public API. Eligible subscribers are notified when configured.
How are times and missing data shown?
Global history uses UTC dates. Date-only sources keep that precision; no hours or minutes are invented. Such records are excluded from precise interval calculations.
Scheduled tasks sync history and check sources every 15 minutes. “Refresh data” reads the latest stored check, not a new source check. Failed checks remain visibly failed.
Why are forecasts not published yet?
Probabilities require at least 10 independently verified global resets with accurate times and continuous historical coverage. Third-party history is not automatically verified training data. Until requirements are met, probabilities are null.
Forecast snapshots store publication time, 24- and 48-hour probabilities, explanation and model version. Accuracy can be assessed only after the full outcome window and with reliable record coverage.