Work mode repeatedly returns “Selected model is at capacity” on GPT-5.5+ while Chat mode works normally

What subscription do you have?

ChatGPT Pro

What platform are you using?

Windows / Codex desktop workflow

What issue are you seeing?

There appears to be a mode-specific capacity/routing problem affecting higher-tier models in Codex/Work.

On the same account and same machine, ordinary Chat mode works normally and does not show obvious latency/capacity problems. However, as soon as I switch to Work mode and select GPT-5.5 or newer models, requests repeatedly fail with:

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

This is not an occasional single failure. In Work mode it can happen repeatedly enough to make the mode effectively unusable, while Chat mode continues to work normally.

The key observation is therefore not simply that a model is temporarily at capacity, but that availability differs strongly by execution mode for the same account:

Same account / same machine

Chat mode  -> works normally
Work mode  -> GPT-5.5+ repeatedly returns capacity errors

This pattern suggests that the problem may be in the Work/remote-task scheduling, model routing, admission-control, worker pool, or remote compaction path rather than a global lack of model capacity.

Steps to reproduce

1. Sign in to Codex/ChatGPT with the same account.

2. Use normal Chat mode and send ordinary prompts. The conversation works normally.

3. Switch to Work mode.

4. Select a model in the GPT-5.5-or-newer range.

5. Start a task.

6. Work mode repeatedly returns:

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

7. Return to Chat mode on the same account; Chat remains usable.

Expected behavior

If the selected model is available to the account, Work mode should be able to start and continue tasks reliably.

If Work and Chat use different serving pools or admission-control paths, temporary Work-side capacity problems should ideally be handled with automatic retry/backoff and preserved task state rather than repeatedly terminating the user's task.

The UI should also distinguish between:

• actual global model capacity,
• Work-specific worker/remote-task capacity,
• account entitlement or routing problems,
• quota/rate-limit exhaustion,
• remote compaction failures.

At the moment they can all surface to the user as the same generic capacity message, which makes local troubleshooting misleading.

Why this seems important

Because Chat mode continues to work normally on the same account, repeatedly reinstalling Codex, clearing local configuration, or changing local project state does not appear to address the underlying issue.

This also appears related to other recent reports involving the same error, including #43337, #43670, #42169, and the broader retry/state-preservation request in #22390.

Additional information

Observed on September 8, 2026.

I can provide additional diagnostics (Codex version, Feedback ID/request IDs, screenshots, or a codex doctor report) if maintainers need them. The most useful distinguishing symptom is the reproducible Chat works / Work fails on GPT-5.5+ behavior on the same account.

Start by reproducing the same-account comparison between Chat mode and Work mode on GPT-5.5-or-newer models. Collect the Codex version, Feedback ID or request IDs, screenshots, and codex doctor report offered in the issue, then compare related reports #43337, #43670, #42169, and #22390. Done should identify whether the failure is Work-specific capacity, routing, entitlement, quota, or remote compaction and define the appropriate user-visible behavior.