5-hour usage limit exhausted right after reset: first rate_limits reading already reports used_percent=79% with no preceding model activity

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.51957

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

The 5-hour usage limit was displayed as reset/available in the app UI. I opened a new thread and sent a single message. Within ~5 minutes the 5h limit went from "available" to 100% and I was blocked.

Digging into local logs, the very first rate_limits reading of that thread was already at 79% — before my message could plausibly have consumed that much — and there was no model activity in the window prior to my message:

Thread 019f56ef-2688-7912-82c7-dc6a372575f7, 5h window starting 08:08:34 local (resets_at - 300min):
08:26:46 primary.used_percent = 79% (this thread's cumulative tokens so far: 29k)
08:29:18 used_percent = 94%
08:30:20 used_percent = 100%
08:31:21 used_percent = 100% (this thread total: ~782k tokens)

The 79% at 08:26:46 cannot have come from this thread (only 29k tokens billed to it at that point). Checking ~/.codex/logs_2.sqlite, there was NO model inference in this account between the window start (08:08:34) and my message (08:25:41) — only background HTTP-pool / OTLP-telemetry / websocket log entries. The first op.dispatch.user_input of the day after the reset is at 08:29.

So the 5h quota the UI showed as "reset" did not match the server-side rate-limit accounting, which was already ~79% consumed at the first turn.

What steps can reproduce the bug?

Feedback ID: 019f56ef-2688-7912-82c7-dc6a372575f7

What is the expected behavior?

Immediately after a 5h window reset that the UI presents as available, a fresh thread's first rate_limits reading should reflect the actual (near-zero) consumption of the new window. The 5h usage shown in the UI should be consistent with the server-side rate-limit accounting used to enforce the limit — a user shouldn't see "available" and then be blocked after a single message because the window was in fact already ~79%
consumed.

Additional information

Config context that likely amplifies cost per message (may be relevant to how fast the window fills, though not the core discrepancy above):

• model = gpt-5.6-sol, model_reasoning_effort = xhigh
• multi_agent = true — this single message fanned out into 3 concurrent threads

(019f56ef-2688, 019f56ef-ab74, 019f56f2-972d)

• ~20 enabled plugins + 3 MCP servers → ~67k input tokens per turn (mostly tool schema)

What I ruled out: no other Codex session on this machine was active between the window reset and my message.

What I could NOT rule out from local logs: account-level usage from another surface or device (the 5h quota is account-wide). If the maintainers can see server-side usage for Feedback ID 019f56ef-2688-7912-82c7-dc6a372575f7, that would confirm whether the 79% was real prior usage or an accounting/display bug.