Repository navigation
Long-running Codex tasks stop mid-run with “Selected model is at capacity” and no graceful recovery #41810
Description
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
- Open ChatGPT Work / Codex on the web.
- Select
GPT-5.6 Sol. - Start a multi-step coding task involving shell commands, source-file edits, builds, or tests.
- Allow the task to run for several minutes.
- 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:
- The capacity error displayed in Chinese.
- 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.
Activity
github-actions commentedon Aug 31, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
itwasmatias commentedon Aug 31, 2026
@chengcuiping — the recovery problem you described is very close to something I’ve been working on with MissionaryX: determining what actually landed after an AI coding task is interrupted, preserving valid work, and establishing a verified point from which the task can safely continue.
I can’t diagnose or change OpenAI’s backend capacity behavior, but I could take a look at one affected worktree/run and help reconcile the changes that actually landed, identify incomplete or uncertain work, define a safe recovery/checkpoint boundary, and provide verification evidence for continuing the task.
If that would be useful, I’d be happy to coordinate.
chengcuiping commentedon Sep 1, 2026
Thanks — a sanitized reconciliation would be useful. Could you first outline the exact artifacts you need and whether you can work from a redacted git diff, command timeline, and test outputs only? I can’t share raw Codex logs or private repository contents. Ideally, the result should produce a reproducible recovery checklist or evidence that can be added to #22390.
itwasmatias commentedon Sep 1, 2026
Yes — I can work from a redacted Git diff, command timeline, and test outputs only. I do not need raw Codex logs, credentials, or private repository contents.
For one bounded interrupted run, the minimum useful artifacts would be:
From that evidence, I would aim to produce:
The scope can stay limited to one interrupted run/worktree, and I would not need access to the private repository itself.
If that evidence set and scope work for you, we can use that as the basis for the check.
chengcuiping commentedon Sep 2, 2026
Thanks. I completed the bounded read-only recovery audit and am sharing the final sanitized result here.
One scope clarification: this recovered run stopped at a GPU execution-context gate rather than a model-capacity error. It should therefore be treated only as evidence about post-interruption state reconciliation, not as a reproduction of the backend capacity problem reported in this issue.
The interruption report stated that no worktree had been created and no code had been modified. Filesystem evidence contradicted that report:
a dedicated worktree had been created;
a rebase had completed, producing two local rebase-related commits;
the recovered worktree HEAD was
5db1db8e9c11c9d8646bcbd565b305f91227f1c4;seven tracked files contained uncommitted modifications:
tests/test_config.pytests/v1/test_outputs.pytests/v1/worker/test_gpu_rejection_sampler_chunking.pyvllm/config/vllm.pyvllm/v1/worker/gpu/sample/output.pyvllm/v1/worker/gpu/sample/sampler.pyvllm/v1/worker/gpu/spec_decode/rejection_sampler.pyThe pre-run PR head available to the audit was
1304ed77631961a37bcfe604606a215099fcb485.No build or test artifacts attributable to this interrupted run were preserved. The original command/tool timeline, the intent and authorship of individual changes, test outcomes, and any attempted remote actions could not be recovered reliably. I have not inferred or reconstructed those missing details.
The safe recovery boundary is therefore to preserve the recovered worktree, treat all seven modifications as unverified, review the diff against the known PR head, and rerun the required correctness and regression tests before committing, pushing, or making any remote PR changes.
This is the final evidence summary for this run. Because it is not a clean capacity-error reproduction, I will not present it as capacity-specific evidence for #22390, and I do not plan to perform further reconstruction for this case.