Paid credits silently drawn down while rate_limit reports allowed=false and 84% of weekly allowance remains (Plus)

Summary

On a ChatGPT Plus account with 84% of the weekly included allowance still remaining, Codex kept serving requests after the 5-hour window hit 100% and silently billed them against my purchased credit balance — no confirmation prompt, no client-visible notice, and no per-request billing ledger. Every response still carried limit_reached: true while credits were being drawn down.

Evidence

1. Backend kept executing requests while reporting allowed=false

codex-cli 0.150.1 session rollouts record the rate_limits snapshot the backend attaches to every response. Session started 13:29:23 (UTC+8), 2026-08-30. total_tokens is the server-confirmed count of the response at that point:

local time	total_tokens	5h window	weekly	credits.balance
13:29:40	37,980	100.0	16.0	2995.4510
13:30:18	383,730	100.0	16.0	2995.4510
13:30:25	465,349	100.0	16.0	2951.9045 (−43.5465)
13:35:11	2,018,569	100.0	16.0	2951.9045

Zero UsageLimitReached errors were surfaced; ~2.0M tokens were executed server-side during this session alone. A second session (14:28:31) ran to completion the same way: 5h=100.0, weekly=16.0, no errors, balance constant at 2745.7597 in all 8 of its snapshots.

2. Independent wham/usage samples confirm steady drawdown

Two GET /backend-api/wham/usage calls on the same account, ~65 min apart, with no window reset in between (identical reset_at values):

• t1 14:26:50 — allowed: false, limit_reached: true, 5h=100%, weekly=16%, credits.balance: "2745.7597130000"
• t2 15:31:51 — allowed: false, limit_reached: true, 5h=100%, weekly=16%, credits.balance: "2735.5822130000"

Expected behavior

Per the help center — "Your plan's included usage is used first. After you hit plan limits, usage draws from your credit balance" — with the weekly included allowance 84% unused, I would expect at least one of:

1. Service continues drawing from the included allowance (the 5h window acting as a throttle only), or
2. Service pauses (allowed=false honored end-to-end), and paid credits are consumed only after an explicit user opt-in ("continue with credits?"), never silently.

Actual behavior

The backend simultaneously:

• (a) reports limit_reached: true / allowed: false in every response,
• (b) keeps executing and returning model responses, and
• (c) silently bills paid credits.

There is no client prompt, no warning, and the usage payload exposes only credits.balance plus message-count approximations — no transaction ledger to reconcile drawdowns against sessions.

Questions

1. Is billing paid credits while rate_limit.allowed=false and the weekly included allowance has 84% remaining intended behavior?
2. If intended, should the client require explicit opt-in before switching to paid credits?
3. Can the usage endpoint expose a credits transaction ledger so drawdowns can be audited?

Environment

• codex-cli 0.150.1, Windows 11
• ChatGPT Plus plan with purchased credits (credit purchases made earlier; balance only ever moves downward)

Related open issues

• #27097 — Paid credits consumed too quickly and Pro quota still blocked
• #38294 — Codex credits consumed ~38,000–39,000 overnight with zero tasks issued, no warning given
• #30784 — Credit consumes too fast

Start by comparing the codex-cli 0.150.1 session snapshots with the two GET /backend-api/wham/usage samples, focusing on the relationship between allowed, limit_reached, rate_limits, and credits.balance. Done should establish whether this behavior is intended and define the missing client warning, opt-in, or credits-ledger behavior needed to reconcile drawdowns.