Codex 出現 selected model is at capacity：不是你的用量上限，6 個依序處理的解法

Codex 的「Selected model is at capacity」是什麼意思？

意思是 OpenAI 針對你選的模型，伺服器已經不夠用。你的帳號沒有問題。Codex 顯示這行字，來自它開源程式碼中的同一個錯誤，也就是 codex-rs/protocol/src/error.rs 裡的 ServerOverloaded；用量上限則是另一個錯誤，用字完全不同。請拿你看到的訊息對照下表，這張表是我們在 2026 年 10 月 18 日根據該檔案整理的：

分辨的關鍵在兩個字。個人上限一定會寫「usage limit」，工作區上限會寫「credits」或「spend cap」。容量訊息兩者都沒有，也從不寫出時間，因為你的帳號根本沒有任何變化。負責在 GitHub 上回覆 Codex 問題的 OpenAI 帳號 etraut-openai，在 2026 年 5 月 12 日說得很直接：「If you receive this message, it does not mean that you are being rate limited or are out of usage. It means that we are running low on capacity to serve this model in your region.」

OpenAI 的 API 把同類的不足回報成 HTTP 503 server_is_overloaded。它的錯誤碼指南把原因寫成「The requested model is temporarily overloaded.」。Codex 使用者回報，這行字會出現在桌面應用程式、CLI、VS Code 擴充功能，以及 ChatGPT 桌面應用程式裡的 Codex。ChatGPT 本身也出現過一次：2026 年 7 月 9 日，OpenAI 針對使用者「across multiple models」遇到這個錯誤發布了事件，內容來自 Pulsetic 的副本轉載的狀態推送。

Codex 容量不足會持續多久？

單一次容量錯誤通常幾分鐘就會消失，狀態頁上最嚴重的幾天也在 3.4 小時內結束。我們在 2026 年 10 月 18 日查閱了 OpenAI 的狀態歷史。有三起事件通報了容量問題：6 月 16 日的「Codex 'Selected Model is at Capacity' Error」持續 196 分鐘，7 月 9 日的模型選擇事件持續 58 分鐘，7 月 17 日的「Codex 5.6-sol Experiencing Increased Server-Overload Errors」持續 203 分鐘。之後就沒有再通報過。

論壇上的情況時間更長。使用者在 6 月 15 日和 16 日、7 月 28 日到 30 日、9 月 7 日到 10 日和 10 月 3 日到 12 日都發文回報這個錯誤。後三波都沒有容量公告。在 9 月那一波，唯一提到 Codex 的狀態說明，是一起 25 分鐘、關於「unexpected usage limit resets」的事件。7 月有位發文者形容 GPT-5.6 Sol 超過 48 小時「almost continuously unavailable」。狀態頁一片綠燈，不代表 Codex 沒事。

從 2026 年 8 月 1 日到 10 月 16 日，OpenAI 狀態頁上標題含 Codex 的事件共 13 起。持續時間從 54 到 506 分鐘，中位數 95 分鐘，其中四起超過三小時。我們以 OpenAI 第一則更新到恢復通知之間的分鐘數計算。歷史頁面從 7 月 20 日才開始，所以 6 月和 7 月的容量事件是靠搜尋找到的，7 月 9 日那起則是從 Pulsetic 的鏡像讀取。

「Selected model is at capacity」要怎麼依序解決？

先重試一次，再換模型，然後開新的對話。在你看到這行字之前，Codex 其實已經自己重試過了。它的設定參考預設對失敗的請求重試 4 次，對中斷的串流重試 5 次。再多按十次 Enter 也幫不上什麼忙。

1. 保留提示詞。 重新載入任何東西之前先複製起來。在進行中的工作階段裡，使用者回報在同一個對話串輸入「continue」，常常能讓任務接著做下去。
2. 一分鐘後重試一次。 短暫的尖峰會自己消退，重試一次就能判斷這是不是偶發。
3. 換模型。 在 CLI 中執行 /model，或用 codex -m gpt-6-luna 啟動。在桌面應用程式和 ChatGPT Work 裡，使用輸入框下方的模型控制項。GPT-5.5 在 2026 年 10 月 14 日已不再提供給以 ChatGPT 登入的 Codex，所以不能當備用選項。
4. 用同一個模型開新對話。 OpenAI 員工 10 月在論壇上建議這麼做。執行 /new，或先執行 /compact 把摘要帶過去。
5. 查看 status.openai.com，再用 /status。 有事件點名 Codex 就代表要等。頁面正常、你的用量也還有餘裕，就表示不足出在你的模型和地區。
6. 回報問題。 在出錯的對話中執行 /feedback，並記下時間和你的時區，這是 OpenAI 員工要求的。如果 /feedback 本身也失敗，員工建議改開支援案件。

有些做法沒有用。重新安裝 Codex、刪除 ~/.codex 或購買點數，都不會增加伺服器。9 月有位發文者試過 3 個地區的 4 個 IP 位址，仍然沒用。如果所有模型都失敗，OpenAI 自己在 9 月 25 日那次中斷時的建議是「Login via API key will unblock access at this time.」。依 OpenAI 的 Codex 定價頁，API 金鑰工作階段按標準 API 費率計費，所以這條路請留給真正的死線。

容量錯誤會用掉你的 Codex 用量上限嗎？

不會。容量訊息不是用量上限，OpenAI 的工程師也說過，這不代表你「out of usage」。你可以在十秒內確認。進行中的 CLI 工作階段裡輸入 /status，會顯示目前模型和你的用量；網頁上的 chatgpt.com/codex/settings/usage 顯示同一個用量表。如果用量表還有餘裕、錯誤仍然出現，那就是容量問題。至於中途失敗的那一輪對話有沒有被計入，OpenAI 還沒有說明。

用量上限有自己的計時方式。OpenAI 的 Codex 定價頁（2026 年 10 月 18 日查閱）估計，Plus 和 Standard Business 在 GPT-6.1 Sol 上每五小時約有 15 到 160 則本機訊息。GPT-6 Astra 是 5 到 45 則，GPT-6 Luna 是 350 到 3,000 則，並補充：「Pro plans currently have no five-hour limit.」每週上限可能另外適用。所以在 Pro 方案上，如果遇到的牆從不寫「usage limit」，那是容量問題，不是每週上限。Codex 用量上限列出了各方案的時間窗，以及碰到限制時的提示訊息會提供什麼選項。

Codex 的第三個長得很像的訊息是「rate limit exceeded」，意思是請求太快。和容量訊息不同，它跟你自己的請求頻率有關，所以放慢一分鐘，同一個模型就能恢復。

為什麼付費方案的 Codex 也會碰到容量不足？

因為方案買到的是用量額度，不是保留的伺服器，而 OpenAI 是依模型和地區來分配容量。回報大多集中在新模型發表前後。發文者把 9 月那一波和 GPT-6 Astra 的發表連在一起。許多人用的是 Pro 20x 帳號，也有人說同一時間他的 Pro 5x 帳號仍能正常使用。10 月有位發文者把錯誤追溯到一個以對話命名的背景 GPT-6 Luna 請求。員工回覆說他們「can't confirm the background Luna explanation from the thread alone.」

真正的解法在 OpenAI 手上。2026 年 10 月 15 日，它的員工在論壇寫道：「We've added capacity and shipped changes today to reduce these interruptions.」要求 Codex 遇到容量錯誤時以退避方式重試的 issue #22390，從 2026 年 5 月 12 日起一直開著。在它上線之前，無人看管的任務只要碰到撐過內建重試的第一個容量錯誤就會停下。

Codex 容量不足時可以改用什麼？

改用其他廠商的模型，處理不需要你的程式庫的那部分工作。關於堆疊追蹤的疑問、重構計畫或正規表示式，都可以在 Codex 等待時丟給 Claude 或 Gemini。貼上一段任務的簡短摘要（目標、已決定的事、失敗的地方），然後繼續做。

發布本頁的 Whizi 不會取代 Codex。它沒有開發者 API，也不會碰你的程式庫。它把 GPT、Claude 和 Gemini 放在同一個對話裡：對話中切換模型，會把整個對話串交給新模型（切換如何運作），生成失敗時會退款而不是收費。Claude Sonnet 和 Claude Opus 需要每月 $29.99 的 Pro，所有方案每小時最多 60 則訊息。當不足出在 OpenAI 那邊時，就改選 Claude 或 Gemini 模型。