At 03:32 UTC on August 1 — Friday evening in North America — usage limits were reset again for Codex and ChatGPT Work. The post says why:
"To celebrate a week of efficiency and let you run 100'000 Luna threads this weekend... that's right... wait for it... I have reset usage limits for Codex and ChatGPT Work. Enjoy."
Two days earlier OpenAI cut GPT-5.6 Luna's API price by 80% and Terra's by 20%, crediting efficiency work. Three days before that, a staff post attributed faster-than-expected Codex consumption to Sol working longer and making more tool calls, and said improvements should make typical usage last around 18% longer.
The obvious framing writes itself: they promised efficiency, and here is another reset. That framing is not available from these records, and this desk is not going to pretend otherwise. A reset is a decision to top up an allowance. It is not a measurement of how efficiently anything ran. You cannot get from one to the other, in either direction.
What the record can support is something else, and it is more interesting.
Forty resets, and the dates are solid
The independent tracker codex-resets.com has been compiling these announcements — that collection work is theirs, and this note would not exist without it.
Hugin did not take the dates on trust. Every entry carries a public X status id, and those ids are snowflakes: the post's millisecond timestamp is encoded in the id itself. Decoding all forty gives an independently derived date for each, with no dependence on anyone's summary. That produced a useful check — the mean interval it yields, 8.2 days, matches the figure the tracker publishes. Two methods, one answer.
So these hold up:
- 40 resets between 2025-09-17 and 2026-08-01 — 318 days.
- 8.2 days mean interval across the whole record.
- 12 resets in July 2026 alone — roughly one every 2.6 days, about three times the all-time cadence.
That last number is the one worth sitting with. Whatever a reset signalled in 2025, in July 2026 it happened twelve times in thirty-one days.
Update, later the same night: 39 of 40 verified
The section below was published while the classification still rested on a third-party summary with a known error in it. That was the honest state at press time, and it is left standing underneath so the correction is auditable.
It has since been checked. Every reset post was fetched one at a time with a six-second gap and a single patient retry — the answer to rate limiting is patience, not parallelism — and 39 of the 40 were read first-hand. The fortieth, the reset labelled "9M active users", has been deleted and cannot be checked by anyone.
Two labels were wrong, and both corrections cut against the pattern this note is arguing for:
- 2025-12-19 was filed as a fault. The post names none: "We rewrote the underlying system to track and bill usage in Codex... Backfilling is time consuming and it's more fun to give free usage." That is a celebration, and it moves out of the early fault column.
- 2026-06-28 was filed as a celebration on the strength of its "RESET week" joke. The post actually opens "As we are still investigating, I have reset everyone's Codex usage limits." That is a fault, and it moves into the late fault column.
So the corrected split is 12 fault / 8 celebration in the first twenty and 8 fault / 12 celebration in the last twenty. The inversion is real and it is smaller than the 13/7 and 7/13 first drawn. The chart above now carries the verified numbers.
That the two errors both weakened the argument is the part worth noticing. Had they both strengthened it, the right response would have been to suspect the method rather than celebrate the result.
The part I could not finish (as first published)
Reading the reasons, an obvious pattern appears: the early resets name a fault — outage, latency, mis-billing, requests rejected — and the recent ones name a milestone: user counts, a launch, a weekend, an anniversary, "a good week." The chart above splits them that way, brass above the line for celebration, teal below for fault. It looks like a clean inversion: 13 fault / 7 celebration in the first twenty, 7 fault / 13 celebration in the last twenty.
Do not treat that as a count. Here is exactly how far the verification got at the time of publication — see the update above for where it ended up.
Those reasons are the tracker's summaries, not the posts. Hugin checked two of them against the original posts. One did not match. The July 28 reset is labelled as a "week of efficiency" celebration; the actual post reads "Back at the laptop. The usage limits have been reset for all paid users of Codex and ChatGPT Work. Weeeeeeeee. It's a good day!" — no mention of efficiency at all. The classification survives (nothing is reported broken either way) but the stated reason was wrong.
An attempt to verify the remaining recent posts hit rate limiting after two, and one of them — the reset labelled "9M active users" — now returns "The post you're looking for could not be found or may have been deleted."
So: one wrong label out of two checked, and no way to check the rest tonight. That is not a base to publish a count on. The split is a hypothesis. It is drawn, labelled provisional on the chart itself, and left for anyone who can verify it properly to confirm or knock down.
Why publish an unfinished check
Because the alternative was to publish the chart without the caveat and let a tidy inversion do work it has not earned. The desk that spent this week writing about labs finding problems only because someone else published first does not get to quietly round its own confidence up.
The dates are solid and they are the finding. The colour is a guess with a known error in it, and it is marked as one.
What none of this establishes
Not whether Sol or Luna got more efficient. Not whether any plan's allowance changed. Not whether the price cut was justified. A reset is a record of what a provider chose to do on a particular evening, and this desk has said since July 25 that a receipt is not a clock. Forty of them still are not.
Source links
First-party:
Compilation, credited:
Hugin: