Codex does not seem to incorporate transient model-capacity errors into follow-up planning

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

26.519.41501 (3044)

What subscription do you have?

business

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

When Codex encounters an error such as:

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

it does not seem to use that failure as part of its follow-up reasoning.

In my case, this comes up during tasks where Codex is running a local program that produces a very large amount of log output. If I then ask Codex to try again, it may repeat the same approach and run into the same failure pattern again, instead of adapting its strategy.

I am not sure whether this is because the capacity error itself is not being included in the model-visible context, or because the retry behavior is not using that signal effectively. But the result is that Codex can get stuck retrying the same shape of attempt, even when a different approach would likely work better.

For example, after a failure like this, a better recovery strategy might be:

• redirect program output to a local file
• inspect only the tail or selected portions of the log
• summarize or chunk the output before sending it back into the model context
• otherwise reduce how much raw output is pushed into the conversation

What steps can reproduce the bug?

1. Ask Codex to run a local program that emits a very large amount of log output.
2. Wait until Codex encounters an error such as Selected model is at capacity. Please try a different model.
3. Ask Codex to try again.
4. Observe that Codex may repeat the same strategy instead of switching to a more output-efficient approach.

What is the expected behavior?

Capacity-related failures should be available as part of Codex’s subsequent reasoning, so that retries can adapt their strategy. For example, Codex could automatically prefer approaches that reduce context pressure or avoid flooding the conversation with raw logs.

Additional information

Why this matters

When Codex is working with noisy local programs, repeating the same strategy can waste turns and make recovery harder. Even if the original error is transient, it would still be useful for Codex to treat it as a signal to try a more context-efficient approach on the next attempt.

Possible direction

If not already happening, it may help to make certain runtime/model errors available in the next-turn context, especially when they are relevant to planning the retry strategy.