529 Overloaded 到底意味着什么
截至 2026-10-08，Claude Code 官方错误文档写明：529 是 API 容量暂时满载，不是你的用量限额，也不计入配额。改代码没用，改重试策略才有用。
更新于 2026-10-08
订阅额度用完或频繁 429？可以改用按 token 计费的 API，一把 key 接着用。
- 按 token 计费，实时单价见 /models
- 支付宝、微信支付、信用卡、加密货币均可付款
- 充值后自助开通、立刻生效
四个要点
上游拥塞
服务端整体容量紧张时返回，与你的密钥额度、参数、请求体都无关。
你被限流了
这个才是「你超了自己的速率或额度」。529 和 429 的处理方式完全不同，别用同一套逻辑。
唯一有效的客户端应对
指数退避 + 抖动。立刻重试只会加重拥塞，并让你更快撞上限流。
结构性缓解
同一任务能落到不同上游时，单点拥塞才不至于变成停工。代价是要接受模型差异。
529 和 429、503 有什么不同
529 表示服务端此刻整体过载，属于容量问题，通常是暂时的；429 表示你触碰了自己的速率或额度上限，是配额问题；503 一般指服务不可用或正在维护。三者都不代表你的请求写错了，但处理方式不同：529 应当退避重试，429 应当降速或提额，503 应当等待并关注服务状态页。把它们混在一个 catch 分支里，是最常见的错误处理写法。
为什么最近讨论变多
每当有新模型发布或大规模迁移发生，上游容量都会出现阶段性紧张，529 的讨论随之升温。这类波动通常随容量扩充而缓解，但对正在赶工的人来说，等厂商扩容不是可用的答案。
排查顺序
确认状态码确实是 529 而不是 429。两者的响应体不同，日志里要分开统计。
查厂商状态页。若是大范围事件，客户端再怎么改都只是缓解。
检查自己的重试逻辑是否在放大拥塞：无抖动、无上限、失败即刻重试都属于放大。用 Claude Code 的话，2.1.292 版（2026-10-06）起可以用 CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS 把 529 重试的基础延迟调长。
先别急着重试，先分清楚是哪个码
可以确认的
529 表示服务端容量拥塞、与请求内容无关，这是厂商文档中明确的语义。Claude Code 官方错误文档（2026-10-08 核对）的报错原文是 API Error: Repeated 529 Overloaded errors. The API is at capacity — this is usually temporary.，并写明 A 529 is not your usage limit and doesn't count against your quota，即 529 不是你的用量限额、不计入配额；文档还说容量按模型分别统计，可以运行 /model 换一个模型继续。Claude Code CHANGELOG 记载：2.1.286 起默认设置下一次失败的模型调用最多发出 14 次请求，2.1.292 新增 CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS。指数退避加抖动是被广泛验证的客户端应对方式。
不要当事实
「529 是厂商在悄悄限制重度用户」这类说法没有证据支持，本页不做断言。529 与 429 的语义区分是公开文档写明的，把两者混为一谈会让你选错处理方式。
两种应对
只在客户端做退避
实现成本低，能显著降低失败率。但上游持续拥塞时，你能做的只有等。
让任务能落到多个上游
单点拥塞不再等于停工。代价是要接受不同模型的习性差异，且任何一路都可能有自己的故障形态。
正确的重试写法
要点有三条。第一，指数退避而不是固定间隔：首次等 1 秒，之后逐次翻倍。第二，加随机抖动：所有客户端同时退避同一时长，会造成同步的重试洪峰，反而延长拥塞。第三，设上限：重试次数和总等待时长都要封顶，否则一次拥塞会让你的任务队列无限堆积。另外，流式请求在中途断开时不要盲目从头重试，先判断已收到的内容是否可续。如果你用的是 Claude Code：官方文档写明它在报错之前会对瞬时失败自动重试最多 10 次、指数退避（2026-10-08 复核）；2.1.286 版（GitHub Release 2026-09-30）改了重试的计数方式，changelog 原文是 one limit now covers a whole model call, so with the default retry settings a failing call sends at most 14 requests，即一个上限覆盖整次模型调用，默认设置下一次失败的调用最多发出 14 次请求；2.1.292 版（GitHub Release 2026-10-06）新增了环境变量 CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS，changelog 原文是 to set a longer base delay for the backoff when retrying an overloaded (529) request，即给 529 重试的退避设置更长的基础延迟。changelog 没有写这个变量的默认值，本页不猜。
QCode 能接住什么、接不住什么
能接住的：同一把密钥可以在拥塞时切到别的模型家族继续干活，不必干等某一个模型恢复。接不住的：我们不是模型厂商，改不了厂商的服务器容量；经 QCode 的请求同样可能失败。我们能提供的是换模型家族的选择，而不是一份不出故障的承诺。
常见问题
收到 529 要改我的请求参数吗？
不用。529 与请求内容无关，改 max_tokens、换模型参数、精简 prompt 都不会让它消失。要改的是重试策略。
529 和 429 我可以用同一套重试逻辑吗？
不建议。529 应当退避后重试同一请求；429 意味着你需要降低发送速率或提高额度，盲目重试只会持续触发限流。
退避多久合适？
常见做法是首次 1 秒、逐次翻倍，叠加随机抖动，并对重试次数与总等待时长设上限。具体数值取决于你的任务能容忍多长延迟。用 Claude Code 的话（截至 2026-10-08 官方文档与 CHANGELOG）：重试次数由 CLAUDE_CODE_MAX_RETRIES 控制，默认 10；2.1.286 起默认设置下一次失败的模型调用最多发出 14 次请求；2.1.292 起可以用 CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS 把 529 重试的基础延迟调长。
流式请求中途 529 了怎么办？
先看已经收到的内容是否可用。能续写就续，不能续再整体重试。盲目从头重试会重复计费，也会加重拥塞。
QCode 会遇到 529 吗？
可能会。厂商侧的拥塞是客观存在的，我们无法免疫；我们能做的是让同一任务可以切到别的模型家族，而不是承诺不出错。
多路可用性是不是就没有单点故障了？
不是。多路降低的是「一路挂了就停工」的概率，但每一路都有自己的故障形态，路由层本身也可能出问题。它是缓解，不是消除。
信息来源
状态码语义以厂商官方 API 文档为准。Claude Code 的重试行为与 CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS 来自 Anthropic 的 Claude Code CHANGELOG（2.1.286 与 2.1.292 条目）、这两个版本的 GitHub Release 页与 Claude Code 错误文档，均于 2026-10-08 抓取核对。本页不引用具体的第三方可用性百分比 —— 这类数字随时间波动，且我们没有权威的第三方测量来源。
相关阅读
本页的状态码语义以各厂商官方文档为准，可能随版本调整；Claude Code 相关内容核对于 2026-10-08，以官方 CHANGELOG 与文档为准。本页内容不构成任何可用性承诺。