Usage rejected with 37% remaining: premium/null quota snapshot and an older reset window (Astra, Pro, Windows)

Summary

On September 9, 2026, three local Codex sessions stopped with usage_limit_exceeded even though their ordinary weekly quota readings still showed 63% consumed (37% remaining). The rejection coincided with limit_id changing from codex to premium, 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

• Windows, ChatGPT Pro.
• Recorded Codex CLI version: 0.153.4.
• Main session: gpt-6-astra, medium; two affected workers: gpt-6-astra, low.
• ChatGPT authentication; no API-key billing claim.
• Times below are UTC; local timezone is America/Mexico_City (UTC-6).

Verified sequence

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.

The report names no source files or tests. Start by reproducing the recorded quota-transition sequence and compare the reported limit, windows, reset times, and enforced response; done means the applicable limit is identified and reported quota, reset timing, and access behavior agree.