529 是唯一不是由自己程式碼造成的 Claude 錯誤。繁忙的是 Anthropic 端，我們無法從這邊修正。能做的只有「妥善承受」——加入指數退避的持續重試、為嚴格要求延遲的路徑準備備援模型，以及不要連續立即重試而進一步惡化故障。這三項就是全部的處置方式。
錯誤
{
"type": "error",
"error": { "type": "overloaded_error",
"message": "Overloaded" }
}原因與解決方法一覽
| 原因 | 解決方法 |
|---|---|
| 供應商端繁忙（新模型發布日、區域性故障）。所有使用者會同時發生。 | 使用帶抖動的退避等待。不要重新部署應用程式，而應查看 Anthropic 的狀態頁面。 |
| 自己的突發傳送與已經吃緊的容量重疊。 | 將批次處理在時間上分散。通常只要錯開 10 分鐘就能解決。 |
| 與 429 混淆。日誌看起來相似，但原因完全不同。 | 429 表示自己超過上限（伺服器正常），529 表示伺服器過載（餘額與上限正常）。只有 429 會附帶 Retry-After。 |
| 沒有定義備援，導致供應商問題原樣傳遞到終端使用者。 | 預先決定備援順序。同一系列（Sonnet → Haiku）行為較接近；跨供應商（Claude → GPT）則能渡過整體故障。 |
設計不會惡化故障的重試
將 529 視為「沒有 Retry-After 的 429」。從約 2 秒開始進行指數退避，加入抖動，上限為 30～60 秒，重試約 5 次後放棄並移入佇列。真正有效的是抖動；沒有它，所有用戶端會在同一瞬間返回，直接延長本想脫離的壅塞。
不要丟棄，而要疏導
為嚴格要求延遲的路徑準備備援鏈。如果是 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 # 過負荷 — 次の候補へ
raise last最後才懷疑自己的程式碼
如果只有特定請求類型收到 529，而同一時間的其他呼叫都成功，那就不是整體故障。請確認該路徑是否傳送異常大的提示詞，或是否在短迴圈中連續發送。反之，如果所有呼叫同時收到 529，之後又自然恢復，原因就是容量。在這種情況下應調整的是重試與備援，而不是重構。
如果你透過 Kunavo 呼叫
Kunavo 將 Claude 分流至多條上游路徑，並透過多模型目錄，讓跨供應商備援變成「維持相同金鑰與相同餘額，只變更模型名稱」。不需要在上方程式碼中加入第二個帳戶。即使如此，已抵達的 529 也不會產生費用。 容量與價格是兩個不同問題。至於後者，請參見各模型的單價 Claude API 價格表.
常見問題
529 是我的錯嗎？
不是。這是供應商端的容量問題。我們這邊只有兩項責任——不要放大故障（退避與抖動），以及預先準備好備援目的地，以便在故障持續時間超過可容許的延遲時使用。
529 與 429 有何不同？
429 表示自己超過上限，而伺服器本身正常。529 表示伺服器過載，而我們這邊的上限與餘額正常。兩者都可以重試，但只有 429 會附帶 Retry-After 提示。
529 通常會持續多久？
無法預測，也無法保證。正因如此，正確做法是「有上限的退避 + 佇列」，而不是在程式碼中寫死等待時間。如果該路徑有延遲容許時間，就不要等待，而應讓備援接手。
因 529 失敗的呼叫也會計費嗎？
透過 Kunavo 不會計費。以錯誤結束的請求不列入帳單。若是直接簽約，則依各供應商的計費規則處理。