Repository navigation
Make Weekly Limit Reset Deterministic #9508
Description
What version of Codex is running?
v0.87.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.2-codex
What platform is your computer?
MacOS
What terminal emulator and version are you using (if applicable)?
Ghostty
What issue are you seeing?
Weekly Reset clock should start as the /status implies and not as the time of the first prompt after the blackout period
What steps can reproduce the bug?
Uploaded thread: 019bce1a-64e5-7283-862e-6198c417eee9
What is the expected behavior?
Weekly reset data/time should be scheduled and deterministic and not based on first prompt after the blackout period
Additional information
No response
Activity
[-]Weekly Limit Reset Timing Issue[/-][+]Make Weekly Limit Reset Deterministic[/+]conqueror commentedon Jan 20, 2026
Thanks for filing this. I took a quick look at the CLI code path:
/statusjust displays thereset_attimestamp returned by the backend rate‑limit snapshot (from/usage); the client doesn’t compute its own schedule. So if the reset time is currently tied to the first request after a blackout, the most correct fix likely needs to be backend‑side.If a client‑side mitigation is acceptable, we could display a deterministic weekly reset once we know the intended anchor (e.g., Monday 00:00 UTC), possibly using
limit_window_seconds+reset_after_secondswhen present — but that wouldn’t change actual enforcement.A few questions to clarify before proposing code:
Happy to draft a concrete proposal once we have those answers.
SamuelMcAravey commentedon Apr 2, 2026
I'm also affected, and this is not just confusing UX. it causes loss of paid included usage.
In my case, my weekly usage showed about 20% remaining with a reset due in a few hours. Based on that, I let several unattended prompts continue running specifically to use the rest of the current window. The next morning, the reset had occurred in a way that caused those in-flight prompts to consume the newly reset weekly allowance instead. The result: I effectively lost the unused portion of the prior window and started the new window already reduced to about 80%.
That is not a neutral reset. It changes real paid usage availability.
What I'm asking for:
gsusI commentedon Apr 4, 2026
Early adopter and long-time Pro subscriber here.
While I understand that you may be trying to help people who are not closely managing their token consumption (and score some points in the Twitter wars), for those of us who are very aware of it and ration our usage throughout the week, these arbitrary resets derail that planning.
For example, last week, when the limits were reset, I had been very conscious of my usage at the beginning of the week because I had deadlines coming up and work that needed to be done towards the end of the week. I wanted to make sure I had enough credits available to use more heavily when needed, so with 3-4 days left in the week, I had intentionally kept around 70% of my weekly tokens available. That would have allowed me to make serious progress.
Instead, the limits were reset. Because I now have uncertainty about what my workload may look like in the remaining days of this week, I cannot afford to consume tokens heavily right now because I might run out before the week finishes, even if I deliberately used fewer credits in the days before the reset.
So while I do appreciate that you are trying to be helpful, please make sure that this does not negatively impact those of us who are planning our token usage properly. Perhaps the reset should not be global, but only apply to those who would benefit from it.
grzegorznowak commentedon Apr 8, 2026
As I mentioned in my now-closed-as-duplicate thread, I would appreciate if unused credits would roll over to next periods when there's a reset.
Heck it would be nice if they could roll over to following period always - we only need it to roll once , so that the last 10% of usage isn't the tug of war between optimizing the usage and not being locked out.
gsusI commentedon Apr 8, 2026
This is VERY annoying.
I had saved a 28% weekly usage for today (the reset was due tomorrow), and now I have to eat into next week's allowance.
30 remaining items
sfilargi commentedon May 23, 2026
@etraut-openai how is this an enhancement and not a bug?
rkunnamp commentedon May 23, 2026
When Claude resets , they keep the weekly reset time unchanged, which is actually what is expected.
The way codex currently does quota reset ends up actually punishing majority of the users , and is not exactly acting as a compensation.
rocky-m commentedon May 23, 2026
Like others, I track my 5hr, daily, and weekly quotas to make sure I allocate enough usage for heavy days. Random resets are taking away from users like us. Either give us an option to opt out of the reset, or reset usage without changing the reset date. The first few times was tolerable, but it's happening every week now and is disrupting our workflows.
ebarti commentedon May 24, 2026
It says that they may reset limits when new features are added... so I assume this reset would apply to anyone, no? When were your limits reset? I noted a few of my latest resets:
May 17
May 19
May 23
Non-sensical - none of those days correlates with any event in the changelog https://developers.openai.com/codex/changelog
jvanakker commentedon May 24, 2026
Well, rate limit resets are announced by Tibo (from OpenAI/Codex team) on his twitter account:
https://x.com/search?q=from%3Athsottiaux%20reset&src=typed_query
He also mentions reasons, so maybe this clears things up for people who didn't know.
jakeparkernet commentedon May 25, 2026
The issue that will arise is that customers are paying for an expected outcome. If that outcome is not predictable, we aren't getting what we pay for. Resetting in this way makes us lose predictability, and since Codex is likely going to be used by people trying to make money with it, predictability is profit. If, say, the limits were reset and the date did not change (i.e. we just randomly got boosted back up to 0% weekly limit used), that would be a win for us, but because the limit resets and the date changes, it raises vigilance in customers who would otherwise be more likely to keep paying for reliability.
jvanakker commentedon May 31, 2026
And another codex usage limit reset, confirmed on Tibo's X. In this case it was in my advantage.
wxx07 commentedon Jun 29, 2026
+1!! Within a single day, I watched my weekly limit reset time get inexplicably pushed back by over an hour (from "resets 14:25 on 6 Jul" to "resets 15:51 on 6 Jul"). Can anyone tell me why this happened? I believe that delaying the weekly limit reset time harms users' interests.
The-Cyber-Captain commentedon Jun 29, 2026
Probably the full reset Tibo mentioned on Twitter earlier today? This one has NOT been done under the recently implemented 'bank until later' system... presumably for technical backend and / or rollback reasons. Does that line up with what you're seeing @wxx07 ?
https://x.com/thsottiaux/status/2071381664853319742?s=20
DavidExploresAI commentedon Jul 12, 2026
Adding a July 1–13, 2026 data point from Asia/Shanghai. This closely matches the planning problem described in this issue.
This does not appear to be caused directly by installing a desktop app update. The weekly window was repeatedly replaced by server-side hard resets during the same period as the GPT-5.6 launch.
Environment
Timeline from sanitized local rate-limit records
All times below are Beijing time.
The July 13 transition occurred inside an active session and remained consistent across fresh sessions and a live
account/rateLimits/readrequest. It was not just a replayed historical snapshot.The rate-limit structure also changed.
Before the reset:
After the reset:
This matches the temporary removal of the 5-hour restriction announced during the same period.
Relationship to the public reset announcements
These changes line up with the public hard-reset announcements:
https://x.com/thsottiaux/status/2075452680760443190
https://x.com/thsottiaux/status/2075641131002700120
https://x.com/thsottiaux/status/2075820987833274448
https://x.com/thsottiaux/status/2076365965915467978
The app-update timing does not support the conclusion that installation itself triggered the resets. For example, version 26.707.31428 first launched after one of the weekly windows had already changed. Version 26.707.51957 was running for several hours while the old July 18 window was still active, and the server-side window changed later.
Impact
A hard reset benefits users who have already consumed most of their allowance. However, it can disadvantage users who intentionally preserve weekly capacity for work later in the displayed period.
When a nearly unused weekly window is replaced:
This is not a request for unlimited usage. It is a request for predictable and transparent quota accounting.
Requested improvements
I can provide additional sanitized
used_percent,window_minutes, andresets_atexcerpts if useful. I am not uploading complete session files because they may contain prompts and local workspace paths.saaranshM commentedon Jul 19, 2026
+1. A lot of the data is already there, it just isn't surfaced in the UI.
Every rollout under
~/.codex/sessionscontains arate_limitssnapshot with the currentused_percentand the exact epoch reset time for each quota window.I use those in an external tool I built (unsnooze) to show live usage percentages and schedule automatic resumes when the limit resets, and they've been consistently accurate. Because the reset time is already an absolute timestamp, there's no need to infer it from the human-readable banner.
https://github.com/saaranshM/unsnooze
mryellow commentedon Jul 22, 2026
I just used a reset to give me some credits after your bug ate them all, when I didn't need to because you randomly reset anyway to give back those bugged tokens.
Can't plan usage around this.
You need to remove the weekly limit UI until your backend accounting bug is fixed.
The quota system doesn't work. Either you use all your tokens in 3 hours, or you use them all in a week, or they all magically come back twice a week. There is no quota system. There is the illusion of a quota system. It's entirely broken and obviously does not scale.
gaandurian commentedon Jul 25, 2026
Please don't reset our time frames if you want to be kind, do the reset but keep our time frames, I had so much weekly usage left to consume in a couple of days (I used a limit reset credit for this) and I was excited about this. and all of a sudden I get hit with a reset that also resets the time frame. so, basically, I lost all my potential usage... this is extremely annoying to say the least, and it's not hard to fix this. so stop doing this! thanks.
taoyadev commentedon Aug 4, 2026
Since several people here are already hand-tracking these resets (personal logs of reset dates, checking Tibo's X announcements), I've been logging the observed/announced reset events in one place, each verified against the official announcement where one exists. A few patterns from the data so far, for planning purposes while the timing stays non-deterministic:
Full event log + a rough next-reset estimate: https://codex-reset.com/timeline
None of this replaces the actual fix requested in this issue — a deterministic, scheduled reset clock — it's just community-observed data to plan around in the meantime.