Claude API が 529 overloaded_error を返したら、最初の判断は Anthropic 側の容量過負荷です。キーが壊れた、請求が止まった、個人の quota が切れた、とすぐに決めないでください。近い罠は 429 rate_limit_error と混同することです。429 は rate limit や quota の分岐で、529 は capacity の分岐です。
最初の一分は小さく順番を守ります。Claude Status の結果と時刻を記録し、jitter を入れた短い retry 予算で確認します。呼び出し側の traffic を制御できるなら、concurrency を下げ、非緊急 batch を止め、queue に逃がします。その後、同じ model、endpoint、auth path、request shape で再確認します。同じ経路で 529 が続くなら、error body と request_id を残してエスカレーションします。
Status は時刻付きの信号にすぎません。この run では 2026-04-29 11:02 UTC に public status API が all systems operational を示していましたが、incident feed には 4 月 28 日と 4 月 29 日 UTC の resolved elevated-error event が残っていました。緑表示は判断材料ですが、あなたの正確な経路が復旧済みだと証明するものではありません。
一分で決める分岐表
キー、請求、model、provider を触る前に、まず exact signal を見ます。
| exact signal | まず扱う分岐 | 最初の動き | 同じ経路の確認 | 止める・相談する条件 |
|---|---|---|---|---|
529 または overloaded_error | Anthropic の capacity overload | live status を確認し、capped jitter retry | 同じ model、endpoint、auth route、request shape | status、retry 予算、負荷低減後も続く |
429 または rate_limit_error | rate limit または quota | retry-after、limit、credential route を確認 | 許可 window か route 修正後に再試行 | header と Console が制限を示し続ける |
500 または api_error | server error | status を確認し、request evidence を保存 | 短い pause 後に同じ request | incident なしで同じ経路が失敗 |
504 または timeout_error | timeout | request を短くし、streaming か分割を使う | 一つだけ形を変えて確認 | 長い request がまだ timeout |
| Claude Code terminal の反復 529 | Claude Code surface | API 意味を確認して terminal 分岐へ | 同じ session と route を cooldown 後に確認 | status と route 確認後も続く |
実務上の結論は、529 は overload first です。error が 429、auth error、明確な provider limit に変わらない限り、key rotation、plan upgrade、prompt rewrite から始めない方が原因を残せます。
Claude API で 529 が意味すること
Anthropic の API error documentation は HTTP 529 を overloaded_error と定義しています。同じ表では 429 rate_limit_error、500 api_error、504 timeout_error が別の行になっています。この公式の分離が、復旧手順の境界になります。
重要なのは ownership です。真の 529 は、service が overloaded か capacity pressure にあることを示します。client 側の振る舞いを良くする必要はありますが、最初の解釈は「自分の account が quota out」ではありません。真の 429 は request rate、acceleration limit、model limit、account/provider ceiling に寄ります。500 は server error handling と証拠保存、504 は duration と request shape の問題です。
悪い修正は、すべての blocked request を同じものとして扱う時に起きます。blocked だから 429 のように遅くする、auth のように key を替える、route failure のように provider を替える。どれも別分岐では有効ですが、clean 529 の第一手ではありません。
request_id も早く保存します。Anthropic の docs は error response に request_id が含まれると説明し、response header に request-id が出る場合もあります。529 が続く時、support が見たいのは長い実験記録ではなく、この id と同じ経路の証拠です。
安全な復旧ループ
529 の handler は退屈であるべきです。status を確認し、短い retry を行い、pressure を下げ、同じ経路を確認し、そこで止めるか相談します。client にもっと頑張らせるのではなく、overload を悪化させずに証拠を残すことが目的です。
まず live status を見ます。結果と時刻を UTC か運用 timezone で記録します。active incident があるなら、model、endpoint、auth、request size を同時に変えないでください。失敗した request shape を保持し、pause して、degradation が改善してから確認します。
status が green、または public incident がない場合は、bounded retry budget を使います。現実的な実装は exponential backoff、jitter、attempt limit、total elapsed time limit を持ちます。retry できるのは繰り返して安全な work だけです。read request や caller-side deduplication のある generation は、side-effecting workflow より扱いやすいです。
次に caller pressure を下げます。concurrency を落とし、non-urgent batch job を止め、queue backpressure を使い、optional feature を degraded mode にします。529 があなたの責任という意味ではありません。provider overload 中の aggressive retry は、同じ狭い system にさらに traffic を戻すからです。
最後に同じ経路で確認します。model、route、auth owner、endpoint、region/proxy path、request shape は安定させます。一つの変数だけを意図的に変えるなら、その目的を記録します。五つ変えて成功すると、overload が回復したのか、route が変わったのか、request が軽くなったのか分かりません。
反復 529 に必要な production control
手動の順序は人間向けですが、service も同じ discipline を自動化する必要があります。まず retry budget です。infinite retry ではありません。attempt、elapsed time、request value が切れる時刻を制限します。chat turn、background batch、transactional workflow は同じ retry policy にしません。
jitter も必須です。固定 interval は traffic を同期させ、overloaded API に最悪の形で戻します。jitter は request を分散し、復旧時の spike を下げます。
反復 529 には circuit breaker を置きます。error rate が threshold を超えたら breaker を開き、non-urgent work を queue に置き、optional feature を落とし、user-facing message を出します。閉じる時は少数の same-path probe で確認し、batch traffic を一気に戻さないようにします。
「pressure を下げる」と「route を変える」は別物です。pressure reduction は concurrency を減らす、batch window を小さくする、job を defer することです。route change は model、endpoint、provider、auth owner を変えることです。route change は business decision として有効ですが、evidence trail と product behavior を変えます。
観測項目は単純で十分です。error type、HTTP status、model、endpoint、auth route、request size class、retry count、final outcome、request_id を残します。これで 529 spike 中に必要な問いへ答えられます。同じ経路は retry budget 内で戻ったのか、それとも provider overload が続いているのか。
Claude Code で 529 が見える場合
まず API 層の意味を適用します。529 overloaded_error は overload first です。Claude Code で見えている場合、terminal surface は別の rule を足しますが、529 を billing issue に変えるわけではありません。
Claude Code documentation は repeated 529 を users across temporary capacity と説明し、message が出る前に Claude Code が retry 済みだと言い、usage limit や quota wording と分けています。terminal 固有の症状は Claude Code overloaded error guide に渡す方が自然です。
terminal line が 500、529、429、temporary limiting、route confusion を混ぜているなら、より広い Claude Code 500 と 529 と rate limit の分岐 を使います。terminal は複数の分岐を一行に圧縮することがあります。
API team は route ownership も確認します。shell environment variable、proxy、provider wrapper により、意図しない path で request が走ることがあります。一つの wrapper path だけが 529 を返すなら、同じ request を意図した route で比較してから、Claude API 全体の障害だと判断します。
エスカレーション用の証拠
相談に進むのは、小さく順序立てた recovery path の後です。current status が記録され、retry は bounded、可能な pressure reduction は実施済みで、同じ経路がまだ 529 を返している状態です。
送る情報は短くします。
- exact HTTP status と error type、つまり
529 overloaded_error - full error body と利用可能な
request_id - model、endpoint、SDK または gateway route、auth owner
- timestamped Claude Status result と relevant recent incident note
- retry count、backoff window、jitter の有無
- failure 時点の concurrency または batch pressure
- secret を除いた minimal reproduction request shape
- business impact 一文、たとえば production job blocked、user flow degraded、batch delayed
support に必要なのはすべての local experiment ではありません。正しい branch が 529 であること、client が retry storm を作っていないこと、reasonable control 後も同じ経路が失敗していることです。
よくある質問
Claude API 529 は 429 と同じですか？
違います。Anthropic は 529 を overloaded_error、429 を rate_limit_error と定義しています。529 は overload first、429 は rate-limit branch です。
529 は account や billing の故障ですか？
最初の解釈にはしません。clean な 529 overloaded_error は capacity overload を示します。billing、key、quota の確認は、error が変わる、route が想定と違う、または別の signal がある時に行います。
Claude Status が green でも 529 が続く時は？
green status は timestamped signal であり、正確な path の復旧証明ではありません。短い same-path retry with jitter、pressure reduction、同じ model/route/auth/request shape の確認を行い、それでも続くなら request_id 付きで相談します。
retry は何回まで安全ですか？
普遍的な回数ではなく budget を使います。attempt または elapsed time を制限し、jitter を入れ、繰り返して安全な work だけ retry します。user-visible value が短い request は budget も短くします。
529 が出たら model や provider を変えるべきですか？
明示的な route decision としてなら可能です。workload が別 route を許す場合、non-critical flow を守れます。ただし第一診断として使うと、original path が回復したかどうかを隠します。
Anthropic support には何を送るべきですか？
error body、request_id、model、endpoint または gateway route、auth owner、status timestamp、retry timeline、pressure level、minimal reproduction を送ります。secret は削除し、branch を明確にします。
運用ルール
Claude API 529 は overload-first branch です。live status を時刻付きで確認し、capped jittered budget で retry し、caller pressure を下げ、同じ経路を確認します。同じ経路が 529 overloaded_error を返し続ける時だけ、clean evidence と request_id でエスカレーションします。