Codex Pro quota draining abnormally since 2026-06-25; local logs show needs_follow_up token loops

What issue are you seeing?

Starting around 2026-06-25, my ChatGPT Pro account started showing abnormally fast Codex quota consumption. This appears similar to #29963, #30002, and #30054: quota drains much faster than the local token evidence suggests, and local logs show repeated model_needs_follow_up=true samples inside single turns.

I submitted in-product feedback with logs attached.

Uploaded thread: 019effb1-407c-7383-8b89-0fdbc95e418e

What version of the Codex App are you using?

• Codex app: 26.616.81150 (CFBundleVersion 4306)
• Codex CLI: 0.142.0
• Platform: macOS arm64
• Auth mode: ChatGPT login
• Subscription: ChatGPT Pro
• Main model/config: mostly gpt-5.5, reasoning high / xhigh, default service tier

What steps can reproduce the bug?

1. Use Codex desktop / CLI with a Pro account.
2. Run normal Codex work after 2026-06-25.
3. Watch the 5h / weekly quota move much faster than expected.
4. Inspect local diagnostics. I used sanitized aggregates from ~/.codex/logs_2.sqlite and session JSONL files, without prompt content or account identifiers.

Sanitized local evidence

From codex_core::session::turn logs, grouping only post-sampling token usage rows:

| Local date | Turns | Sampling rows | model_needs_follow_up=true rows | Turns with >=5 true samples | Max single-turn token delta | Max samples in one turn |
|---|---:|---:|---:|---:|---:|---:|
| 2026-06-23 | 95 | 171 | 77 | 6 | 60,747 | 14 |
| 2026-06-24 | 178 | 431 | 253 | 29 | 234,317 | 16 |
| 2026-06-25 | 126 | 302 | 177 | 20 | 100,615 | 15 |

Worst redacted single-turn examples:

| Redacted turn | Local date/time | Model | Effort | Duration | Samples | True samples | total_usage_tokens delta | token_limit_reached |
|---|---|---|---|---:|---:|---:|---:|---|
| Turn A | 2026-06-24 03:04:50-03:07:31 | gpt-5.5 | xhigh | 161s | 4 | 3 | 234,317 | true |
| Turn B | 2026-06-24 00:26:20-00:31:14 | gpt-5.5 | high | 294s | 13 | 12 | 229,144 | true |
| Turn C | 2026-06-25 11:31:39-11:33:55 | gpt-5.4 | medium | 136s | 15 | 14 | 100,615 | false |
| Turn D | 2026-06-25 02:59:49-03:01:13 | gpt-5.5 | xhigh | 84s | 7 | 6 | 69,933 | false |

Session-level local summary also shows the quota meter already high on a small fresh session:

| Local date/time | Session total tokens | 5h quota shown in rate limits | Weekly quota shown in rate limits |
|---|---:|---|---|
| 2026-06-26 00:35-00:48 | 359,784 | 38% -> 40% used | 24% used |
| 2026-06-26 00:37-00:37 | 44,848 | 38% used | 24% used |
| 2026-06-26 00:41-00:43 | 333,968 | 39% used | 24% used |

The CLI status line also showed weekly 76% left immediately after opening a fresh temporary TUI for feedback.

Expected behavior

• Pro quota consumption should remain proportional to actual usage.
• A single turn should not repeatedly sample with model_needs_follow_up=true and accumulate large token deltas unless it is genuinely doing that much work.
• 5h / weekly quota should not drain at the effective rates reported by users in #29963, #30002, and #30054.
• If this is a quota accounting or reset bug, incorrectly consumed paid quota should be restored.

Additional notes

I did not include account IDs, email addresses, local user paths, prompt text, auth tokens, or raw session logs in this public issue. The attached in-product feedback upload should give maintainers the diagnostic context via the uploaded thread ID above.