CodexでSelected model is at capacityが出たらまず続行する
目次
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 | 状態 | 内容 |
|---|---|---|
| #17014 | closed | maintainerが、アカウントのrate limitではなくモデル側のcapacity不足と説明 |
| #22277 | closed | 2026-05-12のincidentとして扱われ、同日中にmitigatedとコメント |
| #11635 | open | capacity bannerが出てもモデルが応答し続けるstale banner系 |
| #22390 | open | transient capacity errorをbackoff付きでretryし、task stateを保持してほしいという要望 |
| #27149 | open | 2026-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. の後、同じスレッドで続行指示を出すと作業は再開した。
その後の続行中に同じエラーが連発する形には、まだ遭遇していない。
なので、現時点の運用メモはこれになる。
- エラーが出てもスレッドをすぐ捨てない。
- 同じスレッドで続行指示を出す。
- 通らない場合だけモデルを切り替える。
- 再発するなら、Issue番号と時刻、使っていたモデル、コンテキスト圧縮の有無を残す。
このエラー文は強い。
でも、少なくとも今回の挙動では「作業終了」ではなかった。