Repository navigation
Usage rejected with 37% remaining: premium/null quota snapshot and an older reset window (Astra, Pro, Windows) #44234
Description
Activity
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
- Weekly quota dropped from 21% remaining to 0% while idle; reset timestamp changed unexpectedly #44233
- GPT-6 Astra usage limit is not visible in /status or usage dashboard #43006
- [Windows][Pro 20x] Weekly usage display jumped 60%→97% while reset timestamp changed #44210
Powered by Codex Action
Second incident, September 9, 2026: the displayed allowance fell from 99% to 36% remaining. Local quota metadata confirms a change of accounting window, not just an increasing percentage within one window:
- 17:39:11.257 UTC: main session reports codex, 1% used, reset epoch 1789577954 (September 16).
- 17:40:10.225 UTC: same session reports codex, 63% used, reset epoch 1789466585 (September 15).
- 17:40:28.387 UTC: same session reports 64% used with the September 15 reset.
- 17:40:51.895 UTC: another session still reports 1% used with the September 16 reset; at 17:41:06.616 UTC it changes to 64% used with the September 15 reset. These observations may include stale per-session snapshots.
- At 17:46 UTC the live account endpoint confirms 64% used with reset epoch 1789466585.
For 17:36:24–17:46:24 UTC, deduplicated local completed-response records show 38 responses versus 67 in the preceding ten minutes. Total input fell from 12,019,490 to 6,781,786 tokens (cached input is included); uncached input was 125,858 versus 106,842; output was 33,129 versus 36,316. Only an Astra Medium investigation/support session and a Luna Max policy-editing worker appear in these records. No task-completion errors were found in this second interval. The worker has been paused. These are local records, not a server billing ledger, and cannot establish a percentage-to-token conversion.
The verified symptom is a reversion to an earlier reset window with a discontinuous allowance reading. Please correlate this with the official unexpected-reset incident and determine whether it is recovery/reconciliation, incorrect quota routing, or another accounting issue. We cannot establish the backend cause locally. A private refund and human-review request has now been submitted through the signed-in Help Center chat; a decision has not yet been received. No credentials, source code, customer information or security findings are included.
Additional affected-account evidence from the same incident:
- Environment: ChatGPT/Codex Desktop on Windows, ChatGPT Pro, UTC+8.
- A full reset had been manually applied on September 9, and the UI subsequently showed the next weekly reset on September 16.
- At approximately September 10, 2026 01:30 UTC+8, the main Codex weekly meter abruptly changed from about 25% used / 75% remaining to 78% used / 22% remaining. The reset date simultaneously moved backward from September 16 to September 11.
- A direct authenticated
account/rateLimits/readsnapshot during the anomaly returnedusedPercent: 78,windowDurationMins: 10080, andresetsAt: 1789139466(September 11, 2026 23:11 UTC+8). - A few minutes later, after mitigation for the status incident was posted, the same backend read returned
usedPercent: 25,windowDurationMins: 10080, andresetsAt: 1789539023(September 16, 2026 14:10 UTC+8). The UI also returned to 75% remaining. - The available Full reset count remained 1 in both readings, so the correction was not caused by consuming another reset.
This was therefore observable in the authenticated rate-limit response, not only as a UI rendering issue. It self-corrected after mitigation, but please confirm that affected accounts will not retain any permanent usage miscount.
No account email, account ID, screenshot, session content, or local path is included in this public comment.
Follow-up — 2026-09-10
OpenAI Support has not yet provided a case number or a refund/credit decision in the existing Help Center conversation. OpenAI's September 9 email confirms that the incorrect usage-limit display issue was fixed and that banked usage resets used during the affected window were restored. That addresses the reset symptom, but it does not explain or remediate allowance consumed by the failed September 7–8 work.
Please link this issue to the incident, confirm whether the account-level ledger was corrected for affected tasks, and advise on the remaining refund or credit review. I am keeping private account and execution metadata in the Support case.
Summary
On September 9, 2026, three local Codex sessions stopped with
usage_limit_exceededeven though their ordinary weekly quota readings still showed 63% consumed (37% remaining). The rejection coincided withlimit_idchanging fromcodextopremium, with both quota windows null.This is an actual execution failure, not only a display complaint. I have experienced unexpected depletion/interrupted work since Astra's release; that recurrence is my experience, while the precise sequence below is verified in local metadata.
Environment
Verified sequence
premium, primary=null, secondary=null.The error tells me to try again on September 14, 2026, 4:58 a.m. local. The ordinary pre-error window points to September 15, 4:03 a.m. The later zero-consumed window points to September 16, around 10:59 a.m.
Notably, September 14 at 4:58 matches an older window recorded on September 7, rather than the window being reported on September 8–9. Please check for stale-window enforcement or inconsistent quota selection; I cannot establish the internal cause from client logs.
Workload sanity check
Deduplicated local response-usage records show 79 completed responses during 16:40–16:48 UTC, versus 94 during 16:48–16:57 UTC (eight versus nine minutes). Total input per minute decreased; output per minute increased about 10%. There was no obvious order-of-magnitude local workload surge. Ordinary quota snapshots in the latter interval remained at 62–63% consumed.
This is not a claim that local token counts are the authoritative billing ledger. Delayed accounting, other account activity, or another quota require server-side investigation. Null quota windows must not be interpreted as zero remaining.
Expected behavior
Reported quota, reset window, and enforced access should agree. If a different limit applies, identify it with usable counters/reset information. Explain any accounting adjustment rather than abruptly rejecting work with a reset date belonging to a different window.
Related incident and request
OpenAI has now posted Investigating unexpected usage limit resets. Please confirm whether this symptom is covered. Related but not identical: #43136.
I am also requesting private support review and a refund for the affected paid service. No account email, session/response IDs, local paths, source code, security findings, credentials, or raw logs are included here. Correlation metadata can be supplied privately to OpenAI support.
Separate recurring impact: security audits have failed to finish as allowance reached zero. A metadata-only check found 15 usage_limit_exceeded worker/turn completion events on September 7; that is not 15 distinct scans and does not prove all depletion was erroneous.