Paid/banked resets restart the weekly clock and displace included refills instead of adding quota

What issue are you seeing?

Codex resets refresh the usage allowance and restart the weekly reset schedule, rather than provide additional usage while preserving the subscription's existing replenishment schedule. I have observed the weekly schedule changing after banked resets and OpenAI-applied resets, including resets announced by Tibo.

This has an important consequence for the $80 paid reset option: a customer can pay to receive a refill sooner while the refill already scheduled under their subscription is displaced. That is not equivalent to purchasing an additional allowance on top of the subscription.

My expectation is: subscription allowance + purchased allowance. The current paid-reset design is: refill now + replace the subscription's reset schedule.

Documented behavior, not an assumed client-code defect

OpenAI's Paid weekly Work and Codex rate limit resets confirms that the purchase advances the normal allowance rather than creating an independent entitlement. Restoration is immediate, but the next automatic reset is seven days after the first Work or Codex request following the reset—not necessarily seven days after payment.

How banked Codex resets work also confirms that a full banked reset changes the weekly reset date.

I recognize that this is documented product design for paid/banked resets, not proof of an accidental harness-code bug. This issue requests additive quota behavior, clear purchase/redemption disclosure, and clarification of whether automatic/global resets follow the same scheduling rule.

The $80 figure is the paid-reset price being raised in this report, not a claim about pricing on every plan. This report concerns usage resets, not separately metered credit purchases.

The math: an earlier refill is not necessarily an extra refill

Define:

• A = time the purchased reset applies and restores the allowance.
• T = first Work or Codex request after that reset.
• R = next weekly reset timestamp displayed before the purchase.
• W = the seven-day weekly window.

For a reset purchased and used before the original deadline, A ≤ T < R:

New scheduled reset = T + W

Delay to the previously scheduled refill = (T + W) − R

Equivalently:

Delay = seven days − the time left until the original reset when post-reset usage begins.

The customer can resume work earlier, but the original refill at R is no longer an independent refill. It is replaced by the new schedule.

Compare refill opportunities from A, inclusive, until T + W, exclusive, with no further manual resets in that interval:

Treatment	Refill opportunities in that same interval
No additional reset	One included refill at R
Truly additive reset	One additional refill at A, plus the included refill at R
Current clock-restarting reset	One refill at A; the next refill is not until T + W

Within that interval, the $80 purchase advances one refill rather than adding a second refill. There is a real earlier-access benefit, but that is different from an additional allowance with the subscription schedule preserved.

Repeated paid resets

For a fixed comparison period, isolate paid resets from other changes and define:

• B = ordinary subscription refill opportunities that would occur without the purchases.
• P = paid reset events during that period.
• D = the reduction in ordinary refill opportunities during that period caused by restarting the clock.

Then:

Expected additive refill count = B + P

Actual refill count = B − D + P

Net added refill opportunities above the subscription baseline = P − D

Additional spending = $80 × P

When P − D is positive:

Cost per net added refill opportunity = ($80 × P) / (P − D)

This is why counting purchases alone overstates the added value: the displaced subscription refills must also be counted. Repeated resets before the next weekly deadline can repeatedly postpone ordinary replenishment.

These equations count refill opportunities, not actual tokens consumed or a proven cash loss. Restoring a partially used allowance to 100% also adds only the missing portion, not another full allowance. The exact long-term effect depends on reset timing, the comparison period, and usage. I am not claiming that every purchase permanently cancels exactly one future refill or provides zero useful value.

What steps can verify the behavior?

1. Record the current weekly remaining percentage and next reset timestamp in Usage or /status.
2. When applying an already intended paid or banked reset, record its application time, the time of the first subsequent request, and the resulting percentage and reset timestamp. This report is not asking anyone to make an additional purchase just to reproduce it.
3. Check whether the old scheduled reset remains an independent replenishment opportunity or has been replaced by a new seven-day window.
4. Inspect the server-side reset history to distinguish paid, banked, automatic/global, and ordinary weekly events.

For automatic/global resets, the trigger is not user-controlled; before/after account-state records are needed. This report does not include an account-specific timestamp trace or establish a particular harness implementation as the cause.

What is the expected behavior?

Paid or promotional additional usage should not reduce or postpone the ordinary replenishment provided by the subscription.

Requested changes:

1. Preserve the existing weekly reset schedule when additional usage is purchased or granted. Track the added entitlement separately so it can actually be used without replacing the subscription allowance.
2. If a reset remains an early renewal rather than additional usage, disclose that before payment or redemption. Show the existing reset timestamp and explain how the new timestamp is determined, explicitly stating that the old scheduled refill will not also occur. Once post-reset usage begins, show the resulting timestamp.
3. Make automatic/global reset behavior explicit and protect paid/banked value from being overwritten by a subsequent reset.
4. Expose reset-event history with event type, application time, previous/new quota state, and previous/new weekly reset timestamp, so customers can reconcile the benefit received.

Paying for extra usage should add to what the subscription already provides—not require surrendering a scheduled subscription refill to receive it sooner.

Related reports

• #38332: an unsolicited reset replacing an active window with a new seven-day window.
• #43643: global resets overwriting the practical value of recently redeemed banked resets.
• #43694: a request to grant global resets as banked credits rather than overwrite active quota state.

This report specifically adds the paid-reset/subscription-refill accounting issue. If the responsible quota service is outside this repository, please route it to that team and retain a public tracking reference.

Start with the Usage view or /status, then compare the reset timestamps and quota state described in the report with server-side reset history. Review related issues #38332, #43643, and #43694; done means the responsible quota service preserves the subscription schedule, records reset events, and clearly discloses non-additive behavior if that remains the design.