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 不会收费。以错误结束的请求不计费。若是直接签约，则遵循各提供商的计费规则。