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).

Affected thread IDs (these are the sessions that burned the limit):

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

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

Uploaded thread: 01a05c04-bf62-7e50-9d6b-ad50e15a0304
(submitted via /feedback; note that this uploaded thread is the empty session I
opened to file the report, so the diagnostics it carries are the doctor report
rather than the affected sessions.)

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

Start by inspecting the rate_limits snapshots in the session rollout JSONL files under ~/.codex/sessions and compare them with the limit display in the TUI. Reproduce the two concurrent-session workload using the affected model and high cache-hit context, then trace how the primary and secondary counters are computed. Done means the counters account for the same traffic consistently and the reported 5h usage no longer diverges unexpectedly from the weekly usage.