Long-running Codex tasks stop mid-run with “Selected model is at capacity” and no graceful recovery

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

codex-cli 0.151.0-alpha.7.2

What subscription do you have?

pro

What platform is your computer?

No response

What issue are you seeing?

Summary

Long-running Codex tasks are repeatedly interrupted after they have already started executing commands and editing files.

The UI suddenly reports:

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

The localized Chinese message is:

所选模型已达容量上限。请尝试其他模型。

This happens while my paid ChatGPT subscription is active. I am not seeing an account-expiration or payment warning.

The problem is not simply that a new task cannot be started. An already-running task can be terminated after substantial work has been performed, without a reliable way to resume the same turn from its latest completed state.

What steps can reproduce the bug?

Steps to reproduce

1. Open ChatGPT Work / Codex on the web.
2. Select GPT-5.6 Sol.
3. Start a multi-step coding task involving shell commands, source-file edits, builds, or tests.
4. Allow the task to run for several minutes.
5. After Codex has executed commands and modified files, the active task may suddenly stop with:

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

The issue is intermittent but recurring. I captured two occurrences on August 31, 2026, at approximately 15:58 and 16:43 (UTC+8).

What is the expected behavior?

Expected behavior

Once an active task has been accepted and started, temporary model-capacity pressure should not terminate it abruptly.

Ideally, Codex should do one of the following:

• Transparently queue or retry the model request until capacity becomes available.
• Allow the Retry button to resume the same task from the last completed tool call while preserving the conversation, execution state, and worktree changes.
• Clearly distinguish account usage limits from temporary backend model-capacity problems.
• Display a request or session identifier that can be included in a bug report.

Actual behavior

The task stops before producing its final result. Commands and some file changes may already have been completed, but the remaining implementation, validation, or summary is left unfinished.

The UI only reports that the selected model is at capacity and suggests using another model. For long-running coding tasks, switching models or starting another chat can lose important execution context and makes it difficult to determine which parts of the task were completed safely.

In one occurrence, Codex had already edited 16 files with approximately +921 / -2 lines before the capacity error appeared.

Additional information

Environment

• Component: ChatGPT Work / Codex task UI on the web
• Selected model: GPT-5.6 Sol
• Operating system: macOS
• Browser: Chrome 150
• Subscription: Active paid ChatGPT subscription
• Date: August 31, 2026
• Time zone: UTC+8
• Task type: Long-running coding tasks involving commands, builds, tests, and file edits
• Frequency: Recurring across multiple task runs

Impact

This makes long-running Codex work unreliable because the failure occurs after commands and source changes have already been made.

Users must then manually inspect the worktree, determine where execution stopped, verify which changes are complete, and reconstruct the unfinished portion of the task.

For builds, benchmarks, GPU experiments, and multi-stage validation, this can also waste significant compute time.

Screenshots

Two screenshots are attached:

1. The capacity error displayed in Chinese.
2. The same capacity error displayed in English after Codex had already edited 16 files.

Suggested improvement

Please consider adding capacity-aware retry or checkpointed task resumption for active turns.

If automatic recovery is not possible, the Retry action should explicitly state whether it preserves:

• Conversation and reasoning context
• Completed tool results
• Local file changes
• Pending task steps
• The originally selected model
• The current execution environment or worktree

This may be a capacity-routing or active-task recovery issue rather than an account-subscription issue.

A separate GPU execution-context problem, where the parent shell can access NVIDIA GPUs but the Codex runner cannot, will be reported independently because it appears to involve a different subsystem.

Please let me know which session ID, diagnostic information, or sanitized logs would help investigate this issue.

Start by tracing the web Codex task lifecycle around the active task, capacity error, and Retry action. Determine how completed tool calls, conversation context, file changes, pending steps, and model selection are represented when a run stops. Done means a capacity interruption is retried or resumable without losing completed work, and account-limit errors remain distinguishable.