exceeded retry limit, last status: 429 Too Many Requests が出たら、まず同じ操作の連打を止めてください。この表示から分かるのは、Codex側の再試行が上限に達し、最後に観測した応答がHTTP 429だったことまでです。ChatGPTアカウントの利用枠、OpenAI APIのレート制限や請求、外部のモデルプロバイダーのどれが原因かは、この一行だけでは決まりません。
最短で復帰する鍵は、「何分待つか」を推測することではなく、429を返した経路を先に特定することです。利用経路が分かれば、見るべき画面、待機が有効な条件、利用者側の修正が必要な条件を切り分けられます。
まず保存し、再試行を止める
ターミナルやアプリを閉じる前に、次の情報を保存します。
- エラー全文と発生時刻（タイムゾーンを含む）
- 実行していた操作と、同じ操作が直前まで成功していたか
- ChatGPTでサインインしているか、APIキーを使っているか、外部プロバイダー／ゲートウェイを設定しているか
- 表示されていれば、HTTPヘッダー、エラーcode、request ID
- 直前にモデル、認証、設定、組織、プロジェクト、請求方法を変更したか
APIキー、アクセストークン、Cookie、認証ヘッダー、社内URLは、そのままスクリーンショットや問い合わせ文に含めないでください。値を伏せても、時刻、項目名、エラーcode、request IDは診断材料として残せます。
自動再実行を組んでいる場合は、いったん停止します。429の原因が残高や支出上限なら、繰り返しても回復しません。一時的な速度制限でも、待機なしの再試行は失敗リクエストを増やし、原因の切り分けを難しくします。
429を返した利用経路を特定する
次の3経路は、同じCodex画面から使っているように見えても、制限の管理場所が異なります。
| 利用経路 | 最初に確認する信号 | ここからは断定できないこと |
|---|---|---|
| ChatGPTアカウントでCodexにサインイン | Codex TUIの /usage、現在のプランと利用可能量 | API組織のレート制限や残高 |
| OpenAI APIキー | エラーpayload、Retry-After、request ID、組織・プロジェクト・モデルのlimitsと請求 | ChatGPTプランのCodex利用枠 |
| カスタムプロバイダー／ゲートウェイ | Codexのプロバイダー設定、ゲートウェイのログ、上流のレスポンスと制限 | OpenAIが直接返した429かどうか |
ChatGPTアカウントで使っている場合
Codex TUIでは、/usage がChatGPTアカウントの日次・週次・累積のトークン利用状況を確認するための公式コマンドです。表示内容と利用可能な操作はアカウントによって異なり得ます。詳しくはCodexの組み込みスラッシュコマンドを確認してください。
Codexの消費量は、単純なメッセージ件数では一定になりません。モデル、タスクの規模や複雑さ、コンテキスト、推論、ツール利用、検索、キャッシュなどに左右されます。また、対象プランではローカルメッセージとクラウドチャットが5時間枠を共有し、追加の週次制限が適用される場合があります。値や対象は変わり得るため、現在のCodex利用枠を自分のプランに合わせて確認します。
/usage に余裕が見えても、それだけで「利用枠が原因ではない」「サービス障害だ」とは確定できません。表示時刻、実際に選択したモデル、発生した操作、再現性を併せて残します。再試行してよい根拠が得られた後に、最小の安全な操作で回復を確認します。
OpenAI APIキーを使っている場合
OpenAI APIのレート制限は、組織・プロジェクト単位で定義され、モデルによって異なります。現在の値はDeveloper Consoleのlimits画面で確認できます。詳しい適用単位はOpenAI APIのrate limitsに記載されています。
APIの429は、短時間のリクエスト過多だけを意味するとは限りません。残高、組織・プロジェクトの支出上限、組織の利用上限に関係する分類もあるため、レスポンスのエラーcodeと本文を保存し、API error codesの該当項目と照合します。複数の組織やプロジェクトを使っている場合は、実際にリクエストを送った対象を確認してください。
ただし、これはOpenAI APIトラフィックに限った説明です。ChatGPTアカウントでサインインしたCodexの利用枠や、外部providerが返した429に、そのまま当てはめることはできません。
カスタムプロバイダー／ゲートウェイを使っている場合
CodexがOpenAI以外のプロバイダー、社内ゲートウェイ、互換APIを経由しているなら、429の発行元はその中継層または上流プロバイダーの可能性があります。設定した接続先、ゲートウェイ側のrequest ID、レスポンスヘッダー、同時刻のログ、プロバイダー固有の制限を確認します。
OpenAIの利用枠画面が正常でも、外部経路の429は説明できません。逆に、ゲートウェイが上流のエラー本文を書き換える構成では、Codexに見える一行だけで発行元を判別できないことがあります。ゲートウェイ側のrequest IDや時刻から、上流の記録と対応づけられるかを確認します。
待てばよい429と、設定確認が必要な429を分ける
一時的なAPIレート制限
OpenAI APIの一時的なレート制限でRetry-Afterが返っている場合は、少なくともその時間が過ぎるまで待ちます。独自クライアントでヘッダーがない場合は、待機時間にランダムな揺らぎを加えた指数バックオフを使い、試行回数と総時間に上限を設けます。公式の再試行ガイドも、短い間隔での無制限な再試行ではなく、バックオフを案内しています。
再試行する前に、並列数、同時実行中のジョブ、同一キーを共有する別プロセスを減らします。成功確認は、大きな元タスクをいきなり再開するのではなく、同じ経路とモデルを使う最小限の安全な操作を一度だけ実行します。
利用枠、残高、請求、支出上限
利用可能量が尽きている場合や、OpenAI API経路で残高不足・支出上限への到達が示されている場合、バックオフだけでは解消しません。該当する利用枠のリセット、残高や請求状態、組織・プロジェクトの制限変更が反映されたことを確認してから再実行します。
固定の「何分待てば直る」という答えはありません。ChatGPTの時間枠、APIのレート窓、請求・支出の境界、外部providerの制限では、回復条件がそれぞれ異なるためです。
認証または接続先の変更後に発生した場合
認証の切り替え、APIキーの変更、組織・プロジェクトの変更、gatewayの追加直後なら、現在のセッションがどの資格情報と接続先を使っているかを確認します。ただし、「変更直後だった」という時間的な一致だけで認証を原因とみなしてはいけません。エラーpayloadやgatewayログなど、発行元を示す情報と組み合わせて判断します。
再試行回数を増やす前に確認すること
Codexのモデルプロバイダー設定では、model_providers配下の各プロバイダーIDに指定するstream_max_retriesがSSE中断時の再試行を制御し、現行ドキュメント上の既定値は5です。設定の意味はCodex config referenceで確認できます。
この値を増やしても、残高、支出上限、利用枠、継続中のプロバイダー制限は解消しません。また、この設定はSSE中断時の再試行に関するもので、手元の429が必ずこの設定によって再試行されたとは限りません。原因が分からないまま値だけを大きくすると、失敗までの時間や不要なリクエストが増え、診断しにくくなります。
変更を検討するのは、429の発行元が分かり、一時的な制限で、待機条件が確認でき、現在の有限な再試行方針では短すぎると観測できた場合に限ります。変更前の値と検証結果を残し、総試行時間にも上限を設けてください。
安全に作業を再開する判定
「エラーが消えた」だけでなく、原因候補に対応する状態変化を確認します。
- 利用経路を一つに特定できた。
- その経路で、利用可能量、API limits、請求、ゲートウェイ応答のいずれかを確認した。
Retry-After、利用枠の更新、設定修正など、再試行してよい根拠が生じた。- 並列ジョブや自動再試行を止めた状態で、最小の操作が一度成功した。
- 元のタスクを再開するときも、失敗回数と総時間を制限している。
最小操作が成功しても、すぐに並列数を元へ戻さないでください。段階的に負荷を戻し、再び429が出た時点の同時実行数やタスク量を記録すると、次回の判断材料になります。
判断できないまま続くときの問い合わせ情報
同じ429が続き、待機の根拠がない場合は、推測で設定を変え続けるより、発行元に合ったサポート先へ情報を渡します。問い合わせには次を含めます。
- 発生日時とタイムゾーン
- Codexの利用経路（ChatGPTサインイン、OpenAI APIキー、カスタムプロバイダー／ゲートウェイ）
- エラー全文、エラーcode、request ID
- 使用したモデルと、再現する最小の操作
/usage、API limits・請求、ゲートウェイのログのうち、該当経路で確認した結果Retry-Afterの有無と、実施した再試行間隔- 直前の認証・設定変更
秘密情報は必ず伏せます。外部プロバイダーを使っている場合は、そのプロバイダーまたはゲートウェイのサポート先が一次窓口になることがあります。OpenAI APIのrequest IDが確認でき、OpenAIから直接返った応答だと分かる場合は、その情報をOpenAI側の問い合わせに添えます。
まずはCodexで認証方式を確認し、ChatGPTサインインなら「/usage」、APIキーならエラーpayloadとlimits、外部ゲートウェイなら上流ログを一つずつ確認してください。経路に対応する状態変化が見えるまで再試行を止めることが、復旧と原因特定の両方に最も有効です。
