›_ Codex Issues
Codex Issues / #36436

Weekly usage reset silently while 68% remained; no reset-credit consume call recorded

Open 💬 2 comments Opened Aug 1, 2026 by pjonasice
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

A weekly Codex usage window reset unexpectedly while approximately 68% of the weekly allowance remained. No explicit reset confirmation was shown, and the local rollout record contains no call to account/rateLimitResetCredit/consume.

This closely matches #28525, but it occurred on a newer Codex desktop build after that issue was closed without a public fix, linked pull request, or release reference.

Environment

  • Codex desktop app: 26.727.6591.0
  • Platform: Windows
  • Model selected by the user: gpt-5.6-sol
  • Reasoning level: xhigh
  • Affected task/thread: 019f7aff-07eb-7281-b3d8-9c4b8b6eab78
  • Time zone below: JST (UTC+09:00)

Confirmed timeline from local rollout snapshots

  • 2026-07-31 20:41:23: weekly used 27%, about 73% remaining.
  • 2026-08-01 01:16:59: weekly used 27%.
  • 2026-08-01 12:29:28: weekly used 32%, about 68% remaining.
  • 2026-08-01 12:36:07: still 32% used; scheduled reset was 2026-08-05 18:05:54.
  • 2026-08-01 12:36:23: weekly used became 0%; scheduled reset moved to 2026-08-08 12:36:08, almost exactly seven days later.
  • 2026-08-01 14:08:41: weekly used was 1% in the new window.

Usage on August 1 accounts for approximately five percentage points before the reset and one point afterward. Natural weekly-limit exhaustion is therefore ruled out.

Local evidence

  • The affected automation was running when the transition occurred.
  • The local tool input around the transition did not contain a reset request or reset-related method.
  • No local record of account/rateLimitResetCredit/consume was found.
  • No manual reset was initiated by the user.
  • The evidence proves that the backend returned a newly anchored seven-day window, but the client-visible records do not identify whether it was:
  • an automatically consumed banked reset;
  • a global/hard reset;
  • an expiry plus a separate reset event; or
  • another server-side quota-accounting defect.

No authentication values, tokens, or account secrets are included in this report.

Expected behavior

  1. A banked reset must not be consumed without explicit user confirmation.
  2. A task should pause before consuming a scarce reset credit.
  3. The usage UI should show reset-event history, including event type, timestamp, trigger, and whether a credit was consumed or expired.
  4. A reset must not silently replace a weekly window while substantial allowance remains.

Requested action

Please:

  1. Audit the account-side reset transaction corresponding to 2026-08-01 12:36:07-12:36:23 JST and identify the server-side actor, event type, and trigger.
  2. Restore the banked reset credit if it was consumed or removed incorrectly.
  3. Confirm whether this is a recurrence of #28525 and explain why that issue was closed as completed without a public fix reference.
  4. Add explicit confirmation before reset redemption and expose reset-consumption/expiry history in supported usage surfaces.
  5. Confirm which released version contains the fix, if a fix already exists.

Related: #28525, #28805, #32218, #34661.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 27 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #36313

Powered by Codex Action

pjonasice · 27 days ago

Additional local evidence: five uncommanded window replacements; restore at least four missing resets

Clarification: this is not only a comparison with other public reports. A complete read-only analysis of this account's local Codex history found repeated events in the same local environment.

Scope

  • 611 local rollout JSONL files examined
  • 24,535 structured weekly rate-limit snapshots examined
  • Main limit: codex, Pro plan
  • No authentication values, tokens, account secrets, or Hub secrets included

Five premature weekly-window replacements

| Event time (JST) | Prior remaining | Old scheduled reset | New scheduled reset | Old reset still ahead by |
|---|---:|---|---|---:|
| 2026-07-15 05:47:03 | 91% | 2026-07-20 14:07:09 | 2026-07-22 05:47:03 | 128.335 h |
| 2026-07-16 17:09:07 | 91% | 2026-07-22 05:47:03 | 2026-07-23 17:09:07 | 132.632 h |
| 2026-07-18 20:56:46 | 73% | 2026-07-23 17:09:07 | 2026-07-25 20:56:46 | 116.206 h |
| 2026-07-22 02:14:27 | 67% | 2026-07-25 20:56:46 | 2026-07-29 02:14:27 | 90.705 h |
| 2026-08-01 12:36:23 | 68% | 2026-08-05 18:05:54 | 2026-08-08 12:36:23 | 101.492 h |

Each event produced a newly anchored seven-day window while substantial allowance remained in the prior window. Events 1, 2, and 5 were observed at or within seconds of transition. Events 3 and 4 are derived from the exact backend-provided seven-day reset anchors and were first observed 4.342 h and 0.524 h later.

A separate transition on July 29 was excluded because the prior scheduled reset had already passed; it may be an ordinary first-use anchor.

No authorized redemption record

  • The user states that these resets were not manually redeemed.
  • No local tool-call record invoking account/rateLimitResetCredit/consume exists before any of the five events.
  • Mentions of that method appear only after the August 1 event during investigation and cannot explain the earlier transitions.
  • The user observed approximately four stored reset opportunities disappear without intentionally using them.

The client persists weekly usage snapshots but does not preserve historical rateLimitResetCredits.availableCount or a user-visible reset transaction ledger. Therefore, local evidence proves five premature window replacements, while only OpenAI's server-side ledger can determine which events consumed a banked reset, were global/hard resets, expired credits, or were another accounting action.

Updated required remedy

Please:

  1. Audit all five timestamps against the account-side reset-credit and quota-event ledger.
  2. Provide, through a privacy-safe channel, each event's ID, event type, actor/source, trigger, affected pool, credit disposition, before/after values, and recorded user-consent state.
  3. Restore no fewer than four reset opportunities corresponding to the user's observed unexplained losses unless OpenAI can provide timestamped evidence of explicit user redemption for each one.
  4. If the audit shows that more than four credits were consumed or removed without authorization, restore every affected credit.
  5. For any global/promotional/hard reset, restore the displaced unused allowance or equivalent value and explain why the original window was replaced.
  6. Do not close this issue as a duplicate without an account-specific audit and a concrete restoration decision.

This supplements the original August 1 incident timeline and materially expands the requested account-side audit.