Selected model is at capacity appears intermittently in active session

Open 💬 2 comments Opened Jun 25, 2026 by Sachin619619
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

The app intermittently shows this error inside an active chat session:

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

This appears even when the same session can continue responding before and after the error, which makes it feel like an intermittent routing/capacity failure rather than a full session failure.

What happened

  • User sent short messages in an existing session.
  • The assistant responded normally to earlier messages.
  • A later message produced the capacity error banner: Selected model is at capacity. Please try a different model.
  • Sending another message afterward worked again.

Expected behavior

If the selected model is temporarily unavailable, the app should either retry gracefully, offer a clear fallback path, or preserve the pending user message so the user can continue without losing flow.

Actual behavior

A capacity error appears inline during an otherwise active session. The user has to retry manually or change model, even though the session itself remains usable.

Environment

  • Surface: mobile app remote-control session
  • Device shown in session: Sachins-MacBook-Pro.local
  • Date observed: 2026-06-25
  • Error text: Selected model is at capacity. Please try a different model.

Impact

This makes Codex feel unreliable for simple short-turn usage, especially when the rest of the session is still alive and responsive.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #30008
  • #30034
  • #29760
  • #28514
  • #28509

Powered by Codex Action

Sachin619619 · 2 months ago

Please prioritize a fix for this issue. When this error appears repeatedly, Codex becomes difficult to use for normal workflows because even simple messages can fail unexpectedly.

A graceful retry or fallback would make the experience much more reliable.