Claude API 报 529 overloaded_error 怎么办?和 429 的区别 + 五种处理方式(2026)
529 是 Anthropic 侧容量满了,不是你超额、不是你的 key 有问题、也不是你的代码写错。它和 429 的成因完全相反,处理方式也完全不同。
先分清楚:你遇到的到底是哪个
看响应体里的 `type` 字段:`overloaded_error` 是 529,`rate_limit_error` 是 429。**这一步不能跳** —— 两者的解法方向相反:429 要你**减少发送**,529 减少发送几乎没用,因为瓶颈不在你这边。很多人遇到 529 就去砍并发,结果既没解决问题,又白白拖慢了业务。
为什么「换模型」对 529 特别有效
Anthropic 的容量是**按模型分别调度**的。Opus 这类旗舰模型在高峰期最容易先满,而同一时刻 Sonnet、Haiku 往往是通的。所以 529 的第一反应不该是「等」,而是「降一档试试」——对大多数任务来说,换成 Sonnet 完成得了,总比停在那里等强。这也是分层路由除了省钱之外的第二个价值:**它同时是一条容灾路径**。
退避重试必须带 jitter
遇到 529 后按 1s、2s、4s、8s 逐次退避,并**给每次延迟加一个随机量**。没有随机量的话,所有在同一秒被拒的客户端会在同一秒一起重试,把刚缓过来的服务端再打满一次。另外设一个重试次数上限(通常 3-5 次),别让一个任务无限重试——那会变成账单问题。官方 SDK 默认重试两次并遵守 `retry-after`,自己写循环时记得对齐这个行为。
长任务要能从中间续上
529 最伤的场景是长任务:跑了二十分钟,最后一步 529,整个任务作废重来。解法是把长任务**切成可独立重试的小段**,每段完成就落盘。这样 529 只会让你重跑一小段,而不是从头开始。这件事和 529 没有直接关系,但它决定了 529 发生时你损失多少。
备用路径值不值得配
看你的业务能不能接受「等十分钟」。能接受就不用折腾,退避重试足够。不能接受(比如面向用户的实时功能)就该配第二条路:同一份代码切到另一个模型或另一个入口。走 OpenAI 兼容接口的好处是切换成本接近零——模型名换一个字符串,不用改 SDK、不用改鉴权。cocodot 一个 key 一份余额覆盖 Claude / GPT / Gemini 全系,就是为了让这种切换是一行配置而不是一次迁移。
说清楚能力边界
**任何中转都不能让 529 消失。** 上游容量是 Anthropic 的容量,中间多一层不会凭空变出算力——遇到有人宣称「用了我们就不会 529」,那句话本身就不成立。中转能提供的是别的东西:一个 key 覆盖多家模型,让「换一档继续跑」变成一行配置;以及失败调用不计费,重试不会让你为没拿到的结果付钱。
529 和 429 是两回事
| 529 overloaded_error | 429 rate_limit_error | |
|---|---|---|
| 原因 | 服务端整体容量满 | 你超了自己的配额 |
| 和你的账号有关吗 | 无关 | 直接相关 |
| 消耗配额吗 | 不消耗 | 已计入 |
| 降低并发有用吗 | 基本没用 | 有用,这就是解法 |
| 换模型有用吗 | **有用**(容量按模型算) | 不一定 |
| 该做什么 | 退避重试 / 换模型 / 等 | 降速 + 客户端限流 |