Claude 529 错误（overloaded_error）的原因与处理方法

529 是唯一一个不是由我的代码造成的 Claude 错误。过载发生在 Anthropic 一侧，我无法修复它。能做的只有妥善承接——加入退避的耐心重试、为对延迟敏感的路径准备回退模型，以及不要通过即时重试风暴放大故障。

错误

响应（HTTP 529）

{
  "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 或账户：

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          # 과부하 — 다음 후보로
    raise last

最后才怀疑自己的代码

如果只有特定请求类型出现 529，而同一时间的其他调用成功，那就不是整体故障。请检查该路径是否发送了异常大的提示词，或是否在紧密循环中连续调用。相反，如果所有调用同时变成 529，随后自然恢复，原因就是容量。此时应调整的是重试和回退，而不是重构。

如果你通过 Kunavo 调用

Kunavo 会将 Claude 路由到两个以上的上游路径，并借助多模型目录实现跨提供商回退，即“使用相同密钥和相同余额，只更改模型名称”。上述代码不需要第二个账户。即使到达 529，也不会产生费用。容量与价格是两个不同的问题。关于第二个问题，按模型列出的单价是 Claude API 价格表.

常见问题

529 是我的错吗？

不是。这是提供商侧的容量问题。我们这边只有两项责任：不要放大故障（退避和抖动），并为故障超过延迟容忍时间的情况准备好转移路径。

529 与 429 的区别是什么？

429 表示我超出了限制，服务器正常。529 表示服务器本身过载，而我的限制正常。两者都应重试，但只有 429 会附带 Retry-After 提示。

529 状态通常会持续多久？

无法预测，也无法保证。因此正确答案是有上限的退避和队列，而不是在代码中写死等待时间。如果该路径有延迟容忍时间，应让回退方案接管，而不是等待。

因 529 失败的调用也会收费吗？

通过 Kunavo 不会收费。以错误结束的请求不计费。若是直接签约，则遵循各提供商的计费规则。

Claude API 529 overloaded_error——是什么意思，如何应对

错误