How this is measured
Two kinds of evidence, kept separate.
1. Public reset records
Three public trackers publish machine-readable histories. They are credited here and were read on 2026-10-29 08:52 UTC:
| Source | Endpoint |
|---|---|
| codex-reset.com | /api/timeline |
| codexreset.ai | /api/v1/resets.json |
| didcodexreset.com | /api/status.json |
These publishers largely watch the same upstream announcements, so agreement between them is corroboration, not independent proof. codexreset.ai states its history before 2026-09-10 was seeded from codex-resets.com.
2. Our own observation
The Codex client reports the account's usage window on every turn: used_percent, window_minutes, resets_at. We record that snapshot on a schedule. A reset is counted when both hold:
- usage drops by at least 20 points and lands at or below 20%;
resets_atmoves forward by at least six hours.
Requiring both matters: resets_at alone drifts by seconds to minutes between requests and would produce false positives. A single account is enough to detect a global reset, because a reset applies to everyone at once.
3. What it does not tell you
- It cannot tell you what will happen — only what has happened, and at what rate.
- Announcement timestamps and effective times can differ; we cluster records within ten hours into one reset.
- Coverage depends on how often the account is used; quiet stretches have fewer observations.
- Four resets in our own record (2026-09-23, 09-25, 09-30, 10-03) were seen on the account but are absent from the public lists. They are marked "our own account" and remain unconfirmed.