Selected model is at capacity
這個提示通常表示目前選中的 Codex 模型或模型路由暫時沒有可用容量。它不優先指向 API Key 寫錯，也不一定是本地配置壞了；先換模型、等待恢復或讓中轉站確認模型通道容量。
錯誤摘要
報錯：Selected model is at capacity. Please try a different model. 先把它當作模型級容量或路由擁塞處理：換模型、等待一段時間、降低上下文，使用中轉站時讓服務商確認帳號池和模型分組。
這個錯誤是什麼意思
Selected model is at capacity. Please try a different model. 的重點是 selected model。請求沒有優先失敗在認證層，而是目前選中的模型、模型分組或上游路由沒有足夠可用容量。
如果你使用的是官方 Codex 登錄態，它可能是 OpenAI 側模型容量高峰。如果你通過中轉站、Sub2API、CPA、NewAPI 或團隊網關接入，它也可能是中轉站背後的帳號池、模型映射或分組路由沒有可用出口。
別把它粗暴理解成「Codex 壞了」。更準確的判斷是：目前模型通道暫時調度不到資源。
OpenAI Developer Community 在 2026-04-23 已有同類報告：使用者提到使用 gpt-5.4 時持續出現這個提示，後續也有人反饋 Codex Desktop macOS / Windows 的長時間工作流會被突然打斷。這個現象更像 Codex 客戶端、模型容量和串流穩定性疊加出來的問題，不是標準 HTTP 429。
在一些 Sub2API 場景裡，使用者觀察到上游原始失敗更接近 Our servers are currently overloaded，中間層再把錯誤透傳成 Codex 裡的 at capacity 提示。問題不只是失敗本身，而是 Codex 收到這類提示後可能不會自動續跑，於是長任務被頻繁打斷。
常見原因
- 目前 Codex 模型處在高峰期，服務端建議切換到其他模型。
- 中轉站把你選的模型映射到一個已滿載、限流或冷卻中的上游帳號池。
- API Key 所在分組沒有可用的 Codex 模型供應商，或該模型只對部分套餐開放。
- 目前任務上下文太長、工具調用太多，導致高成本模型更容易被容量限制攔住。
- 同一個帳號、同一個 Key 或同一個 provider 同時跑多個 Codex 會話，擠佔了可用容量。
怎麼快速處理
- 先換一個可用模型。不要死磕同一個高峰模型，尤其是 Codex 專用模型、pro 模型或高 reasoning 檔位。
- 等 1 到 5 分鐘再重試。容量類錯誤通常是臨時狀態，立刻連續重試意義不大。
- 降低目前任務的上下文壓力：新開會話、減少附帶文件、縮小修改範圍，或先讓 Codex 處理更小的步驟。
- 如果你使用中轉站，切換模型分組、備用線路或 provider，並讓服務商確認這個模型是否真的有可調度帳號。
- 如果你使用官方 Codex App 或 VS Code extension，保留截圖、時間、模型名和 request id，再通過 Codex 的反饋入口或 GitHub issue 報告。
- 如果所有模型都失敗，再檢查 OpenAI 狀態頁、中轉站狀態頁、餘額、套餐權限和 Base URL 配置。
Sub2API 裡的緩解辦法
如果你自建或管理 Sub2API，可以嘗試在帳號管理裡的錯誤透傳規則中，把包含 Our servers are currently overloaded 或 at capacity 的上游錯誤改寫成客戶端會觸發自動重試的錯誤文本，例如 upstream failed。
這個做法的價值是降低長任務被中斷的頻率，不是讓模型容量憑空變多。重試次數必須有上限，並且要觀察消耗、失敗率和是否進入循環。把所有 capacity 錯誤都吞掉，只會讓你看不見真實容量問題，還可能把餘額燒在無效重試上。
和 429、503 有什麼區別
429 更偏向請求頻率、額度或限流；503 更偏向服務不可用或帳號池沒有可用出口。
Selected model is at capacity 不是 429。它更具體地指向「目前選中的模型或上游模型路由沒有容量」，有時底層表現是上游 overloaded 或串流請求中斷。所以第一反應應該是換模型、換模型路由或做有上限的自動重試，而不是先改 API Key、重裝 Codex，或者盲目遷移整個 provider。
這裡有個容易自欺的點：如果你在用中轉站，這個提示不一定證明官方 Codex 不穩定，也可能只是你的中轉站把熱門模型賣超了。先做最小請求和換模型測試，再判斷是不是 provider 層面的容量問題。