Make Weekly Limit Reset Deterministic

Thanks for filing this. I took a quick look at the CLI code path: /status just displays the reset_at timestamp 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_seconds when present — but that wouldn’t change actual enforcement.

A few questions to clarify before proposing code:

• What’s the canonical weekly reset anchor (day/time/timezone) you want? Monday 00:00 UTC? account creation time? plan cycle?
• Should this be a backend behavior change (preferred for correctness), or is a display‑only deterministic timestamp acceptable?
• Is the weekly window intended to be a fixed calendar schedule or a rolling 7‑day window?

Happy to draft a concrete proposal once we have those answers.

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:

1. Make reset timing deterministic and consistent with the displayed status/reset time.
2. Do not let a reset reduce previously available included usage.
3. If a reset happens mid-run, either preserve the prior window's remaining allowance or top up rather than reset.
4. For affected users, restore the lost included usage or provide equivalent credits.

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.

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.

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.

Agreed with @grzegorznowak. Just let the remainder roll over to the following period and drop this nonsense, please, @tibo-openai

4-5 requests this morning, and my weekly dropped by 5% (~$2.5)

Same requests in my $10/mo GH Copilot sub using the same model and effort, and with the same results would have cost me less than 5% of my monthly (~$0.5).

Until this is resolved, I'm switching to Plus and moving to GH Copilot.

<img width="722" height="294" alt="Image" src="https://github.com/user-attachments/assets/58f2d4d3-1a86-4b47-a7f2-e32be3df638b" />

These limit resets saved me a few times :)

This happened again today. To be clear, my objection is not to users getting extra quota. My objection is to the weekly reset boundary moving unexpectedly in the middle of active work during the week.

I plan usage around the reset time shown by the product. When that anchor moves without warning, the displayed reset stops being something I can rely on.

If OpenAI wants to give people extra usage, that is fine. But it should be additive, not a surprise reset that changes the accounting window underneath users who were intentionally saving capacity for later in the week.

Please keep the reset schedule deterministic or provide bonus capacity without moving the existing window.

These limit resets saved me a few times :)

It has that potential, yes. But for those of us who tend to be more conservative at the start of the weekly cycle and push harder toward the end, these resets have often resulted in lost token usage and disruption.

> These limit resets saved me a few times :) It has that potential, yes. But for those of us who tend to be more conservative at the start of the weekly cycle and push harder toward the end, these resets have often resulted in lost token usage and disruption.

Absolutely. Personally I utilize the left-over usage towards OSS projects and not being able to do it reliably is a huge pain. The rate of depletion is a different story but man has this been all over the place in recent months, I wouldn't even know where to start.
You are already feeding back to agents information about low level of tokens; couldn't you also feed us an information about about-to-happen-reset in X days/hours ?

I deliberately don't use fast mode, and I primarily use the 5.4-mini so that I'm running out of usage right at the end of the week.

When there are random resets like this in the middle of the week, not only do I lose the usage I was planning on, but also I feel like I'm getting punished for spreading out my usage and being conservative rather than trying to guzzle it down as fast as I can.

If I could, I would make use of the full 5.4 model and use it on fast mode. For example, if I knew that there was only going to be a reset that soon (i.e. no warning), then I obviously would have used my tokens faster on the full model, but I didn't.

The random resets make it incredibly difficult to use things predictably. I'm afraid to leave anything running for any long period of time. This last reset happened in the middle of the day, and the last one happened overnight causing my scripts to eat into the new week of usage unexpectedly. I'm losing out when there's a reset when I wasn't planning on it, because then I can't use the tokens faster on the better model. And I'm not able to plan out work for the week if things are going to be changing out from underneath me all the time.

I observed some weird behavior. I began some minor bug patching work at 80% weekly limit or so(at 19:00 or so), which was supposed to refresh at 4.17, and the 5 hour refresh time should take place at 00:00 tomorrow. After the work was finished, I was astonished to find that my weekly limit had gone down to 57%(which is very incredible in and of itself). What's more, my 5-hour limit was not showing, and my weekly limit refresh time has been postponed to 4.20.

This should mean that there must be a refresh at some point, and then I used 43 percent of my tokens from then on. But there's no way that this happened because then it should show in my 5-hour limit as well, since it is not even when my old 5-hour limit refresh time yet (so there's no way that it refreshed and disappeared).

This mean that openai basically canceled about half of my weekly usage out of nowhere. Please fix

I noticed the same thing and not only this. Sometimes I’d save my usage until the end of the week for a longer weekend session, but it just resets my usage several days before it is supposed to be reset, effectively taking away the availability of saved-up usage that I paid for. The following period is then several days longer, giving me less available usage per day.

But what I find even worse, when I run out of usage and have to purchase extra credits, my usage gets reset at the very last moment. So it’s really only resetting it if there might be a chance of me using a lot of it later during the week. It appears as if there is an intentional logic behind this. If this is done to every customer, that’s basically a hidden price increase to tweak some profit margins.

Again...

Yeah just faced the same issue. I had 3 days of usage remaining (with 60%) and now I'm at 100% with the deadline on 28th April

I’m running into the same issue and it’s honestly getting extremely frustrating. I use Codex for work, and these random weekly resets completely destroy any ability to plan my token usage. Today’s reset wiped out roughly 80% of my weekly allowance, and I had intentionally saved that usage for tasks scheduled later this week.

This isn’t just “confusing UX” — it directly affects paid usage and disrupts real workflows. If I’m paying for a quota, I expect that quota to remain stable and predictable. Right now it feels like the system can arbitrarily take away paid usage without warning, which is unacceptable for professional use.

Please, can someone from OpenAI comment on this or at least give us the option to disable these resets? Codex is marketed heavily for programming and business workflows, but these unpredictable resets are actively pushing me to consider switching to a competitor because it’s becoming impossible to rely on the tool for work.

A deterministic reset schedule or the ability to opt out would solve this. But the current behavior is genuinely disruptive.

Yeah just faced the same issue. I had 3 days of usage remaining (with 60%) and now I'm at 100% with the deadline on 28th April

Exactly the same happened here last night. Similar percentages and same dates.

For us Codex users, an unexpected limit reset like this can be temporary beneficial (when you're on the edge of the weekly limit with still a lot of work ahead), it can be equally worsen the situation like explained in many cases above. Especially if these unexpected resets are fine tuned to benefit OpenAI. Not claiming that's the case, but it just shouldn't happen at all.

@openai Please fix this!

And again the limits are reset (this time because Sam Altman tweeted about it).

Yesterday I had ~60% of the weekly limit available for use for today, and I've expected to have 14 hours today to use it up [based on the reset time listed in /status] - I'm not sure it would have been possible to use it up in one day, but I sure have expected that today's work will not use up the the next week's limit.

Instead I see that the weekly limit has been reset 14 hours ahead of time.
This does not seem reasonable.

UPD: used up 16% of a weekly limit in the first 5 hour session - without the 14h early reset would have likely used up 3/4 of the limit I had available before the reset, and would not have spent a part of the limit for the next 7 days.

Same complaint as others around folks who manage their quotas end up wasting when resets are random.
For my account, I had 50% remaining usage and 3 days (i.e May 14th when it was reseting). So managed my workload appropriately.
Suddenly I see that my weekly limits reset today - now I have used 14% for the day from my weekly limits (and have 36% remaining weekly usage). And now I'm out of my 5 hour limit.

So this is literally wasted tokens that I'm paying for.

Facing this issue since last month. And just happened again!

Faced the same issue. Weekly limit got reset a day before with still 13% remaining usage left. This is not fare.

I can confirm, I still had 24% of my limit left to use, and suddenly the refresh went off. Today I'm implementing the new limit, so I lost that 24%

I faced the same issue yesterday, I had an expected weekly reset scheduled for May 20th, and was consciously saving some tokens for monday, and a sudden reset messes up with my planned week usage. At least let me keep the non-used % of my previous session limit.

ditto... maybe consider something more measured than just resetting everyone, it's a bad look.

This is just OpenAI being sneak.

Some serious BS with limits. 2 days ago had a limit , about 70% until 19th, Yesterday had limit reset to 100% until 20th , or 21st, today it's until 24th at 51% only. At this point it seems random to me.

Yes! At least LET ME OPT OUT OF THIS GENEROSITY.

Agreed. I’ve seen the limit get reset whenever the daily burn rate is below 100/7%, which works in OpenAI’s favor. On the other hand, whenever I was above that burn rate, the limit was not randomly reset. This is BS.

ebarti. Very good analysis. It happend to me multiple times. I now have a codex-keepalive scheduler running which already opens my 5h windows 5 minutes after the 5 hourly reset with a short ping. I am thinking about making that smarter and implement there the daily use with configurable <7 %.

I think in the end its just cat mouse race... against openai which we will loose anyhow ;-). Even pushing it further and make a job queue instead of the ping where gpt-5.4-mini is used to do reoccuring tasks reviews and so on, find TODOs, run linter etc....

How about making actual usage cap at 200%, with weekly or irregular updates giving you +100%? That way regular users aren't penalized by irregular updates if they monitor, they'll just see their cap go from e.g. 70% to 170% and manage their tokens appropriately from then? Making a hard limit of 200% will also prevent people from accumulating too much via inactivity.

@etraut-openai how is this an enhancement and not a bug?

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.

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.

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

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.

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.

And another codex usage limit reset, confirmed on Tibo's X. In this case it was in my advantage.

This does not solve the backend reset/accounting behavior, but I hit the same planning problem from the user side: if reset timing and 5h state are unclear, long Codex runs become hard to schedule.

I open-sourced a small macOS companion for that workflow:
https://github.com/tristan666666/agent-island

It keeps the usage/reset state visible in the MacBook notch, shows Claude/Codex session state (running -> breathes, waiting for you -> spins, stuck -> red + beep), and can auto-resume a selected long session when it can continue.

Sharing as a workaround/status layer only; the underlying reset determinism still belongs in Codex.

+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.

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

<img width="904" height="748" alt="Image" src="https://github.com/user-attachments/assets/4b505dac-457d-4857-a9b3-2e64857b9dd1" />

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

• Platform: macOS 26.5.1, Apple Silicon
• Time zone: Asia/Shanghai (UTC+8)
• Desktop versions observed:
• 26.707.31428
• 26.707.41301
• 26.707.51957
• Bundled Codex app-server version: 0.144.0-alpha.4

Timeline from sanitized local rate-limit records

All times below are Beijing time.

| Observation | Weekly reset timestamp | Weekly usage |
|---|---:|---:|
| July 1–7 window | July 7, 10:00:45 | Reached approximately 96% used before the normal reset |
| Normal new window on July 7 | July 14, 10:01:09 | Approximately 3% used at the last observation |
| Window replaced on July 10 | July 17, 19:45:52 | Reset to a new weekly window |
| Window replaced again on July 11 | July 18, 01:26:43 | Reset to another weekly window |
| Window replaced again on July 11 | July 18, 14:11:59 | Reset to another weekly window |
| Old window last observed on July 12 at 23:57 | July 18, 14:11:59 | 76% used, approximately 24% remaining |
| New window observed on July 13 at 03:08 | July 20, 03:08:30 | Reset to 0% used |

The July 13 transition occurred inside an active session and remained consistent across fresh sessions and a live account/rateLimits/read request. It was not just a replayed historical snapshot.

The rate-limit structure also changed.

Before the reset:

primary: 300-minute window
secondary: 10080-minute weekly window

After the reset:

primary: 10080-minute weekly window
secondary: null

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:

• July 10: two additional resets were announced for Codex and ChatGPT Work:

https://x.com/thsottiaux/status/2075452680760443190

• July 11: one reset was confirmed and another was announced:

https://x.com/thsottiaux/status/2075641131002700120

• July 11: another reset was announced to land within 30 minutes:

https://x.com/thsottiaux/status/2075820987833274448

• July 12/13: another usage update and reset occurred:

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:

• the unused allowance does not roll over;
• the displayed weekly deadline moves forward;
• users must begin consuming the new week's allowance earlier than planned;
• the previously displayed reset date can no longer be relied upon for planning;
• banked reset credits may become difficult to use efficiently before they expire.

This is not a request for unlimited usage. It is a request for predictable and transparent quota accounting.

Requested improvements

1. Keep the ordinary weekly reset anchor deterministic.
2. Apply promotional or incident-compensation usage additively instead of replacing the active weekly window.
3. Alternatively, issue a banked reset that the user can apply on their own schedule.
4. Show a reset-event record containing the exact timestamp, reason, and affected quota windows.
5. Display the exact local expiration time instead of only a calendar date.
6. Avoid allowing a forced reset to reduce the practical value of unused included usage or expiring banked resets.

I can provide additional sanitized used_percent, window_minutes, and resets_at excerpts if useful. I am not uploading complete session files because they may contain prompts and local workspace paths.

+1. A lot of the data is already there, it just isn't surfaced in the UI.

Every rollout under ~/.codex/sessions contains a rate_limits snapshot with the current used_percent and 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