CLI: 5h rate limit went 0% -> 100% in 23 minutes while the weekly limit moved 1pp

What version of Codex CLI is running?

0.151.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Linux 6.8.0-138-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

No response

Codex doctor report

What issue are you seeing?

The 5h ("primary") rate-limit window went from 0% to 100% in 23 minutes, while the
weekly ("secondary") window moved only 55% -> 56% over the same period. The two
counters disagree by roughly two orders of magnitude for identical traffic, which
is what makes me think this is a metering bug rather than just heavy usage.

Numbers are taken from the rate_limits snapshots recorded in the session
rollout files under ~/.codex/sessions:

Timestamp (UTC)	primary used_percent	secondary used_percent
2026-09-01 07:22:07	0%	55%
2026-09-01 07:45:43	100%	56%

primary: window_minutes=300, resets_at=1788265323
secondary: window_minutes=10080, resets_at=1788765541
plan_type: plus

Actual traffic in that 23m41s window, summed across both sessions:

• 209 API calls
• 26,689,078 input tokens, of which 26,217,472 were cached (98.2%)
• 471,606 uncached input tokens
• 99,680 output tokens (34,237 reasoning)

So ~470k uncached input tokens and ~100k output tokens consumed the entire 5h
allowance, but only 1 percentage point of the weekly allowance.

I do not know how the primary window is weighted, but if cached input is being
billed against the 5h bucket at or near the uncached rate, that would explain
both the speed of the burn and the divergence from the weekly counter.

What steps can reproduce the bug?

1. Start two Codex CLI sessions concurrently, both on gpt-5.6-sol, each with a
   large accumulated context (~20M cumulative input tokens, ~96% cache hit rate).
2. Send one prompt to each and let them run agentic tool loops for ~20 minutes.
3. Watch the rate_limits values in the session rollout JSONL (or the limit
   display in the TUI).

Thread / session IDs:

• 01a056db-e496-7460-8eca-cdb640bf4dda
• 01a059ab-aa44-7720-8839-354309ccb041

Both sessions were still mid-task when the limit hit 100%.

What is the expected behavior?

Two ~20-minute sessions should not exhaust a full 5h Plus allowance, and the 5h
and weekly counters should move in proportion to each other for the same traffic.
A 100pp move in one and a 1pp move in the other suggests one of the two is
computed incorrectly.

Additional information

No response

Use the reported rate_limits snapshots in ~/.codex/sessions and the TUI limit display as entry points; compare primary and secondary accounting for the two listed session IDs. Reproduce with concurrent sessions on gpt-5.6-sol and high-cache contexts, then verify that the 5h and weekly counters move consistently without premature exhaustion.