[Feature]: Surface Codex model capacity errors in T3 Code

[coygeek]

Problem or use case

When the Codex provider reports that the selected model is at capacity, T3 Code can leave the conversation looking like it is still working without exposing the provider's explanation. The Codex client displays a direct message such as Selected model is at capacity. Please try a different model. and offers recovery, while the T3 Code view in the supplied example does not show an equivalent capacity state.

This request is specifically for the Codex provider. A capacity response should be distinguished from ordinary model processing, tool execution, authentication errors, quota or rate-limit errors, and silence. The UI should use an explicit provider signal rather than infer capacity from elapsed time.

Proposed behavior

When Codex reports a capacity condition for a turn:

• Show an actionable capacity notice in the affected conversation, preserving the provider's guidance when available.
• If an automatic retry is actually pending or in progress, show that retrying state alongside the capacity explanation.
• If the turn has stopped or retries are exhausted, stop presenting it as actively working and show the stopped or failed state.
• Let the user retry or choose another model through existing recovery controls without silently changing the model or submitting a duplicate turn.
• Persist the notice on the affected turn when the user navigates away and returns.
• Keep later successful attempts separate so an earlier capacity notice does not make a recovered turn look failed.

Smallest useful scope

Codex adapter-to-UI propagation and presentation of explicit capacity errors, with accurate Working/retrying/stopped state and recovery through existing retry or model-selection controls. Other providers and automatic model fallback are out of scope.

Acceptance criteria

• A controlled Codex capacity response produces a visible notice in the T3 Code conversation without requiring diagnostic logs.
• The notice says the selected model is at capacity and includes provider guidance to try another model when supplied.
• A real retry is visible as retrying; a terminal failure or exhausted retry is no longer shown as actively working.
• Retry and model selection preserve the prompt and conversation and do not duplicate submission or silently switch models.
• Navigating away and back retains the explanation; a later successful attempt has accurate independent state.
• Slow successful responses, active tools, authentication failures, and quota/rate-limit errors are not mislabeled as capacity.
• Focused verification covers retrying, terminal failure, and successful recovery without depending on a live provider outage.

Related discussions and issues

• Related status-clarity proposal: Show provider retries and last parent output alongside Working #10941
• Earlier Codex capacity report: [Bug]: Selected Model is at capacity flag with 5% Codex Capacity Remaining #1396

The request is intentionally limited to user-visible handling of an explicit Codex capacity response; it does not claim that every apparently stuck turn is caused by capacity.