英語版で読む
技術約14分で読めます

CodexでSelected model is at capacityが出たらまず続行する

OpenAICodexトラブルシューティングAIエージェントCLI
いけさん目次

TL;DR

症状 Codexで Selected model is at capacity. Please try a different model. が表示され作業が停止（capacity はコンテキスト容量でなくモデル側の処理枠）

回避 対話運用なら、モデルを変えず同じスレッドで続行を指示（多くはそのまま再開）

制限 無人・ループ運用（オーバーナイトの自律実行など）では手動続行が効かない。自動リトライは2026年8月時点で入っているが、9月7日からはアカウント単位で全モデルがこのエラーになる報告が出ていて、クライアント側の操作で消せたという確認はない（末尾の2026年9月8日時点の続報）

2026-09-08続報: 9月7日からは、同じユーザーでGPT-6 Astra、GPT-5.6全3種、GPT-5.5が全部このエラーになったという報告が出ている。別の報告ではロールアウトログが失敗ターンを server_overloaded と記録していてクォータ使用率は0%で、さらに別の報告者は同じマシンの別Proアカウントなら動いた。詳細は 2026年9月8日時点の続報 に追加した。GPT-5.6 Solの波は 2026年9月3日時点の続報 にある。

Codexで作業中に Selected model is at capacity. Please try a different model. が出た。
手元ではほぼ初遭遇に近い。コンテキスト圧縮は入っていなかったし、スレッド自体が壊れた感じもなかった。

そのまま同じスレッドで次のように送った。

止まらずに続けろ

結果として、Codexは何事もなかったように作業を続けた。
続行中に同じエラーがもう一回出る形には、この記事を書いている時点では遭遇していない。

この挙動を見ると、エラー文だけでスレッドを捨てるのは早い。
少なくとも自分のケースでは、一回のモデル呼び出しが弾かれただけで、作業状態や文脈は残っていた。

capacityはコンテキスト容量ではない

この文言の capacity は、文脈長やコンテキスト圧縮ではなく、モデル側の処理枠の話として読む。
今回もコンテキスト圧縮は走っていなかった。

近いGitHub Issueを見ると、OpenAI側のコメントで「アカウント個別のrate limitではなく、そのモデルのcapacity不足」という説明が出ている。
該当するのは openai/codex #17014 だ。

なので、ここでのcapacityは次のような話になる。

選択中のモデルを処理するサーバー側に空き枠がない

「容量」という語からコンテキスト上限や残りトークンを連想しやすいが、少なくともこのエラーについては別物として見たほうがいい。
Codex側のスレッド状態が残っていれば、次のリクエストが通った時点でそのまま再開できる。

閉じたIssueと残っているIssueが混ざっている

このエラーまわりは、Issueの状態を分けて読む。
同じ文言でも、短時間の障害報告、stale banner、リトライ機構の要望が混ざっている。

以下は2026年6月11日JST時点の状態だ。

Issue状態内容
#17014closedmaintainerが、アカウントのrate limitではなくモデル側のcapacity不足と説明
#22277closed2026-05-12のincidentとして扱われ、同日中にmitigatedとコメント
#11635opencapacity bannerが出てもモデルが応答し続けるstale banner系
#22390opentransient capacity errorをbackoff付きでretryし、task stateを保持してほしいという要望
#27149open2026-06-09時点のgpt-5.5 capacity errorとセッション復帰時の文脈残量に関する報告

つまり「5月12日の障害はmitigatedで閉じた」と「capacity error時のリトライや状態保持はまだ要望として残っている」は両立する。
手元で起きた「続行指示で復帰できた」は、#11635 のstale banner系や、#22390 のstate retention要望に近い話として読める。

まず同じスレッドで続行する

実務上の初動は、スレッドを閉じないことだ。
Codexが作業途中でこのエラーを出しても、作業状態が残っているなら次の入力で再開できる。

手元では、短く強めに続行指示を出しただけで戻った。

止まらずに続けろ

もう少し丁寧に書くなら、こうでもよい。

直前の作業を続行して。現在の状態を確認して、未完了の手順から再開して。

これで通らない場合だけ、モデル切り替えを考える。
Codex CLIなら /model、新しいセッションなら codex -m <model> でモデルを指定できる。Codexのモデル選択については、公式ドキュメントの Codex Models にも記載がある。

ただし、途中でモデルを変えると出力の判断基準も少し変わる。
品質を落としたくない作業なら、まず同じモデルで一回再送し、それでも通らない時だけ別モデルへ逃がすほうが扱いやすい。

放置で最後まで任せられるかは別問題

CodexもClaude Codeも、扱えるコンテキストは大きくなっている。
自動処理で複雑な作業を投げられる範囲も広がっている。

ただ、今回のようなcapacity errorや、以前書いたClaude Codeでcourtが出てツール呼び出しが止まるのようなツール呼び出しの崩れを見ると、本当の意味で放置して最後まで完走できるかはまだ別の話だ。

コンテキストが大きいことと、長時間の無人運用に耐えることは同じではない。
途中で一回だけユーザーが「続けろ」と言えば戻るとしても、その一回が必要な時点で完全な放置運用ではない。

長いタスクを任せるなら、今のところは作業を小さく切る、進捗をファイルやgit diffに残す、止まった時に再開しやすい指示を添える、くらいの運用が現実的だと思う。

いまの観測範囲

この記事で言えるのは、手元の一回の観測と、公開Issueから読める範囲までだ。

自分のケースでは、コンテキスト圧縮は入っていなかった。
Selected model is at capacity. Please try a different model. の後、同じスレッドで続行指示を出すと作業は再開した。
その後の続行中に同じエラーが連発する形には、まだ遭遇していない。

なので、現時点の運用メモはこれになる。

  1. エラーが出てもスレッドをすぐ捨てない。
  2. 同じスレッドで続行指示を出す。
  3. 通らない場合だけモデルを切り替える。
  4. 再発するなら、Issue番号と時刻、使っていたモデル、コンテキスト圧縮の有無を残す。

このエラー文は強い。
でも、少なくとも今回の挙動では「作業終了」ではなかった。

2026-07-01時点の続報

この記事の回避策「同じスレッドで続行を指示する」は、人が画面を見ている対話運用が前提だ。長時間の自律ループやオーバーナイトの無人運用では、その手動操作ができないため capacity エラーで止まったままになる。
Codexには capacity エラーに対する自動リトライがまだない。#22390 は「長時間タスクを一晩放置しても、一時的な capacity は自動でリトライ＋状態保持で乗り切ってほしい」という要望で、7/1時点でオープン。現状は「モデルを変えろ」の表示が出るだけで、ユーザーが手動でリトライループを回す形になっている。
#22277 では、事前のサーバー健全性チェックがなくパイプライン途中でクラッシュする点が指摘されている。無人でCodexを回すなら、capacity エラーを検知して自前でリトライ・再開する仕組みを外側に用意しておくほうが安全だ。

2026年9月3日時点の続報

8月31日以降のGitHub報告

2026年8月31日から、このエラーの報告がGitHubに集中している。#41790（ChatGPT Pro、15分のタスクで3回停止）を筆頭に、#41810、#41805、#41798、#41808、#42169 が8月31日から9月2日の間に立ち、9月3日時点でどれもオープンのままだ。
対象モデルは報告のほぼ全部が GPT-5.6 Sol で、Codex CLI 0.144.1 から 0.151.0 系、Codex Desktop の 26.825 と 26.826 の両方で起きている。5時間枠が92%、週次が81%残っていても出たという報告があり、クォータ切れではなくモデル側の処理枠という6月の見立てはそのままだ。
OpenAIのステータスページには8月31日に ChatGPT Workのエラーと遅延 が載っているが、GPT-5.6 Solや capacity を名指ししたインシデントは見当たらなかった。

Issue立った日環境内容
#417908月31日Codex App、Pro15分のタスクで3回停止、リトライの秒読みが117秒
#417988月31日Desktop 26.825、Windows自動リトライは通るがGoalが paused のまま
#418058月31日CLI 0.144.1、macOS、Plus1日10回以上、再起動や codex resume で直らない
#418088月31日Desktop、macOS、Proupdate_goal なしにGoalが blocked に変わる
#418108月31日CLI 0.151.0-alpha.7.2、Pro実行中のタスクが途中で止まり、同じターンから再開できない
#421699月2日Desktop 26.826、Windows、Plus通常のプロンプトでも繰り返し出る

自動リトライの挙動

7月1日の続報で「まだない」と書いた自動リトライは、今は入っている。エラーの後にリトライまでの秒読み（117秒など）が表示され、#41790 のコメントによれば発生回数を重ねるほど待ち時間が伸びる。
ただしリトライが通っても数分後にまた同じエラーで止まり、結局ユーザーが続行を送っているという報告が複数ある。25分で8回という人もいる。
自動リトライと状態保持の要望 #22390 は8月31日にコメントが付き、まだオープンのままだ。

Desktopの goal 側の症状

自動リトライが通ってターン自体は再開しても、Goalが paused のまま戻らない（#41798、Windows）。macOS側の #41808 では、エージェントが update_goal を呼んでいないのにGoalの状態が blocked に書き換わっていて、同じログで full_context_window_limit_reached=false、token_limit_reached=false が出ている。
goal の夜間実行が朝止まっていたとき、原因にはこのサーバー側の処理枠のほかに、端末側の suspended (tty input) もある。端末側のほうは Codexが suspended (tty input) で止まる原因をMac miniで調べた にまとめた。

2026年9月8日時点の続報

9月7日以降に報告されたモデルとIssue

9月7日からは、同じユーザーの環境でGPT-6 Astra、GPT-5.6のSol、Terra、Luna、GPT-5.5が全部 Selected model is at capacity を返し、モデル切り替えや新規セッションでは安定して消えない（#43398、#43368、#43688）。#43337 のコメントには再ログイン後も続いたという人がいる。まだ応答すると報告されているのは標準の推論レベルの gpt-5.4-mini（#43398）と codex-5.3 系（#43682）だけだ。
この文言のIssueは9月7日から8日午前（UTC）までに10件立ち、9月3日時点の6件も全部オープンのまま。10件中8件がChatGPT Proアカウントで、7件がCodex CLI 0.153.4かDesktop 26.901、1件がVS Code拡張 26.901、2件はクライアントのバージョン記載なし。9月8日JST時点で10件のどれにもOpenAI側のコメントは付いていなくて、似た報告を重複候補として挙げるボットが、コメント欄で互いを紐づけている。

Issue立った日環境内容
#433379月7日CLI 0.153.4、macOS・Linux・Windows、Pro 20x片方のProアカウントだけAstraとLunaでエラーになり、同じマシンのもう片方のProアカウントは動く
#433689月7日Desktop 26.901、macOS、Pro 20xTerra、Luna、Sol、Astraが全部エラーになる。使用量は約80%残り
#433759月7日Codex、バージョン記載なしAstraとGPT-5.6系を順に切り替えてもエラーになる。UIにリクエストIDを出してほしいと要望
#433989月7日CLI 0.153.4、Ubuntu 22.04、Pro 20xAstra、Sol、Terra、Luna、GPT-5.5がエラーになり、標準の推論レベルのgpt-5.4-miniだけ安定して動く
#435179月7日CLI 0.153.4、macOS、ProAstraのWebSocketが毎ターン、サーバー側から切られ、HTTPフォールバックも5xx。同じマシンでSolは動く
#436389月8日Desktop 26.901、Windows、Pro 20xSol、Terra、Lunaはcapacity、Astraは代わりに invalid_prompt を返す
#436639月8日VS Code拡張 26.901、Linux、Pro 20x1セッション9タスク中8タスクが server_overloaded で終了
#436829月8日Codex、バージョン記載なしgpt-5.5、5.6、6、5.4-miniが全部エラーになり、codex-5.3だけ答える
#436889月8日App 26.901とCLI 0.153.4、macOSとWindows、Pro全モデル・全推論レベルでエラーになり、Retryボタンでも消えない
#437009月8日Desktop（CLI 0.153.4同梱）、macOS、Pro 20x9月7日に server_overloaded が65回。止められたターンは平均85秒動いていた

ロールアウトログに残る値

3件の報告が、Codexがセッションごとに残すロールアウトログかセッションログを開いている。失敗したターンは全部 codex_error_info: "server_overloaded" で、同じファイルの使用量スナップショットは plan_type: pro、used_percent: 0.0、rate_limit_reached_type: null（#43700、#43663。#43368は used_percent = 20.0）。
リクエストは入口で弾かれてはいない。9月6日に#41790のコメントへ付いたGPT-6 Ultraの報告は、3時間48分走って24ファイル編集した後にこのメッセージで止まっている。9月7日の#43700では止められたターンが平均85秒、最長275秒動いてからこのエラー表示が出ていて、#43663は server_overloaded の前に339〜482出力トークンが生成されている。
#43517はgpt-6-astraの通信側を記録している。chatgpt.com/backend-api/codex/responses へのWebSocketは接続でき、15〜20秒後に response.completed の前にサーバー側から切られ、Codexはサンプリングを5回再試行してHTTPへフォールバックし、そのHTTPも失敗した。

同じマシンの2アカウント比較

#43337 は同じマシンから2つのPro 20xアカウントで、次の1行の codex exec を打っている。

codex exec --ignore-user-config --ephemeral --skip-git-repo-check \
  -C /tmp -s read-only -m gpt-6-astra \
  -c 'model_reasoning_effort="low"' --json \
  'Reply with exactly OK. Do not use tools.'

$CODEX_HOME/config.toml を読み込まない使い捨てタスクなので、これがエラーで止まるなら、既存のスレッドやその設定ファイルに固有の問題ではない。バックエンド側の何が悪いかまでは分からない。
片方のアカウントはgpt-6-astraとgpt-5.6-lunaでcapacityが返り、もう片方は答えた。同じIssueのコメント欄でも2人が同じ比較を再現していて、同じPC・同じ回線・同じクライアントで片方のアカウントだけエラーになる。うち1人は、エラーになる側のアカウントへ戻すとエラーも戻ったと書いている。
片方のアカウントだけエラーになる形は、モデル側の処理枠が埋まっているという6月の説明と合わない。OpenAI側の説明はまだない。

失敗時は {"type":"turn.failed","error":{"message":"Selected model is at capacity. Please try a different model."}} で終わる。

ステータスページ

OpenAIのステータスページには9月3日の Elevated errors across ChatGPT and Codex（14:58〜16:55 UTC）と、9月4日のCodex Cloudを含む APAC地域のエラー増加 が載っていて、どちらも解決済みだ。9月7日と8日のインシデントはなく、9月8日14:00 JST時点で All Systems Operational の表示になっている。
このエラー自体は過去にインシデントとして掲載されたことがあり、6月16日の Codex “Selected Model is at Capacity” Error と7月17日の Codex 5.6-sol Experiencing Increased Server-Overload Errors がある。

6月の初動との関係

自動リトライが通ってスレッドが残っている場合は、6月と同じで、同じスレッドに続行を送りスレッドを捨てない。作業が進んだという報告は、gpt-5.4-miniへ切り替えた分、同じマシンで動くほうのアカウント、#43517でSolだけ動いた環境、#43682のcodex-5.3、それにエラーの波の合間に動いた分だ。85秒動いてから打ち切られたターンごと作業が消えないよう、進捗はファイルか git diff に残しておく。

参考