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 秒，嘗試約五次後放棄並將工作加入佇列。關鍵是抖動。沒有抖動時，所有用戶端會在同一時間回來，反而延長原本想擺脫的過載。
不要失敗，改為切換
為延遲敏感路徑定義備援鏈。若使用 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 時不會收費。以錯誤結束的請求不會計費。若是直接簽約，則依各提供者的計費規則辦理。