まずは結論
exceeded retry limit, last status: 429 Too Many Requests だけでは、Codex のサブスクリプション利用枠を使い切ったとは判断できません。まずアカウントと接続先を特定し、元のエラーを確認してください。一時的なリクエスト制限なら待つことで回復する場合がありますが、API の残高や支出制限には該当するアカウントでの対応が必要です。新しいチャットや手元のタイマーですべての 429 が解決するわけではありません。
「exceeded retry limit」は何を意味する？
このメッセージは「クライアントが再試行を打ち切った」「最後の HTTP 応答が 429 だった」という二つの手掛かりとして読めます。これは提示された文面の診断上の解釈であり、すべてのクライアントの再試行回数を公式に保証するものではありません。App Server プロトコルでは、試行失敗のエラーと上流の HTTP ステータス情報を区別しています。
直前に詳しいエラーが表示されていれば、その内容も保存してください。HTTP ステータスだけでは、リクエスト制限と API の利用枠・請求上の制限を見分けられません。同じタスクを繰り返し開始すると、原因が解消しないままリクエストだけが増えることがあります。
1. リクエストを拒否したサービスを確認する
クライアントでアカウントとワークスペースを確認します。CLI では codex login status を使えます。Codex の認証ガイドは、ChatGPT でのサインインと API キーでのアクセスを区別しています。
- ChatGPT でサインインしている場合： 同じアカウントの Codex 利用状況ダッシュボードを確認します。利用枠を使い切っている場合は、Codex の上限に達したときの手順に進んでください。API の請求残高はサブスクリプションの利用枠とは別です。
- OpenAI API キーを使っている場合： 返されたエラーと、該当する API 組織・プロジェクトの利用状況や請求を確認します。ChatGPT のリセット時刻で API の制限を診断しないでください。
- 独自プロバイダーやゲートウェイを使っている場合： 失敗したリクエストの実際の接続先を確認します。レート制限や請求方法は異なる場合があります。OpenAI API のエラーコードは、そのサービスがそれを返した場合にのみ適用できます。接続先のドキュメントやサポート窓口を確認してください。
2. 一時的なリクエスト制限と利用枠の枯渇を分ける
取得できる場合は、error.code、error.type、メッセージを併せて確認します。項目がないことから原因を決めつけないでください。API エラーリファレンスは次のケースを区別しています。
- リクエスト制限： 応答がレート制限を示し、
slow_downが含まれる場合もあります。同時実行タスクや短時間に集中するリクエストを減らしてから再試行します。 - クレジット残高：
credit_balance_exhaustedは API クレジットに関するエラーです。アカウント管理者と請求を確認してください。Codex のサブスクリプション枠がリセットされても、この残高は補充されません。 - 支出または利用量の制限：
organization_spend_limit_exceeded、project_spend_limit_exceeded、organization_usage_limit_exceededは、それぞれ別の制限を示します。追加支出を承認する前に、管理者と適用期間やアカウント設定を確認してください。 - 広い意味での利用枠エラー：
insufficient_quotaはerror.codeより大まかな分類である場合があります。一時的な送信頻度の問題と決めつけず、詳細なメッセージを読んでください。
これらは OpenAI API の例であり、Codex の画面ですべての項目を確認できるという意味ではありません。429 しか表示されない場合は、アカウント情報や詳しいエラーで特定できるまで原因を不明として扱います。
3. 待つことが有効な場合にだけ再試行する
一時的な API のリクエスト制限では、Retry-After があれば従ってください。ない場合は、OpenAI が推奨する指数バックオフとジッターを使います。待ち時間を段階的に長くし、ランダムなずれを加える方法です。自分で制御する再試行ループには、試行回数と総所要時間の両方に上限を設けます。必要な待ち時間がその範囲を超えるなら、サーバーの指定時間を短縮せず、タスクを後に回してください。
対話形式の Codex タスクでは、繰り返し送信を止め、同時進行の作業を減らし、指定された待ち時間の後に小さな続きを一度試してください。クライアントの再試行に重ねて、手動で短い間隔の再送を続けないでください。クレジットや支出のエラーはバックオフでは直りません。「5 分待てば解決する」という万能な方法もありません。
中断したタスクを再開する前に、すでに変更されたファイル、コマンドの結果、完了した外部操作を確認してください。状態が分かっている手順から再開し、同じ操作を重複させないようにします。
401、403、500、503、ストリーム中断との違い
実際のメッセージに応じて、次に確認する点を選びます。すべてが利用枠のリセット待ちを意味するわけではありません。エラーリファレンスと Codex のトラブルシューティングも参照してください。
- 401： 認証方法、選択中のアカウント、認証情報の有効性を確認します。サポートへの投稿にキーを貼り付けないでください。
- 403： 記載されたアクセス権、ポリシー、地域の制限を確認します。リクエストを繰り返しても権限は付与されません。
- 500 または 503： サーバーエラーや一時的な過負荷では、間隔と回数を制限した再試行が適切な場合があります。続く場合は接続先サービスの稼働情報を確認し、障害を報告してください。
- ストリーム中断またはタイムアウト： クライアントが完全な結果を受け取る前に接続が終了しています。この文面だけでは利用枠の問題とも、作業が何も完了していないとも判断できません。元のステータス、クライアントのログ、ネットワーク経路を確認し、タスクの進捗を確かめてから再開してください。
エラーが続くときに残す情報
発生日時とタイムゾーン、クライアントとバージョン、モデル、サインイン方法、接続先、機密情報を除いたメッセージ、HTTP ステータス、提供されていればリクエスト ID を保存します。小さなリクエスト一つでも失敗するか、別のクライアントでは動くか、アカウントで何を確認したかも記録してください。接続先のサポート窓口にログを送る前に、API キー、認証ヘッダー、Cookie、非公開のタスク内容を取り除きます。
確認の結果、サブスクリプション枠の消費が原因と分かった場合は、Codex のリセット時刻ガイドを参照してください。個人タイマーは表示された回復時刻を思い出すために使えますが、API のリクエスト制限を解除したり、アクセスの回復を確認したりするものではありません。