529 是唯一一種不是由你的程式碼造成的 Claude 錯誤：過載的是 Anthropic 本身。你無法修復它，只能妥善處理。這表示要以退避策略耐心重試、為延遲敏感路徑準備備援模型，絕不能立即發起重試風暴，否則只會加劇中斷。
錯誤
{
"type": "error",
"error": { "type": "overloaded_error",
"message": "Overloaded" }
}原因與解決方法一覽
| 原因 | 解決方法 |
|---|---|
| 提供商端過載（發布日、區域性中斷）。會同時影響所有客戶。 | 採用帶抖動的退避；查看 Anthropic 狀態頁面，不要重新部署自己的應用程式。 |
| 你自己的負載高峰，撞上了原本就緊繃的容量。 | 錯開批次工作；通常延遲十分鐘即可解決。 |
| 與 429 混淆：速率限制在日誌中看起來相似，但原因完全不同。 | 429 表示你超過了自身限制（伺服器正常）；529 表示伺服器過載（你的配額正常）。只有 429 會提供 Retry-After 提示。 |
| 沒有定義備援，因此提供商問題會一路傳遞到終端使用者。 | 設定備援鏈——在同一系列內（Sonnet → Haiku）行為相近；跨提供商（Claude → GPT）則能承受完整中斷。 |
重試，但不要加劇中斷
將 529 視為沒有 Retry-After 的 429：從約 2 秒開始指數退避，加入抖動，上限設為 30–60 秒，約五次嘗試後放棄，並將工作放入佇列。關鍵在於抖動：沒有抖動，所有用戶端會同時回來，延長它們正試圖脫離的過載狀態。
切換備援，而非癱瘓
對延遲敏感的路徑定義備援鏈。在 OpenAI 相容端點上，只需變更一個字串——不需要第二個 SDK，也不需要第二個帳戶：
PREFERRED = ["claude-sonnet-5", "claude-haiku-4-5", "gpt-5-6-terra"]
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 # überlastet — nächste Stufe versuchen
raise last最後才檢查自己的程式碼
如果 529 只出現在某一種請求類型，而同一時間的其他呼叫都成功，那就不是提供商全面中斷：檢查該路徑是否傳送異常大的提示詞，或在緊密迴圈中持續觸發。反之，如果所有呼叫同時受到影響，之後又自行恢復，那就是容量問題——工作應交給重試與備援，而不是重構。
如果你透過 Kunavo 呼叫
Kunavo 透過不只一條上游路徑提供 Claude，而多模型目錄讓跨提供商故障轉移只需在同一把金鑰、同一個計費帳戶上更改模型名稱——上述模式不需要第二個帳戶。即使仍有 529 傳到你這裡，也永遠不會計費。 容量與價格是兩個不同的問題；至於後者，各模型費率列於 Claude API 價格表.
常見問題
529 是我的錯嗎？
不是。這是提供商端的容量問題。你的責任僅限於不要加劇中斷（退避、抖動），並在事件持續時間超過你的延遲預算時準備備援目標。
529 或 429——差異在哪裡？
429 表示你超過了自身限制，伺服器正常。529 表示伺服器本身過載，你的配額正常。兩者都可以重試；只有 429 會附帶 Retry-After 提示。
529 通常會持續多久？
無法預測，也不能保證——因此正確做法是設定有上限的退避並搭配佇列，而不是把固定等待時間寫進程式碼。如果你的路徑有延遲預算，應以備援取代等待。
失敗的 529 呼叫會計費嗎？
透過 Kunavo 不會：以錯誤結束的請求不會計費。若是直接與提供商簽約，則取決於該提供商的計費規則。