Session pinned to wrong rate_limits bucket (codex_bengalfox) while concurrent sessions on the same account receive the correct codex bucket #43136

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

0.153.3

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm (macOS 26.6.2)

What issue are you seeing?

During a multi-agent gpt-6-astra run, four threads began receiving rate_limits for a bucket the account was not consuming -- limit_id: "codex_bengalfox", limit_name: "GPT-5.3-Codex-Spark" -- instead of the codex bucket their requests were actually metered against.

That substitute bucket reported used_percent: 0.0 on both windows for the final 1,549 responses of the run, because it was not the bucket being drained.

This was not an account-wide outage. During the same minutes, other sessions on the same account received correct codex readings climbing 54% -> 100%. Only the threads in this run were misrouted.

Same account, same minute, two different answers

The codex bucket was last served to any of the four affected threads at 21:07:04.974Z, reading 51%. It never appeared in those threads again.

21:07:04.974Z  thread=root(11-42-15)   limit_id=codex            primary={used_percent:51.0, window_minutes:10080}   <-- LAST correct reading to this run
21:07:13.140Z  thread=root(11-42-15)   limit_id=codex_bengalfox  primary={used_percent:0.0, window_minutes:300}
                                                                 secondary={used_percent:0.0, window_minutes:10080}
21:13:41.131Z  thread=17-13-28         limit_id=codex            primary={used_percent:54.0, window_minutes:10080}   <-- correct, different session
21:14:01.229Z  thread=17-13-28         limit_id=codex            primary={used_percent:55.0, window_minutes:10080}
23:07:39.110Z  thread=19-04-51         limit_id=codex            primary={used_percent:100.0, window_minutes:10080}  <-- correct, different session
23:08:37.677Z  thread=phase3(11-42-58) limit_id=codex_bengalfox  primary={used_percent:0.0, window_minutes:300}
                                                                 secondary={used_percent:0.0, window_minutes:10080}

143 correct codex weekly readings were issued to this account after 21:07:05Z. None went to the four threads in this run, which were still actively issuing requests throughout (1,023 requests in the 21:00Z hour alone).

Onset: both buckets interleaved for ~17 minutes

20:49:53.982Z  limit_id=codex             primary={used_percent:40.0, window_minutes:10080, resets_at:1789225024}  secondary=null
20:49:54.448Z  limit_id=codex_bengalfox   limit_name="GPT-5.3-Codex-Spark"
                                          primary={used_percent:0.0,  window_minutes:300,   resets_at:1788659369}
                                          secondary={used_percent:0.0, window_minutes:10080, resets_at:1789246169}
20:49:54.692Z  limit_id=codex             primary={used_percent:41.0, window_minutes:10080, resets_at:1789225024}  secondary=null

Two further signals that codex_bengalfox is not a live bucket for this account:

1. used_percent is 0.0 on all 1,628 of its occurrences -- max primary 0, max secondary 0, across the entire run.
2. Its resets_at advances on every response (1788659369 -> 1788660400 -> 1788660405 -> 1788667665), a window that never anchors and cannot accumulate. The real codex bucket held a stable resets_at of 1789225024 throughout.

Counts

Impact

A banked reset was redeemed on this account at ~14:57Z that morning, opening a fresh weekly window. It was fully consumed by 23:13Z -- 7h 31m later -- with the affected threads reporting 0% for the final two hours and surfacing no warning banner at any threshold.

You have hit your usage limit. Visit https://chatgpt.com/codex/settings/usage
to purchase more credits or try again at Sep 12th, 2026 10:57 AM.

What steps can reproduce the bug?

Not deterministically reproduced. Observed conditions:

1. Codex Desktop 0.153.3, plan pro, model gpt-6-astra (effort medium, summary auto).
2. Start a root thread and spawn 3 subagents (multi_agent_version: v2; agent_path values /root/phase3_next_step, /root/camera_review, /root/platform_acceptance). All 4 threads share one cwd.
3. Run continuously for several hours (this run: 2026-09-05T15:42:19Z -> 23:13Z, 2,683 model requests).
4. Concurrently, run one or more separate unrelated Codex sessions on the same account.
5. Inspect rate_limits in the token_count payloads of each session rollout at ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl.

Onset was mid-run at 20:49:54Z, with ~17 minutes of both buckets interleaved before codex disappeared from these threads entirely at 21:07:04.974Z. The separate sessions started later (17:13 and 19:04 local) continued to receive correct codex readings throughout.

The fact that sibling sessions were unaffected suggests a routing or session-affinity problem rather than an account-level state transition.

What is the expected behavior?

rate_limits should describe the bucket the request is actually metered against, consistently, for every session on an account.

Specifically:

• A session must not be pinned to a limit_id other than the one its requests are drawing down.
• A session must not silently switch which limit_id it reports mid-run.
• A bucket reading 0% must not suppress low-usage warnings for the bucket actually being consumed.

Actual behavior: four threads reported 0% on both windows for their final 1,549 responses while the account ran from 51% to exhaustion, with no warning at any threshold, while sibling sessions on the same account concurrently received accurate readings.

Additional information

Ruling out workload and client-side causes

• Not a background/idle request loop. The run had 286 of 451 wall-clock minutes with zero requests, including one contiguous 251.6-minute gap (16:07:59Z -> 20:19:35Z) during which the client issued nothing. All 2,683 requests are attributable to active agent turns.
• Not a changed workload profile. Cache hit ratio for this weekly window was 97.7%, statistically identical to the account's three prior weekly windows (97.0%, 97.3%, 97.5%).
• Not client version skew. All four affected threads and the correctly-served concurrent sessions ran the same binary (0.153.3) on the same machine under the same auth session.

Other notes

A third limit_id value, premium, was also observed on this account the same day. Not investigated here.

Raw rollout files are not attached -- they contain source-tree paths and workspace content. Full sanitized token_count / rate_limits line sets for all 2,683 responses, plus the correctly-served concurrent sessions, can be provided through a private or support-safe channel on request.