Bug: Weekly quota not reset in unified reset (June 4) + Metering anomaly for Plus account
What issue are you seeing?
On June 4, 2026, OpenAI reset usage restrictions uniformly for all paid ChatGPT subscribers, however, my Plus account did not receive this reset. My weekly reset date remains June 14th, while the reset dates for other affected users have been changed to June 11th.
In addition, I encountered a serious measurement anomaly in this week's quota calculation:
I used 35 million tokens this week, leaving only 36% of my weekly limit.
But when 120 million tokens were used last week, there was a remaining 10% weekly limit.
Obviously, my calculation ratio deviation this week is too large
What steps can reproduce the bug?
<img width="270" height="186" alt="Image" src="https://github.com/user-attachments/assets/19e9e176-7915-4140-94b1-988fb4ad6f39" />
<img width="296" height="156" alt="Image" src="https://github.com/user-attachments/assets/8269448e-3222-4019-9e1d-9a6eed93f416" />
What is the expected behavior?
_No response_
Additional information
<img width="352" height="173" alt="Image" src="https://github.com/user-attachments/assets/953db3e0-fe6b-44a5-8dec-97d89384fc08" />
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I can confirm a very similar pattern on my side.
After the June 4, 2026 Codex update and quota reset, my weekly usage started draining noticeably faster under comparable development workflows. This was not caused by Fast mode: my speed setting is Standard. Suggested Prompts are disabled, and I am using GPT-5.5 with High reasoning.
This looks related to the same class of problem described here: quota reset / metering behavior changed around June 4, and the visible weekly percentage no longer feels comparable to previous weeks.
I posted a more detailed report in #14593:
https://github.com/openai/codex/issues/14593#issuecomment-4643942177
At this point OpenAI should treat this as a potential metering or quota-accounting regression, not just as “some modes consume more.” Users need a concrete explanation of what changed around June 4 and why the same kind of work now appears to consume the weekly limit much faster.
Remember that OpenAI is a California business. If you can’t get any help with your billing issues, you can also ask the CA AG’s office for help here: https://oag.ca.gov/contact/consumer-complaint-against-business-or-company
If you do file a complaint, remember to include all details like dates, screenshots, and other supporting documentation. Be specific, but don’t vent. The person who reads your complaint should have all details in front of them so they can reply to you as fast as possible without delays waiting on an update from you
renewed 5x pro today but the weekly usage is not reset. what's going on here
<img width="277" height="173" alt="Image" src="https://github.com/user-attachments/assets/ea2f54d9-1c89-4683-8bf7-e7016aa8f1c2" />
<img width="297" height="96" alt="Image" src="https://github.com/user-attachments/assets/6a2fa747-8855-4ac3-9185-65f51a3cc1e3" />
Small follow-up from my side.
After updating and restarting Codex today, the weekly usage burn appears to have stabilized noticeably. It is still early to say whether the underlying issue is fully fixed, and I do not have an official confirmation from OpenAI about what changed, but based on my own observations the behavior is now much closer to normal than it was after the June 4 reset/update.
I also want to acknowledge the one-time request-limit reset that appeared in the app. Thank you to the OpenAI team for providing that compensation mechanism.
I think it is important to say this clearly: users should criticize regressions when they happen, but we should also acknowledge improvements when they appear. If OpenAI did make a server-side or client-side correction here, it is appreciated.
That said, it would still be very helpful to have an official clarification on what happened around June 4, whether the metering/quota behavior was changed or fixed, and whether affected users can expect the current behavior to remain stable.