Claude 错误 529 overloaded_error—

529 是唯一一个不是由你的代码引起的 Claude 错误：过载的是 Anthropic。你无法修复它，只能优雅地吸收它。这意味着使用耐心的退避重试，在对延迟敏感的路径中配置备用模型，尤其要避免立即发起重试的突发请求，因为它们会放大故障。

错误

响应（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——是什么以及如何应对

错误