Verified through

Every time Anthropic or OpenAI
gave your usage limits back.

Both companies have taken to zeroing everyone's usage counters — sometimes to apologise for a bug, sometimes to celebrate a milestone, and sometimes for no stated reason at all. This is a cited record of each one since : when it happened, what prompted it, and what it was actually worth against the price you pay.

Drawn fromvendor announcements — official and staff accounts on X, company blogs, help-centre articles, status incidents Compiledby hand, not by a poller Last checked Newest entry Holding resets in  logged events Follow by RSS

The record

Every entry carries its sources, tiered by how much weight they can bear. A is the vendor itself — an official page, status incident, or company/staff account. B is independent press. C is a blog, forum, or individual, which is never used as the only evidence for an event.

    Get told when the next one lands

    A reset is worth a lot less if you hear about it a week late. While researching this we found ResetRadar, which pushes new resets straight out over RSS and Telegram the moment it sees them. That struck us as obviously the right call, so we have done the same here — the idea is theirs, and it is a good one.

    Want it as email rather than a feed reader? RSS does not send mail by itself — point a free RSS-to-email service such as Blogtrottr, Feedrabbit or Follow.it at one of the URLs above and it will forward each new entry to your inbox. Every item carries the vendor's verbatim announcement, the reason they gave, and its sources, so the email tells you the whole story without a click.

    Has someone already done this?

    Partly, and it deserves saying plainly. ResetRadar, by Giulio Capecchi, got here first. It watches the vendors' accounts on a schedule and publishes a running, source-linked ledger with feeds and a Telegram channel. It surfaced roughly fifteen of the events below that our own searching had missed, and this project openly seeded its research from ResetRadar's events.json. Its RSS feeds are why this site has them.

    The two projects answer different halves of the question. ResetRadar tells you, fast and without a human in the loop, that a reset happened. It stores each announcement as free prose, so it cannot tell you why — you cannot ask it how many resets were apologies — and it does not try to price them. Automation also has a cost: a post reading "We were resetting last week. This week we are SHIPPING" gets filed as a reset, an export-control notice gets filed as a reset, and the 5M-user reset appears twice, once for the announcement and once for the execution nine hours later.

    So this tracker trades their speed for a reading. Every entry is classified by the reason the vendor actually gave, priced against what you pay, and cross-checked — which is only possible because a person looks at each one. If you want the alert within the hour, subscribe to theirs too. They are not competitors; one of them is a wire service and the other is an archive.

    ResetRadar figures retrieved 10 July 2026 from the GitHub API and its published events.json; it is actively developed, so counts will have moved. Both projects are MIT-licensed. Nothing here is a knock on a tool we used and are grateful for.
     Reset TrackerResetRadar
    Project started 10 Jul 2026 23 Jun 2026
    Source code cwveysey/reset-tracker giuliocapecchi/ResetRadar
    History covered from 2 Dec 2025 2 Dec 2025
    Events logged 40
    Kept current by A person, reading each announcement An hourly cron, polling X
    Lag before a new reset appears Hours to days About an hour
    Alerts (RSS) Yes — all, plus per-vendor Yes — all, plus per-platform
    Alerts (Telegram) No Yes
    Machine-readable JSON Yes, CORS-enabled Yes
    Tells a reset from a limit increase Yes Yes
    Structured reason for each reset Yes — bug, milestone, launch, goodwill, holiday No — announcement kept as free text
    Flags resets with no reason given Yes No
    Sources graded by weight Yes — vendor / press / everything else Source links, ungraded
    Estimates what a reset is worth Yes — quota-cycle calculator No
    Publishes what it rejected, and why Yes — six candidates No

    Everything else in the field answers a third question entirely. OpenUsage, CodexBar and the various menu-bar monitors tell you when your own quota next refills. Useful, and unrelated. The methodology page sets out how each event was sourced, how the dates were established, and every candidate that was thrown out.

    Did we miss a reset? Get something wrong?

    Both companies announce these things on X, at odd hours, sometimes from a staff account and sometimes not at all. Things get missed. If you know of a reset that isn't on this timeline — or you think one here is misdated, misclassified, or misquoted — please say so.

    One rule, if you're flagging a reset we missed: include a link to the first-party source — the vendor's own post, blog, changelog, help-centre article, or status incident. Press write-ups and blog coverage are welcome as corroboration, but they are not enough on their own to log an event. Holding that line is the entire point of this thing.