Claude 錯誤 529 overloaded_error—

529 是唯一不是由你的程式碼造成的 Claude 錯誤：過載的是 Anthropic。你無法修復它，只能優雅地吸收。這表示要以耐心的退避重試、在對延遲敏感的路徑上設定備援模型，最重要的是避免立即大量重試，以免放大事件。

錯誤

respuesta (HTTP 529)

{
  "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，也不需要第二個帳戶：

failover.py

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          # saturado — probar el siguiente nivel
    raise last

然後才檢查你的程式碼

如果 529 只出現在某一種請求，而其他呼叫同時正常通過，那就不是一般性事件：檢查該路徑是否傳送異常大的提示，或是否在封閉迴圈中觸發。如果所有呼叫同時受到影響，接著又自行恢復，那就是容量問題——此時應處理重試與備援，而不是重構。

如果你透過 Kunavo 呼叫

Kunavo 透過多個來源路徑路由 Claude，其多模型目錄讓跨供應商切換只需在相同金鑰與相同餘額下變更模型名稱——上面的模式不需要第二個帳戶。即使仍收到 529，也絕不會被收費。容量與價格是不同的問題；至於後者，各模型的費率列於 Claude 價格.

常見問題

529 是我的錯嗎？

不是。這是供應商端的容量問題。你唯一需要負責的是不要放大事件（退避、抖動），並在事件持續時間超過延遲預算時提供備援出口。

529 與 429 有什麼差異？

429 表示你超過了自己的限制，伺服器正常。529 表示伺服器本身過載，你的配額正常。兩者都可以重試；只有 429 會附帶 Retry-After 提示。

529 事件通常會持續多久？

無法預測，也無法保證——因此正確做法是設定上限的退避加上佇列，而不是把固定等待時間寫死在程式碼中。如果路徑有延遲預算，應由備援接手，而不是繼續等待。

最後以 529 結束的呼叫會收費嗎？

透過 Kunavo 不會：以錯誤結束的請求不會收費。直接與供應商簽約時，則取決於相關供應商的計費規則。

Claude API 錯誤 529 overloaded_error——這是什麼，以及如何吸收它

錯誤