exceeded retry limit, last status: 429 Too Many Requests が出た直後に、同じ長いタスクを別セッションから何度も送らないでください。Codexはすでに複数回の自動再試行を行い、最後まで429が返ったため処理を止めています。ここで手動の同時再送を増やすと、短時間の制限を長引かせる可能性があります。
まず変更済みファイルを保全し、新しいsubagentやバックグラウンドタスクを止めます。そのうえで、エラー全文、発生時刻とタイムゾーン、表示されていればrequest IDを記録します。復旧に必要なのは「何分待つか」という推測ではなく、「今回のリクエストを所有していたのはどの利用枠か」という確認です。
429とretry limitは同じ制限ではない
retry limit はCodexクライアント側の自動再試行回数です。アカウントに「再試行用の別枠」があるという意味ではありません。last status: 429 は最後にサーバーまたはgatewayが返したHTTP statusです。ただし、429だけでは原因を1つに決められません。
OpenAIの現在のAPI error codesでは、request rate、prepaid credit不足、organization/projectのspend limit、organization usage limitが別の429として扱われます。APIを直接利用している場合、billing系では広いerror.typeよりresponse bodyのerror.codeが具体的で、必要な対応も変わります。
さらに、カスタムbase_url、企業gateway、model router、外部providerを利用していれば、429を返したのはOpenAIではない場合があります。ChatGPT側の残量があっても、そのproviderの同時実行枠や残高は証明できません。
最初の1分で変数を固定する
原因を知る前にlogout、model変更、network変更、key交換、provider切り替えを同時に行うと、復旧しても何が効いたのか分かりません。現在の状態を次のどれかに分類します。
| 実行経路 | 確認する所有者 | 残すべき情報 |
|---|---|---|
| ChatGPTでサインインしたCodex | 個人accountまたはworkspaceのCodex Usage | 5時間・週間枠、reset、credits、CLIの/status |
| OpenAI API keyで直結 | API organization/project | error.code、Retry-After、Limits、Billing |
| Business、Enterprise、Edu | 管理workspace | seat、共有/購入credits、管理者ポリシー |
| 第三者provider/gateway | そのproviderの契約 | base URL、headers、request ID、残高、model pool、status |
OpenAIの現在のCodex usage説明は、accountの現在のlimitをUsage Dashboardで確認し、Codex CLIでは/statusで残量を確認できると案内しています。表示項目はclient、version、認証、plan、rolloutによって変わるため、見えない項目を「制限なし」と解釈しないでください。
Account AからBへ切り替えたのに同じ枠が見える場合は、アカウント・workspace・APIメーターの確認へ進みます。古いlogin、同じworkspace、同じAPI organizationを除外する作業であり、429の連打では確認できません。
「まだ残量がある」を具体的な名前に変える
残っているように見える値が、週間percentage、5時間枠、ChatGPT credits、API prepaid credit、project spend limit、外部provider残高のどれかを書き出してください。これらは同じ財布ではありません。
OpenAIのtokensとcreditsの説明では、credit消費はmodel、context、reasoning、toolsで変わり、対象planではincluded limits到達後も利用可能なcreditsで継続できます。同じページは、ChatGPT planのlocal messagesとcloud chatsが5時間windowを共有し、追加の週間limitが適用される場合もあると説明しています。したがって、メッセージ数だけでは消費量を比較できず、週間枠に残りがあることだけで短いwindowや別providerの制限も否定できません。
設定を触る前の記録は、次の項目で十分です。
- Codexの利用面とclient version
- ChatGPT login、API key、または外部provider
- 秘密情報を伏せたaccount/workspace、APIならorganization/project
- model、reasoning、Fast、subagentの有無
- 表示されたusage、reset、credits、provider balance
- local、cloud、scheduled、delegated、backgroundの実行中タスク
- エラー全文、timestamp、timezone、request ID
API key、access token、OTP、完全なemail、credential file、private code、課金画面全体は問い合わせ資料に含めません。
制限元ごとに復旧条件を変える
短時間のrequest-rate制限
OpenAI APIのrequest-rate 429では、公式ガイドはrequestを減速し、Retry-Afterがあれば少なくともその時間を待つよう案内しています。custom HTTP clientでheaderがない場合はjitter付きexponential backoffを使い、試行回数と総retry時間の両方を制限します。OpenAI公式SDKは対象のrate-limit errorを自動再試行し、存在するRetry-Afterも扱うため、別のretry層を追加する前にその試行を数えてください。失敗したrequestも分間limitに算入される場合があります。
Codexがterminal errorを表示した時点では、クライアント自身の試行は終了済みです。並列sessionとsubagentを止め、画面に出たresetまたはproviderの指示を待ちます。再開時は小さく終了条件の明確な操作を1つだけ実行し、成功後に徐々に負荷を戻します。
ChatGPT/Codexの利用枠
ChatGPT認証なら、同じaccountまたはworkspaceのUsageを確認します。5時間枠と週間枠を分け、表示されたreset、利用可能なcredits、重複して動いているagentic taskを記録します。
支配しているwindowが明確に尽きていれば、そのresetを待つか、accountが提供していて支払いを受け入れられる場合に正規のcreditsを利用します。軽いmodel、短いcontext、少ないtoolsは復旧後の消費を抑えられますが、閉じたwindowを開く操作ではありません。
APIのcredit・spend・usage limit
OpenAI APIへ直結している場合はerror.codeを読みます。credit_balance_exhausted、organization_spend_limit_exceeded、project_spend_limit_exceeded、organization_usage_limit_exceededでは、対応する所有者と復旧条件が異なります。
OpenAIは、credit、spend、quota系errorは再試行してもアクセスが回復しないと明記しています。実際のresetを待つか、権限を持つorganization/project ownerが該当balanceまたはlimitを変更する必要があります。同じproject内でAPI keyだけを交換しても、新しいquotaにはなりません。
外部gatewayの429
OpenAI以外のbase URLなら、providerのrate-limit headers、残高、並列数、model pool、request ID、statusを確認します。gatewayがupstream errorを独自の429へ変換することもあります。元responseが見えないなら、確定できるのは「このrouteが429を返した」までです。
同じ認証とmodelを保ち、providerが示した時間を待つか並列数だけを下げて、小さいrequestを1回試します。ChatGPT Usageのpercentageで外部契約を説明しないでください。
サービス障害の可能性
OpenAI Statusで、製品、時刻、地域が重なる公開incidentを確認します。該当incidentがあれば公式の更新に従い、必要に応じてrequest IDを保管します。公開incidentがないことは、個別account、地域、外部gatewayまで正常だと証明するものではありません。
再開テストは「直ったか」ではなく1つの仮説を検証する
reset、limit変更、provider復旧の後に、古いprocessやcloud taskが残っていないことを確認します。account、route、model、reasoning、Fastを固定し、数分で終わる小さな作業を選びます。開始前後で同じmeterまたはprovider stateを保存してください。
小さな作業は成功し、大きな作業だけ再び429になるなら、負荷、並列数、context、短いwindowが候補として強くなります。最小作業も即座に同じ429を返すなら、大きな再送は情報を増やしません。quota、provider、statusの証拠へ戻ります。
この前後記録は、週間残量が想定より速く減る問題にも使えます。完全なtask別請求書にはなりませんが、見えている作業に対応する変化、別surfaceの活動、説明できない変化を分けられます。
復旧条件を満たしても再現する場合は、client/version、認証経路、provider、model/mode、エラー全文、timestampとtimezone、request ID、見えているusage/reset、並行task、最小再現手順をまとめます。APIなら秘密情報を除いたerror.codeとrate-limit headersを追加し、Authorization headerやprivate request bodyは渡しません。
最短の復旧手順は、連打を止める、requestの所有者を確定する、利用可能なsubtypeを読む、壊れた条件だけを変える、小さなテストを1回行う、の順です。待機・課金・管理者対応・providerへの問い合わせを、この順序なら根拠のある次の行動として選べます。
