Codex: Selected model is at capacity. 模型容量已滿排查
這個提示通常表示目前選中的 Codex 模型或模型路由暫時沒有可用容量。它不是 429，也不優先指向 API Key 寫錯；先區分官方 Codex 登錄態、中轉站帳號池和 Sub2API 錯誤透傳，再決定是換模型、等待恢復、開啟有上限重試，還是反饋給服務商。
錯誤摘要
報錯：Selected model is at capacity. Please try a different model. 先把它當作模型級容量、Admission 或串流中斷問題處理。它可能出現在官方 ChatGPT 登錄態 Codex CLI，也可能來自中轉站帳號池或 Sub2API 上游 overloaded 透傳。
這個錯誤是什麼意思
Selected model is at capacity. Please try a different model. 的重點是 selected model。請求沒有優先失敗在認證層，而是目前選中的模型、模型分組或上游路由沒有足夠可用容量。
如果你使用的是官方 Codex 登錄態，它可能是 OpenAI 側模型容量高峰。如果你通過中轉站、Sub2API、CPA、NewAPI 或團隊網關接入，它也可能是中轉站背後的帳號池、模型映射或分組路由沒有可用出口。
別把它粗暴理解成「Codex 壞了」。更準確的判斷是：目前模型通道暫時調度不到資源。
社群已有不少同類反饋：即使 /status 裡還有上下文和額度，也可能觸發這個提示。先把它當作模型容量或路由調度問題，不要第一反應就改 API Key 或查餘額。
在一些 Sub2API 場景裡，使用者觀察到上游原始失敗更接近 Our servers are currently overloaded，中間層再把錯誤透傳成 Codex 裡的 at capacity 提示。問題不只是失敗本身，而是 Codex 收到這類提示後可能不會自動續跑，於是長任務被頻繁打斷。
常見原因
- 目前 Codex 模型處在高峰期，尤其是平台推薦遷移到新模型後，新模型更容易出現臨時 Admission 失敗。
gpt-5.4、gpt-5.3-codex這類 Codex 相關模型可能有獨立容量池，剩餘額度不等於目前模型一定能調度成功。- 同一個模型在 ChatGPT 普通對話裡可用，但 Codex 的連接被拒，說明 Codex 可能走不同的 Admission、工具調用或模型路由。
- 中轉站把你選的模型映射到一個已滿載、限流或冷卻中的上游帳號池。
- SSE 串流請求中途斷開，客戶端把上游 overloaded 或 stream 失敗展示成 at capacity。
- 同一個帳號、同一個 Key 或同一個 provider 同時跑多個 Codex 會話，擠佔了可用容量。
先判斷你屬於哪種場景
如果你用的是官方 ChatGPT 登錄態，先換模型測試：從 gpt-5.4 切回 gpt-5.3-codex，或等幾分鐘後重試。不要先改 Key。
如果你用的是中轉站、Sub2API、CPA 或 NewAPI，先用同一 Base URL、Key、模型名發最小請求，再換模型。最小請求也失敗，看帳號池和上游容量；只有長任務失敗，再看上下文、串流輸出和工具調用。
怎麼快速處理
- 先換模型。優先從
gpt-5.4切回gpt-5.3-codex或另一個穩定模型，確認是不是單模型容量問題。 - 等 1 到 5 分鐘再重試。容量類錯誤通常是臨時狀態，立刻連續重試意義不大。
- 降低目前任務的上下文壓力：新開會話、減少附帶文件、縮小修改範圍，或先讓 Codex 處理更小的步驟。
- 如果你使用 Codex 的
/goal能力，可以把目標拆清楚，讓客戶端在中斷後更容易續跑。但這只是降低人工接管成本，不是解決上游容量。 - 如果你使用中轉站，切換模型分組、備用線路或 provider，並讓服務商確認這個模型是否真的有可調度帳號。
Sub2API 裡的緩解辦法
如果你自建或管理 Sub2API，可以嘗試在帳號管理裡的錯誤透傳規則中，把包含 Our servers are currently overloaded 或 at capacity 的上游錯誤改寫成客戶端會觸發自動重試的錯誤文本，例如 upstream failed。
常見配置思路是：錯誤碼保持空，關鍵詞填 Our servers are currently overloaded、at capacity，匹配模式選擇「錯誤碼或關鍵詞」，自定義錯誤信息填 upstream failed 或類似可重試文本。
這個做法的價值是降低長任務被中斷的頻率，不是讓模型容量憑空變多。重試次數必須有上限，並且要觀察消耗、失敗率和是否進入循環。把所有 capacity 錯誤都吞掉，只會讓你看不見真實容量問題，還可能把餘額燒在無效重試上。
NewAPI 場景要更謹慎。社群反饋裡提到 NewAPI 更常見的是狀態碼覆寫，不一定能像 Sub2API 一樣精細改寫這類上游錯誤文本。不要為了追求自動重試，把所有錯誤都改成同一個可重試錯誤。