Your Codex weekly meter is down to 20%. A saved full reset is available, and the usual refresh is tomorrow. It looks like an easy button to press. Then you notice what happens to the date:
Available now20% → 100%
Next weekly refreshTomorrow → about a week from now
You get the 80% you have used back today. Tomorrow’s refresh, however, moves out of reach.
The date moves with the meter
A full banked reset refreshes Codex’s five-hour and weekly limits. OpenAI says it also changes the weekly reset date. If you resume using Codex right away, the next refresh could be roughly a week away. You do not get the original refresh tomorrow as well. That second line on the usage screen matters.
Since you can keep a banked reset until it expires, you have a choice about when to use it.
Put a price on the timing
I wanted a way to compare those two changes. Take a $200 monthly subscription as an example: seven days come to about $46. For this exercise, I treat all $46 as the value of the weekly allowance. The subscription includes more than that, so this is a yardstick, not a refund calculation.
The table adds the allowance you get back and subtracts the time you lose before the next refresh. If you have used 80% and the original refresh is three days away, the score is about +$11. At 40% used, with the same three days left, it is −$8. Both resets fill the meter, but one gives back much less. The opening case, 80% used with a refresh due tomorrow, comes out at −$3.
| Days until original refresh ↓ Allowance used → | 0% | 20% | 40% | 60% | 80% | 100% |
|---|---|---|---|---|---|---|
| 7 days | 0 | +9 | +18 | +28 | +37 | +46 |
| 6 days | −7 | +3 | +12 | +21 | +30 | +39 |
| 5 days | −13 | −4 | +5 | +14 | +24 | +33 |
| 4 days | −20 | −11 | −1 | +8 | +17 | +26 |
| 3 days | −26 | −17 | −8 | +1 | +11 | +20 |
| 2 days | −33 | −24 | −14 | −5 | +4 | +13 |
| 1 day | −39 | −30 | −21 | −12 | −3 | +7 |
| 0 days | −46 | −37 | −28 | −18 | −9 | 0 |
The table rounds price-based scores to whole dollars. The scores do not estimate cash saved. The −$46 and +$46 corners are mathematical limits; you may not be able to use a reset in those conditions. On a narrow screen, scroll the table sideways.
Try your own timing
Enter the days until your ordinary weekly refresh and the share of your weekly allowance already used.
Reference score
80% used; 3 days until refresh.
The score compares timing. It does not estimate money saved.
How the $46 table is calculated
Using an average month of 30.44 days, seven days of a $200 subscription is $200 × 7 ÷ 30.44 ≈ $46. The table treats that entire $46 as the weekly allowance’s reference price, an allocation I chose for this comparison.
Let c be the fraction of the weekly allowance already used, and d the days until its original refresh. If a full reset moves the next refresh to seven days from now, the old date is postponed by 7 − d days. The model subtracts one-seventh of the $46 reference for each day moved:
Reference score = $46 × [c − (7 − d) ÷ 7]
With 80% used and three days left, that is $46 × [0.8 − 4 ÷ 7] ≈ +$11. With 40% used and the same three days left, it is about −$8. The weekly allowance does not arrive one-seventh at a time; that daily adjustment is a way to compare timing across a seven-day period. If the next refresh date stays unchanged, the adjustment is zero.
Would I use the reset now?
The pattern in the table is clear: the score rises when you have used more of the weekly allowance and the original refresh is farther away. If the meter is empty, resetting six days early scores about +$39. Resetting one day early scores about +$7.
On a busy week, I would consider a saved reset if I needed the capacity and had an eligible limit. I would not burn through work just to improve a number in a table. If my normal refresh were tomorrow and the work could wait, I might save the reset for a later deadline. The reset has an expiry date of its own.