529 是唯一一個不是你的程式造成的 Claude 錯誤：滿載的是 Anthropic 那一端。你修不了它，只能把它接得漂亮一點 —— 帶退避的耐心重試、對延遲敏感的路徑準備備援模型，以及絕對不要用立即重試的連打去放大這場故障。
錯誤訊息
{
"type": "error",
"error": { "type": "overloaded_error",
"message": "Overloaded" }
}成因與解法一覽
| 成因 | 解法 |
|---|---|
| 供應商端滿載（新模型發表日、區域性故障）。所有客戶會同時遇到。 | 用帶抖動的退避等待；去看 Anthropic 的狀態頁，而不是重新部署自己的應用。 |
| 自己的尖峰流量正好撞上已經吃緊的容量。 | 把批次工作在時間上分散開；通常延後十分鐘就過去了。 |
| 與 429 混淆。在日誌裡兩者看起來很像，成因卻完全不同。 | 429 是你超過了自己的上限（伺服器健康）；529 是伺服器本身過載（你的額度沒問題）。只有 429 會附上 Retry-After 提示。 |
| 沒有定義備援，於是供應商的問題會一路傳到終端使用者面前。 | 先訂好備援順序 —— 同系列（Sonnet → Haiku）行為比較接近；跨供應商（Claude → Gemini）則能撐過整家出事的情況。 |
讓重試不會把故障放大
把 529 當成「沒有 Retry-After 的 429」來處理：從約 2 秒開始的指數退避、加上抖動、上限 30〜60 秒，大約五次之後放棄並把工作丟進佇列。真正有效的是抖動那一段：少了它，所有用戶端會在同一瞬間回來，把自己想逃離的那場壅塞原封不動地延長。
不要倒下，要繞過去
對延遲敏感的路徑要先定義好備援鏈。在 OpenAI 相容的端點上，這只是改一個字串 —— 不必多接一套 SDK，也不必多開一個帳號：
PREFERRED = ["claude-sonnet-4-6", "claude-haiku-4-5", "gemini-2-5-flash"]
def complete(messages):
last = None
for model in PREFERRED:
try:
return client.chat.completions.create(
model=model, messages=messages, max_tokens=800)
except APIStatusError as e:
if e.status_code not in (429, 500, 529):
raise
last = e # 過載 —— 試下一個
raise last最後才回頭懷疑自己的程式
如果只有某一種請求會 529、同一時間其他呼叫都過得去，那就不是全面故障：去看那條路徑是不是送了異常大的提示詞，或是在很短的迴圈裡連續發送。反過來，如果所有呼叫同時開始 529、過一陣子又自己好了，那成因就是容量 —— 該動的是重試與備援，不是重構。
如果你是透過 Kunavo 呼叫
Kunavo 會把 Claude 分散到一條以上的上游路徑，而多模型目錄讓跨供應商的備援變成「同一把金鑰、同一個餘額，只改模型名稱」這件事 —— 上面那段程式不需要第二個帳號。即使仍有 529 傳到你手上，也一律不計費。 容量與價格是兩個問題；關於後者，各模型的單價列在 Claude API 費用表.
常見問題
529 是我的問題嗎？
不是。這是供應商端的容量問題。你這邊的責任只有兩件：不要放大故障（退避與抖動），以及在故障持續超過你的延遲預算時有地方可以繞。
529 和 429 差在哪裡？
429 是你超過了自己的上限，伺服器是健康的；529 是伺服器本身過載，你的額度沒問題。兩者都可以重試，但只有 429 會附上 Retry-After 提示。
529 通常會持續多久？
無法預測，也不能保證 —— 所以正確答案是「有上限的退避加上佇列」，而不是在程式裡寫死一個等待時間。如果那條路徑有延遲預算，接手的應該是備援而不是等待。
以 529 失敗的呼叫會被計費嗎？
經由 Kunavo 不會：以錯誤結束的請求不列入計費。若是直接跟供應商簽約，就依各家的計費規則而定。