Plus: quota hits 100% after idle period with zero sessions; Jul 2 single-prompt drain 1%→100% in 6 min (session logs)

Summary

ChatGPT Plus Codex quota shows 0% remaining (both 5-hour and weekly windows at used_percent: 100) despite no Codex activity for 29+ hours. Local session forensics show prior abnormal quota accounting on Jul 2 (single user message → 99% consumed in ~6 minutes) and a silent drain from 79% → 100% between Jul 4 evening and Jul 5 with zero new session files.

This appears to be a server-side rate-limit accounting bug, not legitimate usage. Verified independently via GET https://chatgpt.com/backend-api/codex/usage (OAuth) and local ~/.codex/sessions/ JSONL logs.

Related / potential duplicates: #30943, #30918, #30909, #29963
Prior incident: https://status.openai.com/incidents/01KW2E6W0503W4NXJNCVAG8V6T (marked resolved Jun 29, 2026; behavior persists)

Environment

• Plan: ChatGPT Plus (plan_type: plus)
• Codex CLI: codex-cli 0.141.0
• OS: macOS 26.5
• Account ID (for OpenAI internal lookup): 41de98b6-aaec-427c-904b-1a60e4fd6dcb

Current state (2026-07-05 ~23:30 CST)

OAuth backend-api/codex/usage response:

• rate_limit.primary_window.used_percent: 100 (resets 2026-07-06 01:38 CST)
• rate_limit.secondary_window.used_percent: 100 (resets 2026-07-10 11:17 CST)
• credits.balance: 0

User has not sent any Codex prompts today (Jul 5). Only background account/rateLimits/read calls from the app (read-only, should not consume quota).

Evidence 1 — Idle drain with zero sessions (Jul 4 → Jul 5)

| Time (UTC) | Event |
|---|---|
| 2026-07-04T10:25:15Z | Last used_percent in local session logs: 79% (rollout-2026-07-04T16-34-07-...) |
| 2026-07-05 (entire day) | 0 new files under ~/.codex/sessions/2026/07/05/ |
| 2026-07-05 15:26–23:26 CST | 0 conversation/prompt log entries; only rateLimits/read + initialize |
| 2026-07-05 ~23:30 CST | OAuth usage API still reports 100% on both windows |

Expected: quota should not increase from 79% → 100% with zero sessions and zero prompts for 29+ hours.
Actual: both windows show fully exhausted.

Evidence 2 — Abnormal fast drain on Jul 2 (single prompt)

Session: rollout-2026-07-02T12-15-12-019f2109-b5fe-7c11-be8f-10f6a5a3a946.jsonl

• User messages sent: 1 (at 2026-07-02T04:15:32.780Z)
• 5-hour used_percent timeline:
• 04:15:39 → 18%
• 04:18:33 → 37%
• 04:18:52 → 1% ← appears to be a window reset mid-session
• 04:19:58 → 15%
• 04:24:40 → 100%
• Drain after reset: 1% → 100% in ~5m 48s with no additional user messages

This is far beyond normal Plus consumption for a single interactive turn.

Evidence 3 — Parallel Jul 2 sessions with similar pattern

Other sessions on the same day showing comparable abnormal drains (all within ~12 minutes):

| Session file (prefix) | First % | Last % | Notes |
|---|---|---|---|
| ...019f2109-b5fe... | 18% | 100% | 1 user message |
| ...019f210a-6755... | 1% | 100% | rapid drain |
| ...019f210a-7297... | 22% | 93% | rapid drain |
| ...019f210d-3c57... | 4% | 91% | rapid drain |
| ...019f22b9-69eb... | 1% | 100% | evening session |

Reproduction (as observed)

1. Use Codex CLI on Plus with normal prompts.
2. Observe used_percent climbing far faster than expected (sometimes 1% → 100% in minutes).
3. Stop using Codex entirely.
4. Hours later, OAuth usage API reports 100% despite no new sessions.

Impact

• Paid Plus entitlement effectively unusable.
• User cannot distinguish legitimate exhaustion from accounting bugs.
• Prior status incident marked "resolved" but behavior continues into July 2026.

Request

1. Investigate server-side quota accounting for account 41de98b6-aaec-427c-904b-1a60e4fd6dcb.
2. Identify what consumed quota between 2026-07-04T10:25Z (79%) and 2026-07-05 (100%) with zero client sessions.
3. Restore incorrectly consumed 5-hour / weekly quota if confirmed bug.
4. Confirm whether Jul 2 post-reset drain (1% → 100% in <6 min, 1 user message) was a known regression.

Happy to provide sanitized token_count / rate_limits log lines from session JSONL on request (not attaching raw files — they contain prompts and workspace paths).