About Tibo's Resets
A Historical and Quantitative Look at GPT Quotas
Author’s note: I am a Chinese-speaking user. The original essay was written and published in Chinese. I translated and lightly adapted this version for an English-speaking audience while preserving its argument, tone, formulas, and source structure as closely as possible.
Over the past few months, Tibo has pressed the reset button many times.[14]
Not long after I had confidently said that Tibo probably would not reset the limits again, he did exactly that. On August 8, he reset the usage limits for all paid ChatGPT Work and Codex users, then promised another “performative reset” on Monday.[1]
The community reaction was a little strange. People had gone from jokingly summoning resets to producing a few dissenting voices. Some had exhausted their quota that very day and thought the timing was perfect. Some had only used 2% or 3% since their natural reset. Others had already been sitting at 100%, only to be “reset” from 100% back to 100%.[12]
The complaints became visibly louder. Several groups were describing different experiences, and all of them were telling the truth. So the jokes slowly turned into an argument.
Someone invoked the old Chinese fable Morning Three, Evening Four to get at the nature of the reset.
Then came the counterargument: if OpenAI is giving away free quota, complaining about it seems a little ungrateful. Others pulled out plan prices, current balances, and reset dates, arguing that it was not a pure gift at all and might even push back a natural reset that was about to arrive.
Now this is interesting. The moment a dissenting voice appears, thesis, antithesis, and synthesis suddenly invite us to think about what the thing actually is.
As usual, I instinctively wandered over to the opposition. I started with the same arithmetic. Divide a weekly quota by seven to obtain a daily amount. Count how many days the natural reset was delayed. End with either a positive number or a negative one.
The more I calculated, the more I felt that the problem was not really arithmetic.
The trouble is that a quota is not one single thing. For someone like me, who can burn through a full week of Pro 20x in a day, I plainly benefit from a reset. Someone with much lighter demand may feel absolutely robbed.
OpenAI does not describe Plus as a plan for using Codex a fixed number of times each day. It describes it as suitable for a few focused sessions each week. OpenAI also says that actual consumption varies with the model, task size, context, reasoning effort, tool calls, and caching. Two apparently similar tasks can therefore consume very different amounts of quota.2
Those two facts open a gap between the way people imagine quotas and the way AI is actually used. Most people’s experience confirms it. When there is no project, Codex may sit untouched for days. Then a refactor, a pile of documents, or a delivery deadline arrives, and an agent may run continuously for hours.
If we look only at the balance and calculate gains or losses in quota units, we quietly import a strange assumption: every user ought to consume one-seventh of the quota every day, and failing to eat today’s share means losing it.
Real-world AI use is not that tidy.
So I changed the question. Instead of asking how much one unit of quota is worth, I asked whether the work a user had planned before the reset could still be completed after it.
I also went looking in history for an earlier form of the same problem—something that would let us discuss quotas and resets in a more useful conceptual setting.
I found options. They are a good entry point, but only an entry point.
Options, Commitment Lines, and Allocation Rules
Modern standardized options markets often treat 1973 as a landmark year. The Chicago Board Options Exchange began trading listed options with standardized expiries, strike prices, and rules, moving the product away from purely bilateral, bespoke agreements.[4]
The basic structure of an option is simple. The buyer acquires a right, not an obligation. The buyer may purchase or sell the underlying asset within the agreed period—or never exercise at all.[5]
This is useful for thinking about AI quotas.
Not using a quota does not necessarily mean wasting it. If there is no suitable task for Codex today, preserving the capacity may be more rational than inventing something trivial to burn it on. The user is not waiting for model performance to rise. The user is waiting for a task worth calling compute for.
Codex quota is, of course, not a financial option.
There is no tradable underlying asset, no clear strike price, and no transferability. Feeding the supposed dollar value of the remaining 70% into Black–Scholes would not produce a credible price.
A standard option also tends to focus on one exercise, while AI use usually consists of many calls.
This is where swing options in energy markets come closer.
Swing options begin with a simple observation: demand for natural gas and electricity does not remain constant every day. A buyer may know roughly how much gas will be needed over a winter, without knowing which days will bring a cold snap or when a factory will suddenly raise output.
A swing contract therefore allows the holder to adjust withdrawals multiple times during the contract period, while remaining subject to daily quantity limits, a total quantity cap, and an exercise-count limit. The literature treats it as a multi-exercise contract with quantity constraints.[6]
That resembles the way Codex is used.
Users do not know when tasks will arrive. They can make repeated calls within short-term windows and weekly limits. The platform grants some flexibility, but cannot allow any single account to consume unlimited shared compute.
Swing options still do not explain everything.
Some users rarely hit the limit. Some go an entire week without using it. What exactly did they buy? I doubt this group is small. Some people subscribe because AI is fashionable, some out of curiosity, and some simply become busy with something else. More importantly, many do not have a steady stream of tasks but still want the ability to use the service immediately when real work appears.
I wanted a model complete enough to describe the quota itself before moving on to the reset.
That led me to committed credit lines.
US banking developed loan commitments and revolving credit facilities long ago. A bank promises to keep funds available for a specified term, and the company draws only when it needs them. A 1975 Federal Reserve Bank of Richmond review noted that formal commitments often charged a fee on the unused portion. Even if the client never drew the money, the bank could retain the fee because it had to maintain lending readiness throughout the term.[7]
If a company secures a ¥100 million credit line and never draws it, we do not say that the company “lost” ¥100 million. What it bought was the ability to obtain liquidity immediately if cash suddenly became tight, rather than having to look for a bank after the crisis had already begun.
Low-frequency AI subscribers may be doing something similar.
A high remaining balance does not necessarily mean the right is unimportant. It may mean the user deliberately preserved the capacity for later.
There is one final layer: allocation.
OpenAI expressly distinguishes a rate-limit reset from usage credit. A reset does not create a cash balance, an API balance, or a transferable credit. Codex is also governed by a shared five-hour window and additional weekly limits.2
Quota is therefore not a bucket of tokens already delivered to the user. It is also an admission rule for shared compute. The user can call the service within the rules; the platform manages load through windows and caps.
At this point, the model is more or less complete.
Options explain why timing has value. Committed credit lines remind us that non-use does not mean no service was received. Swing contracts fit repeated, bursty calls. Allocation rules explain why the platform needs windows and limits in the first place.
From this perspective, AI quota is best understood as a task-triggered service capacity.
The user pays a subscription fee and receives a limited amount of callable capacity during a period. When tasks arrive is determined by the user’s work. When capacity is replenished and how much can be used at once are determined by the platform’s rules.
That is much closer to reality than a bucket of tokens evaporating by one-seventh each day.
Modeling a Reset Through an Option-Like Lens
Let the user’s future tasks be modeled simply.
Suppose task j is written as:
where t_j is the time at which the task arrives, c_j is the quota it consumes, d_j is its deadline, and v_j is the value produced by completing it.
That value need not be revenue. It may be time saved, an on-time delivery, a production incident fixed, or simply a personal project finished. Whatever—the model only needs a workable value term.
Collect all future tasks into \omega.
A quota rule R determines which combinations of tasks can be completed. Writing and coding clearly do not have identical workflows, and actual use may involve combinations of models and tools. We simplify all feasible combinations into:
The maximum task value available under rule R is:
where x_j=1 means task j is completed and x_j=0 means it is not.
This formula is not intended to calculate damages for every subscriber. It changes the object of analysis.
Previously, everyone stared at the balance and asked how much was left.
Now the question becomes: under the current quota calendar, which worthwhile things are still possible?
If there is no task today, the immediate marginal value of quota may be low. If a project is halfway through and quota suddenly becomes the bottleneck, the same unit may be extremely valuable. Dividing the monthly subscription by four and then by seven cannot capture that variation.
Now introduce the reset.
Let a full-period quota be Q, and let the user currently have q remaining. The original natural reset date is r. After Tibo’s reset, the new replenishment date is r’.
Before the reset, the state is:
To separate the two effects, introduce an imaginary intermediate state. Suppose the platform replenishes the current balance to full but leaves the original reset date unchanged:
The actual state after a hard reset is:
The total change created by the reset can then be decomposed as:
In the first bracket, the reset date is unchanged and only the current balance moves from q to Q.
This is the top-up effect.
A user at zero receives almost a full period. A user with 80% remaining receives only the 20% already consumed. A user already at 100% receives nothing from this component.
In the second bracket, current capacity is still the full Q, but the next replenishment time changes from r to r’.
This is the calendar-shift effect.
A top-up will generally not make the user worse off. A calendar shift can. Its direction depends on when tasks arrive.
OpenAI’s official explanation of a banked reset is clear: redeeming it restarts both the five-hour and weekly windows, and the next weekly reset moves to approximately seven days after redemption. For global resets initiated by the platform, OpenAI Support has explained that the new seven-day window may begin when the user next uses Codex, so the date shown in the interface can continue moving. Support also acknowledged that the display makes planning difficult. In another response, a global reset was described as a fresh allocation replacing the prior period and its remaining balance.3[10]
That is why “restored to 100%” is easy to misunderstand.
It combines a top-up and a calendar shift in one operation.
Suppose the user has 0.8Q remaining and would naturally reset in two days. Today the account is restored to Q, and the next replenishment is moved to seven days later.
The interface says the balance moved from 80% to 100%.
The model says the user received a current top-up of 0.2Q, while the reset that was due in two days was replaced with a different calendar. The first component is positive. The second depends on later tasks.
Take a simple example.
The user currently has a full quota Q and would naturally reset on day 3. Tibo performs a hard reset today, moving the next reset to day 7. Each large task requires 0.8Q.
Under the first task path, task A arrives on day 2 and task B on day 4.
Under the old calendar, the user completes A on day 2, naturally resets on day 3, and completes B on day 4.
Under the new calendar, A leaves only 0.2Q on day 2. No reset has arrived by day 4, so B cannot be completed.
Now change the path.
Task A arrives on day 6 and task B on day 8.
The old calendar reset on day 3 and would not reset again until day 10. After A consumes 0.8Q on day 6, B cannot be completed on day 8.
The new calendar resets on day 7, allowing both tasks to be completed.
The same reset produces opposite outcomes under the two task paths.
That is not a contradiction in the model. The quota calendar interacts with task timing.
Tibo changed that interaction.
If we want to call an activity a pure gift, we can impose a stricter condition.
Let the task combinations feasible under the old rule be \mathcal{F}_{\mathrm{old}}(\omega) and those feasible under the new rule be \mathcal{F}_{\mathrm{new}}(\omega).
A change that only expands user choice should satisfy:
No matter how tasks arrive, everything feasible under the old rule remains feasible, and the new rule merely adds possibilities.
Keeping the original reset date while adding a separate bonus bucket would largely meet that test.
A banked reset comes closer as well. If the user does not redeem it, the original calendar remains in place. The user shifts the calendar only when the balance, task, and timing make it worthwhile. OpenAI’s mechanism does indeed require the user to redeem a banked reset rather than applying it automatically.3
A hard reset provides no such choice.
It opens some paths and closes others. That does not mean every user is harmed, but it does mean the operation is not purely additive across all possible task paths.
Four Cases
Once the object of analysis is clear, the community’s different claims fit into a very ordinary table.
Choose a bundle of tasks the user genuinely intends to complete and ask two questions:
Can it be completed under the old calendar?
Can it be completed under the new calendar?
Each question has only two answers, so together they produce four cases.
The first case is common among genuinely light users.
They do not approach the limit, or their tasks are small. Whether the reset falls on Wednesday or Sunday does not change what they want to do. It therefore makes little sense to say that moving the date by four days automatically destroys four-sevenths of their quota.
The second case is where a hard reset receives the most gratitude—which is basically my own case.
The user has hit the limit while the work is unfinished. Under the old rule, the user must wait or buy credits. Tibo presses the button and the work can continue. After the August reset, some community members said they had exhausted their quota that very day and found the timing excellent.[12]
The third case is the stronger form of the loss argument.
The user did not merely “lose a few days” in the abstract. The user had scheduled two stages of work around the original reset. Both were feasible under the old calendar; the second is blocked under the new one.
The fourth case is more common among users whose demand greatly exceeds the plan.
The task remains impossible with or without the reset. The hard reset may provide a few extra hours, but the user still needs credits, an API workflow, a plan upgrade, or another service.
The point of the four cases is not that the table looks complete. It prevents two overgeneralizations.
Moving from 100% to 100% does not prove that nothing changed, because the future calendar changed.
Moving from 100% to 100% also does not prove a loss, because the user may never approach the boundary.
The task still has to be put into the model.
User States
Users can also be classified by state. My first instinct was to divide people into the diligent and the lazy.
Someone who empties the quota every day is “diligent”; someone who opens Codex twice a week is “lazy.” That classification matches the arithmetic that divides quota by days.
But it quietly assumes that more usage is always better and a higher utilization rate is always more rational. Burning tokens on meaningless work does not create value. It is not as though we are taking revenge on OpenAI—unless it turns truly feral one day, in which case perhaps we can revisit the idea.
The more useful criterion is how work arrives.
On that basis, we can roughly distinguish project-based users, continuously high-frequency users, and automated users.
Project-based users may leave Codex untouched for days, then run it heavily before a delivery. They are highly sensitive to the location of the reset point. A reset that falls between two project phases can be extremely useful; the same reset applied a few days earlier may erase that alignment.
Continuously high-frequency users regularly approach the cap, so the top-up component tends to be more valuable to them.
Automated users go further. Once they know a reset is coming, they can keep agents running, consume the current quota quickly, and begin again with the new period. They are best positioned to realize the activity’s nominal value.
Community discussions also classify users by plan. The same framework can absorb that distinction: a plan simply draws another boundary around the usage paths.
OpenAI currently offers Free, Go, Plus, and Pro individual plans. Free is for quick tasks; Go costs $8 per month and is aimed at lightweight tasks; Plus costs $20 per month; Pro begins at $100 per month and offers 5x or 20x the Plus usage capacity.[2]
Tibo’s announcement covered all paid users, so Free was outside the stated scope.[1]
Go and Plus are more likely to exhibit bursty use. Plus is officially framed around several focused sessions per week rather than constant daily consumption. A user may benefit from one hard reset and be harmed by another that disrupts a project scheduled around the old date.[2]
Pro 5x and Pro 20x cannot be valued by mechanically multiplying the result.
A larger quota lowers the probability that ordinary tasks hit the boundary. A 20x user who never comes close to the cap may experience no practical effect from the calendar shift.
But a professional user who genuinely exhausts 20x may be working on a large codebase, long-running automation, or a commercial delivery. Once quota becomes binding, the conditional task cost may be much higher.
A rough expression is:
As the plan grows, the first term often falls.
As the professional workload grows, the second may rise.
Those forces operate in opposite directions. A 20x capacity does not imply that every reset creates twenty times the benefit or loss of Plus.
The plan decides where the boundary is drawn. The task path decides whether the user collides with it.
Some people will also bring up relay services and account resellers, which appear frequently in community discussions. The same relation can roughly describe them. A Plus account in a reseller’s inventory may die before its quota is used, forcing the operator toward sustained, high-frequency consumption. That is not an ordinary end-user case, however, and it introduces a more complicated supply chain, so I will not pursue it here.
OpenAI’s Side of the Ledger
Has anyone calculated the platform’s side? The same model can be extended, but the arithmetic changes.
For comparison, convert the different plans into one common capacity unit.
Let user i have a full-period quota Q_i and a remaining balance q_i immediately before the reset.
If the publicity value counts every account as receiving “a full-period restoration,” the nominal scale of the activity is:
That number is large. Every paid account is counted, and Pro accounts are amplified by their higher capacity.
But the amount actually restored at the moment of reset is only:
A user at zero receives Q_i.
A user with 80% remaining receives 0.2Q_i.
A user already at 100% receives zero from the immediate top-up.
Even restored capacity is not necessarily consumed. We therefore need two counterfactual paths.
How much would this user have run without the reset?
How much additional use occurred because of the reset?
Over an observation horizon H, define that extra use as:
The plus sign means we count only usage added by the reset, not calls that would have occurred anyway.
If one insists on defining a capacity-redemption rate for the event, it is:
The ratio varies with the observation period, the distribution of pre-reset balances, and the timing of tasks. Outsiders do not have OpenAI’s account data, so we cannot calculate a credible number.
But the structure is clear.
“All paid users restored to 100%” describes the campaign’s reach.
How much had already been consumed determines the immediate top-up.
How much of that top-up is subsequently used is what begins to approximate the additional inference burden borne by the platform.
Tibo has said that Codex resets cost money. That can plainly be true in aggregate. Heavy users who were at zero and resume running agents impose real additional compute costs.[13]
But “the campaign costs money” does not mean every user received a full new period of service.
An account moved from 100% to 100% that still has no task may add almost no inference load.
An account moved from 0% to 100% and then run to exhaustion may redeem almost the entire nominal amount.
The campaign therefore covers everyone, but the cost is not distributed evenly across everyone. It is concentrated among users who had hit the boundary and can immediately work in the new window.
That is also why people burn quota before an announced reset.
Once Monday’s reset is known, the threshold for consuming today’s balance falls. Work that was not urgent can be run early. The earlier a user sees Tibo’s post, and the more easily the user can keep agents running, the more value the user can realize. Meanwhile, someone who has not opened Codex for days wakes up to find that 100% has once again become 100%.[12]
One might say that Tibo has discovered a rather modern form of marketing. Some community members go further and suggest that OpenAI is deliberately using low-frequency accounts to reduce promotional cost.
We do not have internal data and cannot infer motive from the outcome. I assume OpenAI’s internal actuaries are smarter than my back-of-the-envelope guesses.
I think only three conclusions are safe.
The campaign’s publicity scale, the capacity immediately restored to accounts, and the platform’s final incremental compute cost are not the same number.
Collapsing them into one produces claims such as “every subscriber received tens of dollars in tokens”—claims that sound precise but have no credible counterfactual basis.
Repeated Resets
Now extend the analysis from a single reset to repeated resets.
A new problem appears: users need to know when they will be able to work again.
OpenAI Support has said that after a global reset, a new seven-day window may begin with the user’s next Codex use, and acknowledged that the current display is difficult to plan around. Some community members have asked for a fixed weekly reset day; others track Codex and Claude Code in spreadsheets. Others have complained that understanding the calendar of a paid product should not require watching a product lead’s X account.1[15]
Max Woolf counted six direct resets between July 9 and July 17, along with banked resets. To manage his quota, he kept the usage page open, set reminders, and began asking whether he should use the balance before the next reset.[14]
That cost is invisible in the quota balance. We can add two deductions to the earlier task-value model:
CE is the service value actually experienced by the user.
is the expected value of worthwhile tasks the user can complete.
captures outcome uncertainty, while \rho measures how much the user dislikes that uncertainty.
K is the cost of checking quotas, following announcements, rescheduling projects, and moving work elsewhere.
This is a simple way to place predictability inside the model.
Even if two systems offer the same average amount of quota, the one that repeatedly moves dates forces users to spend more effort planning. For someone experimenting casually, that may be a minor nuisance. For someone who has integrated Codex into production work, the calendar is part of the tool.
A phrase came to mind: “subscription is an arrogance.” From this angle, we can add a second half: “quota is a curse.”
The percentage in the interface continually reminds the user that something is shrinking, expiring, or about to be overwritten by the next reset. The user slowly stops asking whether a task has value and starts asking whether the quota can be fully consumed.
In the August discussion, one developer asked the question directly: if another reset is coming in a few days, should he run projects today that he does not actually need?[1]
That may be why the community argument raced so quickly toward division and subtraction.
History has seen the same behavior elsewhere.
A study of US federal procurement found that spending in the final week of the fiscal year was 4.9 times the weekly average for the rest of the year, and that IT projects initiated at year-end received significantly lower quality ratings. Once a budget is about to expire, projects that were not worth doing become easier to rush through before the money disappears.[16]
A government budget is obviously not an AI quota, and the scales are completely different.
The similarity is that whenever a resource takes a use-it-or-lose-it form, the user is encouraged to increase consumption, not necessarily output.
The platform may observe more token usage while the user completes no more valuable work.
A subscription is supposed to free the user from checking a price every time something is done. Quota installs a reverse meter inside the subscription. A taxi meter rises as it is used; an AI quota falls. Add irregular global resets, and the user can fear both running out and failing to use enough.
The emotional calibration is, it must be said, rather precise.
My Conclusion
After taking a long detour through options, swing options, committed credit lines, and allocation rules, I arrive at one basic point: the user buys the ability to call compute when tasks arise, within a limited period and usage cap.
Using the intuition of swing options to calculate and model the arrangement covers more real-world cases and exposes the two operations inside Tibo’s preferred hard reset. The platform replenishes what the user has already consumed and simultaneously reschedules the next replenishment date.
The first operation is valuable to a user who has reached zero. The higher the remaining balance, the smaller the top-up and the more important the calendar shift becomes. A person may be moved from 100% to 100%. On a simple monthly count, once there are more than four resets in a month, the user is necessarily ahead overall; July had already crossed that line. Even then, the new calendar is not automatically worse. The result still depends on whether later tasks align with the old calendar or the new one.
This perspective also explains the four cases. Both calendars may be sufficient, in which case the user is unaffected. Only the new calendar may be sufficient, in which case the reset genuinely helps. Only the old calendar may be sufficient, in which case the shift breaks the original arrangement. Or neither may be sufficient, in which case the reset merely loosens the constraint.
Different plans draw that boundary in different places, but they do not replace task-path analysis. The same person may be a low-frequency user this week and a high-frequency user next week because a delivery arrives.
The same logic works from OpenAI’s side. The bill cannot be estimated as “number of paid users multiplied by one full quota.” Restoring everyone to 100% is the campaign’s publicity scale. The amount immediately restored depends on how much users had already consumed. The extra compute cost depends again on whether those restored units are actually used.
It is therefore a campaign with a very large face value, while most of the realized value goes to users who had already hit the limit and can immediately continue. A high-balance account with no task experiences the same visible reset, but the platform may bear almost no additional cost. That does not prove OpenAI is calculating against anyone. It only shows that “how large the campaign looks” and “how much is actually delivered” are different questions. I do not support crude numerical claims; the relevant internal data are unavailable.
OpenAI has bills to pay too. From a marketing perspective, the resets have plainly been successful.
Once a single reset becomes a sequence of resets, the issue grows more complicated. It gradually shifts from how much quota exists to whether the rule can be predicted.
Users must remember the old date, watch temporary announcements, and worry that the current balance will be overwritten by the next reset. At that point, quota begins to influence when users work and may induce them to run tasks they would not otherwise run.
From this perspective, a banked reset is more reasonable than a hard reset—not because it creates twice as much compute from nowhere, but because the user can wait until a real task arrives before deciding whether to shift the calendar.
My conclusion is therefore neither “every reset harms users” nor “a free reset can only be a gift.” It is a quota operation whose result varies with account state and task timing.
For some users it is a genuine remedy. For some it changes almost nothing. For others it damages an existing work plan.
To decide what a reset means for a particular user, place the old calendar, the new calendar, and the work the user intended to complete on the same timeline.
A Final Note on Breach of Contract
I want to end by addressing the breach-of-contract claim.
It is too quick, in my view, to say that every hard reset is a breach.
OpenAI does not promise a fixed number of tokens as the plan entitlement. As the company repeatedly explains—and as I have repeated here—actual consumption depends on the model, context, reasoning effort, and tool use. A rate-limit reset is also not cash or transferable credit.2[8]
So a claim that divides a weekly quota by seven and says the platform took four days’ worth of tokens rests on a weak foundation. The user did not buy a stored-value asset delivered in equal daily installments.
For proving loss, the task-path analysis is stronger.
Under the old calendar, the user had a workable plan.
Under the new calendar, that plan became infeasible.
The user therefore bought additional credits, switched services, delayed delivery, or lost a natural reset that would otherwise have occurred inside the paid subscription period.
The community has already produced a timeline of this kind.
One user said that on July 14 the account had 77% remaining and was scheduled to reset on July 19. On July 15 it was restored to 100%, while the next reset moved to July 21. Because the subscription ended on August 10, the user calculated that the final reset originally due on August 9 moved to August 11, beyond the subscription period. This is a user report rather than an account-level record, but it presents a loss path that can be verified.[17]
There is no need here to assume that the user was entitled to one-seventh of a quota each day.
Confirm the old date, the new date, and the subscription end. That is enough to determine whether a usage window that would have fallen inside the paid term was moved outside it.
A breach claim is not impossible under this framework. It still depends on how the purchase page described quota, whether the user genuinely had the relevant demand, whether notice was given, and whether the loss can be proved.
Personally, I do not see much point in pursuing legal responsibility when no actual loss can be shown.
There are, however, better product designs. If a reset is compensation, the platform can preserve the natural reset date and place the additional capacity in a separate reward bucket. If the seven-day window must restart, it can issue a banked reset and let the user choose when to use it.
Before activation, the interface should at least show the current balance, the amount actually restored, the old reset date, and the new date after activation.
Suppose the user has 83% remaining and is scheduled to reset on Wednesday. The interface could simply say: this operation will restore 17% and move the next reset to next Monday. The user can activate it immediately or save it.
At that point, the community probably would not need options, credit lines, swing contracts, and a page of formulas to work out what happened.
The next time Tibo presses the account back to 100%, everyone would at least know whether that 100% was added to the original calendar or whether the calendar was quietly replaced as well.
Nothing annoys a development cycle more than someone moving its dates around.
Unless otherwise stated, the text and author-created diagrams in this article are released under the CC BY-SA 4.0 International license.
Republishing, adaptation, and commercial use require appropriate attribution, a source reference, and disclosure of modifications. Adapted works must use the same or a compatible license.
Third-party images, trademarks, quotations, and separately credited materials are not covered by this license.
AI tools were used to assist with image generation, language localization, and formatting. The analysis and final written content are the work of Fang Han.
References
[1] OpenAI Developer Community, “Codex rate limits reset for all paid plans on August 9 and again on Monday,” discussion beginning August 8, 2026.
[2] OpenAI, “Pricing | ChatGPT Learn,” accessed August 13, 2026.
[3] OpenAI Help Center, “Using Codex with your ChatGPT plan,” accessed August 13, 2026.
[4] Cboe, “The Creation of Listed Options at Cboe,” March 1, 2024.
[5] FINRA, “Options,” accessed August 13, 2026.
[6] Patrick Jaillet, Ehud I. Ronn, and Stathis Tompaidis, “Valuation of Commodity-Based Swing Options,” accepted for publication in Management Science, December 2003.
[7] Bruce J. Summers, “Loan Commitments to Business in United States Banking History,” Federal Reserve Bank of Richmond, Economic Review, September–October 1975.
[8] OpenAI Help Center, “ChatGPT Desktop Referral Promotions,” accessed August 13, 2026.
[9] OpenAI Developer Community, “Questions about an unexpected Codex usage reset and new quota period,” discussion beginning June 4, 2026.
[10] OpenAI Developer Community, “Weekly limits reset date suddenly changed,” discussion beginning October 31, 2025; the article cites an OpenAI Support explanation posted in 2026.
[11] OpenAI Developer Community, “Flexible Rate Limit Resets for Codex and a method to get a Reset,” discussion beginning June 12, 2026.
[12] Reddit r/codex, “Tibo just reset,” August 2026.
[13] OpenAI Developer Community, “Codex Rate limits reset for all paid plans April 28, 2026,” April 28, 2026.
[14] Max Woolf, “What’s the deal with all the random weekly quota resets for agents lately?,” July 18, 2026.
[15] OpenAI Developer Community, “RANDOM Codex weekly quota reset still happening. WHY?!?,” discussion beginning June 29, 2026.
[16] Jeffrey B. Liebman and Neale Mahoney, “Do Expiring Budgets Lead to Wasteful Year-End Spending? Evidence from Federal Procurement,” American Economic Review, vol. 107, no. 11, November 2017, pp. 3510–3549.
[17] Dragonrin, OpenAI Developer Community, “The ‘Free’ Non-Banked Codex Reset May Have Reduced My Total Usage,” discussion beginning July 14, 2026.