529 是唯一一种不是由你的代码造成的 Claude 错误：满载的是 Anthropic 那一端。你无法修复它，只能更好地处理它——采用带退避的耐心重试，为对延迟敏感的路径准备备用模型，并且绝不要通过立即连续重试来放大这次故障。
错误
{
"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，也不必再开一个账号：
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 不会：以错误结束的请求不计费。如果直接与供应商签约，则取决于各家的计费规则。