Keep retrying after getting - Selected model is at capacity (Don't process rest of queue)

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #33661
• #33171

Powered by Codex Action

Same problem met.

Same

I encountered the same behavior in Codex Desktop on macOS.

Environment

• ChatGPT App: 26.715.21425
• Bundled Codex: codex-cli 0.145.0-alpha.18
• Model: gpt-5.6-sol

Observed behavior

• The UI showed “Optimized the conversation”, followed by:

Selected model is at capacity. Please try a different model.

• The active turn terminated and the task was marked with an orange exclamation indicator in the sidebar.
• Local session metadata records two capacity-terminalized task_complete events:
• 2026-07-17T15:23:52Z while reasoning effort was low
• 2026-07-17T15:34:10Z while reasoning effort was medium
• After changing reasoning effort to high and resubmitting, the next turn completed at 2026-07-17T15:37:11Z.

This does not appear to mean that a particular reasoning level is broken. Changing the level appears to trigger a fresh admission attempt, which can succeed after the transient capacity failure.

A redacted codex doctor --summary run completed with installation, configuration, authentication, state databases, thread inventory, HTTP reachability, and WebSocket connectivity all healthy. No duplicate app-server process was found. This makes a persistent local installation, authentication, or connectivity failure less likely.

The main usability problem is that a transient capacity response terminalizes the active turn instead of retrying with bounded backoff or preserving an explicit resumable state. Since side effects may already have occurred before termination, blindly resubmitting can also risk duplicate work.

same problem please fix

This queue issue a big one because often it will break the prompt with this capacity issue presumably from a load balancer but then it will cascade right into the follow up tab queued prompt even though that prompt is/can be dependent on the previous prompt having finished correctly

for example, if ive prompted implement and merge A which fixes B and then tab queued up "now that B is fixed we can implement C" then "selected model is at capacity" hits, it can immediately halt our finishing of A but then because a load balancer switches us to somewhere where the model is not at capacity, it can from a dirty halfdone feature A begin the confused implementation of C from a partially done conversation.

I traced the CLI/TUI side of this cascade to ChatWidget::on_server_overloaded_error: after finalizing the failed turn and rendering the warning, it unconditionally calls maybe_send_next_queued_input(). That means a Tab-queued dependent prompt is submitted before the later failed turn/completed notification can do anything about it.

I prepared a minimal regression-tested patch here: https://github.com/relh/codex/pull/1

The regression models a configured active turn, queues a dependent follow-up, sends the terminal structured ServerOverloaded error and subsequent failed completion, then verifies no new Op::UserTurn is emitted and the queued text remains available for review. The full codex-tui suite passes (3,094 tests; 4 pre-existing skips), along with the required clippy/fmt checks.

This is complementary to the same-turn capacity retries in #31058: if retry capacity is exhausted and the turn still terminalizes, the dependent queue should remain paused. Per docs/contributing.md, I have not opened an unsolicited upstream PR. If a maintainer confirms this narrow approach and invites a contribution, the branch is ready to retarget.