Codex Resets watches one X account for OpenAI Codex usage-limit reset announcements and keeps every one as a dated, source-linked entry. It adds interval statistics, alert routes and a free keyless API and MCP server.
Used this tool? Rate it
Used this tool? Rate it
Codex Resets is a single-page web tracker that watches one X account, @thsottiaux, for OpenAI Codex usage-limit reset announcements and republishes each one as a dated, permanent log entry. It answers a narrow question with no official home: has the Codex limit reset recently, and how long has the wait been historically?
That question exists because OpenAI does not publish Codex resets on a schedule or a status page. They arrive as informal posts — after an outage, after a bug that drained limits faster than expected, or simply to mark a milestone. If you are not watching that account continuously, you find out late or not at all.
It is an independent side project built by a developer publishing as @wong2__, and the footer states plainly that the site is not affiliated with OpenAI. The site is candid about the narrowness of that pipeline: the data comes from one person's posts and is classified automatically rather than by an editorial desk. Knowing that up front matters more than any feature list, because it defines what the page can and cannot tell you.
The published sitemap lists exactly one URL, which is an honest signal that the reader-facing product is a single page rather than a documentation estate. The live figures, calendar, archive and alert routes all stack onto it, with the machine-readable routes behind.
Entries are typed rather than lumped together: a regular reset restores limits directly, a banked reset issues a credit, and the calendar view adds a third no-reset state for quiet days. The distinction is not cosmetic. A banked reset is a saved credit you redeem when you choose, so it does not refill limits at the moment it is announced; the tracker points you to the Codex app profile sidebar, then Usage, to apply one.
Confusing the two is the most common way to misread an announcement. Seeing "reset" and assuming your quota is full wastes a planning decision when what landed was a credit sitting unredeemed. Typing each entry prevents that, and a raw feed of posts would not.
Three aggregate figures sit above the log — a running total, an average wait and the longest wait on record — reading 53 resets, 6.9 days and 67.7 days when this page was compiled. Read them together. The average spans months where resets clustered heavily and months where they stopped entirely, so the longest wait is what should temper any expectation built on it.
Nothing ages out of the Codex reset history: the archive is expandable to every recorded reset at once and reaches back to an entry dated 17 September 2025. That depth is what makes the averages meaningful — a rolling window of recent weeks would produce a much more flattering average.
Every entry keeps a link back to the original post, so a claim can be checked at its source instead of being trusted in the tracker's paraphrase. That makes the archive usable as evidence rather than trivia, and it answers the site's own disclosure that classification is automatic: when a typing looks doubtful, the original wording is one click away.
Not every entry originates in a post: some are recorded as observed and carry an observed identifier rather than a post identifier, which a live read of the list confirms in practice. These capture resets that happened without a matching announcement; treating them as equivalent to announced ones is a mistake, since the evidence is weaker by construction.
One reaction control sits beside the headline figure and flips its own label with recency, reading Beg for a reset most of the time and Say thanks for the reset in the day after one lands. A public counter shows reactions accumulated since the last reset.
This is the one expressive rather than informational part of the page: a mood gauge, not a petition with standing. It does not reach OpenAI, does not influence when a reset happens, and its count is no demand signal anyone acts on.
Reading the page needs no setup, so the only decision is which delivery route to attach and how to read it. Three delivery routes are wired directly into the page — browser push, a Telegram channel and an email list — so you can pick the one that matches how you already work.
Step five matters because announcements are not uniform: some cover all paid plans, some name specific tiers, some promise propagation over the following hour, some attach conditions about when an account was created. A notification is a prompt to read, not a conclusion.
The honest test is whether a dated log of someone else's announcements changes what you do next, and in three situations it does.
If you are near a Codex usage limit with work left, the useful question is whether waiting beats upgrading. Three aggregate figures sit above the log — a running total, an average wait and the longest wait on record — reading 53 resets, 6.9 days and 67.7 days when this page was compiled, enough to frame the decision without settling it. An average near a week against a worst case near ten weeks argues against betting a deadline on one.
A hosted Model Context Protocol server exposes the same two operations as agent tools, get_status and list_resets, so a coding assistant can consult the log without anyone writing HTTP glue. An agent can answer "when did Codex last reset" mid-session, and a dashboard shows the same figure without a scraper that breaks when markup changes.
A banked reset is a saved credit you redeem when you choose, so it does not refill limits at the moment it is announced; the tracker points you to the Codex app profile sidebar, then Usage, to apply one. That is why it is the entry type most likely to be left unredeemed, and why an alert route plus the entry type closes the gap.
The fit question turns on one distinction: whether you need to know what OpenAI announced publicly, or what your own account currently holds.
The reader-facing surface is a browser page with no installable app; integration sits behind it.
| Route | What it serves | Access |
|---|---|---|
| Web page | Live figures, calendar, full archive, alert sign-up | Open, no account |
| REST API v1 | Current status and paginated announcement list | Keyless, open cross-origin |
| MCP server | Same data as two agent tools | Hosted, no HTTP glue required |
| Browser push | Notification when a reset is recorded | Per-device permission |
| Telegram channel | Same notifications on a phone | Channel subscription |
| Email list | Durable record of confirmed resets | Double opt-in |
The documented version 1 API is deliberately small: two read-only GET routes, one returning current status and one returning a paginated list of announcements. The list route accepts limit, cursor, from, to and order, returns 20 announcements by default and caps a single request at 100, paging onward through an opaque cursor.
The specification also commits to the unglamorous parts of an integration contract, documenting ETag revalidation, a 400 for a malformed parameter, a 429 carrying Retry-After, and a 503 when reset data is temporarily unavailable. For a free side project that is a notable amount of contract, and it separates something you can build against from something you babysit.
Support is one email address, with no help centre, status page or ticket queue behind it. Plan integrations accordingly: no escalation path exists if a route changes.
Because the page is free and asks for nothing, the cost question is not money but whether its interval-reporting stance matches what you want from a tracker.
Reading the page, using the alerts, calling the API and connecting the agent server cost nothing and need no account. The money comes from elsewhere: four sticker card slots beside the tracker sell at 699 US dollars a month against a stated audience of roughly 180,000 monthly visitors, paid through Stripe and reviewed before publication. That is the business model in full, and it explains why the reader side stays free and unauthenticated.
On alternatives, the relevant gap is a deliberate one. Two competing Codex trackers publish an explicit probability for the next 48 hours, which this site deliberately does not do because it reports intervals instead. If you want a single forward-looking number, that is a real reason to look elsewhere; if you distrust probabilities built on thin event counts, intervals are the more conservative choice.
A rival tracker's dated comparison credits this site with the longest event span among the trackers it opened and with linking a source per event, while noting that every automated tracker it checked reacts faster than its own hand-curated ledger. Weigh that against its origin: a competitor assessing rivals, whose self-critical rows are why it is worth citing at all — not a reason to treat it as neutral.
The other alternative is not a product: for your own remaining quota, the Codex app's usage screen is the only authoritative source, and no public tracker substitutes for it.
Where the tool does look forward, it marks the boundary in its own machine-readable description: watch data is an AI-classified forecast, not an official OpenAI commitment. A scheduled entry means an announcement is still awaiting execution evidence, and the specification is explicit that a passed scheduled time does not imply the reset actually completed. Both statements are unusually careful for a tracker and should be taken at face value.
The site is candid about the narrowness of that pipeline: the data comes from one person's posts and is classified automatically rather than by an editorial desk. If that account goes quiet or posts something the classifier reads wrongly, the tracker inherits the problem with no second source to cross-check. The per-entry source links mitigate this; they do not fix it.
The specification also commits to the unglamorous parts of an integration contract, documenting ETag revalidation, a 400 for a malformed parameter, a 429 carrying Retry-After, and a 503 when reset data is temporarily unavailable. Treat the 429 as a real constraint: the ceiling is documented but its threshold is not, so a polling client should honour Retry-After rather than assume headroom.
A comparison also states the site offers no JSON, CSV or API, which contradicts both the published specification and a live keyless response, so the two accounts are in conflict and the machine-readable routes should be confirmed at the source. An aggregator summary from 19 July 2026 recorded 35 resets at an average of 8.9 days, against 53 resets at 6.9 days read live in September, so both the log and its derived averages move underneath any figure quoted elsewhere. Any number you read about this tool secondhand is a snapshot.
For readers the page has no sign-in, no account area and no billing screen, and the only identifier it ever collects is the address or device used for alerts. The flip side is the hard scope limit already noted: with no account link, it cannot show personal quota. Independent evidence about the product is thin. A submission to a large developer community board drew 312 points and 200 comments in July 2026, which measures attention rather than accuracy, and this round found no review-platform rating or technology-press assessment to weigh against the site's own account.
No. There is no sign-in and no account connection, so it cannot read your usage. It reports what was announced publicly; your own remaining allowance is only visible in the Codex app's usage screen.
A regular reset restores limits directly. A banked reset is a saved credit you redeem when you want, so it does not refill limits immediately — you apply it from your profile sidebar under Usage in the Codex app.
It is free and keyless. A live call to the documented status route returned data without any credential and sent an open cross-origin header, so a browser page can read it directly.
Yes. A hosted Model Context Protocol server exposes get_status and list_resets as tools, so an agent can consult the log without custom HTTP code.
No. The product's own description labels watch data an AI-classified forecast rather than an official OpenAI commitment, and a scheduled entry stays pending past its stated time until execution evidence appears.
Nothing is dropped from the archive. The full log is expandable in one action and reaches back to an entry dated 17 September 2025.
Through sponsorship. Four sticker card slots beside the tracker sell at 699 US dollars per month, purchased via Stripe and reviewed before they appear.
