Claude Fable 5 の 529 overloaded_error

529 の実際の原因

4 つの原因はすべて Anthropic 側にあります。リクエスト本文を変えても解決しません。

• Fable 5 の長いターンが露出時間を広げる

  難易度の高いタスクを高い effort で処理する場合、Fable 5 の 1 リクエストが数分に及ぶことがあります。リクエストが飛んでいる時間が長いほど容量イベントと重なる確率が上がり、ストリーム途中の過負荷は 200 が返った後に到達します。

• 事前に警告するヘッダーが存在しない

  429 と異なり、過負荷では監視できる残容量ヘッダーがありません。レスポンスのメタデータから 529 を予測することはできないため、事前のスロットリングではなく事後のバックオフで対処するしかありません。

• 需要が特定のモデルに集中している

  容量はモデルごとに管理されるため、Fable 5 が飽和していても Opus 5 や Sonnet 5 は正常に応答することがあります。Claude Code はこれを明示しており、あるモデルの負荷が特に高いときは /model で切り替えるよう促します。

• アカウントではなくプラットフォーム全体の容量

  529 は API が全ユーザーからの高トラフィックを受けているときに発生します。組織のティア、支出上限、レート制限は 529 に遭遇するかどうかとは無関係です。利用パターンがまったく異なる 2 つの顧客が、同じ時間帯に同時に 529 を受け取ります。

この順序で対処する

手順 1 と 2 でほとんどのケースはカバーできます。3 から 5 は長引く障害と無人実行向けです。

1. 1

   1. 指数バックオフでリトライする

   指数的に伸びる待ち時間とジッターを付けてリトライします。公式 SDK は 5xx に対して既定で 2 回リトライしているので、その外側にもう一段リトライを重ねるのではなく、クライアントの maximum-retries オプションを引き上げてください。二重化すると待ち時間が伸びるのではなく試行回数が掛け算になります。

2. 2

   3. エスカレーション前にステータスページを確認する

   status.claude.com でインシデントが告知されているか確認します。他の構成では、エラーメッセージに記載されたプロバイダーまたはゲートウェイのホストを確認してください。告知がないのにエラーが続く場合は、エラー本文の request_id を添えてサポートチケットを起票します。

3. 3

   2. 即時リトライや一斉リトライを避ける

   詰まったリトライループは容量イベントを悪化させ、毎分のリクエスト枠を無駄に消費します。ジッターを入れて、ワーカー群のリトライが同期し、すでに飽和したモデルへサンダリングハードとして殺到しないようにしてください。

4. 4

   4. 別モデルへのフェイルオーバーを自分で実装する

   容量はモデルごとに管理されるため、Fable 5 の容量イベント中でも claude-opus-5 にルーティングすれば応答が得られることが多いです。これは自分で書くコードです。fallbacks パラメータは安全性分類器の拒否でしか発火せず、過負荷では決して動きません。

5. 5

   5. Claude Code では無人実行向けにリトライ枠を広げる

   Claude Code は一時的な失敗を指数バックオフで最大 10 回リトライし、これは CLAUDE_CODE_MAX_RETRIES で制御します。CI ジョブや評価ハーネスでは CLAUDE_CODE_RETRY_WATCHDOG を 1 に設定し、429 と 529 の容量エラーを実行失敗にせず無制限にリトライさせてください。

関連ページ