如果 Claude API 返回 529 overloaded_error，第一判断应是 Anthropic 侧容量过载，而不是密钥失效、账单异常、个人额度耗尽或账号被限制。最容易走错的是把它当成 429 rate_limit_error：429 才是限流或额度分支，529 是过载分支。
前一分钟只做小而有序的动作：记录 Claude Status 的当前状态和时间，用带抖动的有限重试确认是否短暂恢复；如果调用方由你控制，就降低并发、暂停非紧急批处理、让队列吸收压力；最后保持同一个模型、端点、鉴权路径和请求形状再验证一次。相同路径仍然返回 529 时，保留完整错误体和 request_id，再进入升级。
状态页只能作为时间戳证据。这个 run 在 2026-04-29 11:02 UTC 检查时，公开状态 API 显示 all systems operational，但事件流里仍有 4 月 28 日和 4 月 29 日 UTC 近期已解决的 elevated-error 记录。绿色状态能缩小判断范围，却不能证明你的具体路径已经恢复。
一分钟分支表
先看精确信号，再决定动作。不要一上来换 key、升级套餐、改 prompt 或随机切换 provider。
| 精确信号 | 先按什么处理 | 第一动作 | 同路径验证 | 停止或升级条件 |
|---|---|---|---|---|
529 或 overloaded_error | Anthropic 容量过载 | 查状态，再做有限抖动重试 | 同模型、同端点、同鉴权、同请求形状 | 状态、重试预算和降压后仍持续 |
429 或 rate_limit_error | 限流或额度 | 看 retry-after、限额和当前 credential route | 等允许窗口或修正 route 后再试 | header 与 Console 仍指向限制 |
500 或 api_error | 服务端错误 | 查状态，保留 request_id，短暂停顿后重试一次 | 相同请求短暂停顿后再跑 | 无事件但同路径持续失败 |
504 或 timeout_error | 超时 | 缩短请求、开启 stream 或拆分任务 | 做一次明确形状变化后验证 | 长请求仍超时 |
| Claude Code 终端反复 529 | Claude Code 终端面 | API 含义明确后进入终端分支 | 同 session、同 route 冷却后再试 | 状态和 route 检查后仍持续 |
工作结论很简单：529 先按过载处理。除非错误变成 429、鉴权错误或明确的 provider 限制，否则不要从账号、账单、key 轮换或 prompt 重写开始。
529 在 Claude API 里意味着什么
Anthropic API 错误文档把 HTTP 529 定义为 overloaded_error，并把它和 429 rate_limit_error、500 api_error、504 timeout_error 分开。这个官方分类就是恢复动作的边界。
差异的核心是责任归属。真实 529 表示服务处于过载或容量压力下。你的客户端仍然要表现得更克制，但第一解释不是“我的账号没有额度”。真实 429 才指向请求速率、加速限制、模型限额、账号上限或 provider 上限。500 更偏服务端错误处理与证据保留。504 则要求关注请求时长、stream、批量大小和任务拆分。
很多错误修复来自把这些分支压成一个“请求失败”。团队看到请求被挡住，就套用最熟悉的动作：像 429 一样只降速，像鉴权问题一样换 key，或者像线路坏了一样马上换 provider。那些动作在某些分支有价值，但干净的 529 不应从这里开始。
request_id 也要从第一轮就保留。Anthropic 文档说明错误响应会包含 request_id，响应 header 也可能有 request-id。当 529 持续时，这个标识比“我们试过很多办法”的叙述更有用。
安全恢复循环
生产级 529 处理应该克制：确认状态、短预算重试、降低压力、同路径验证，然后停止或升级。目标不是让客户端更努力，而是在不过度加压的前提下保留足够证据。
先查实时状态，并记录时间。最好统一用 UTC，或写清楚你的运营时区。如果有活跃 incident，不要同时改模型、改路由、改请求大小和改鉴权。保持失败请求形状，暂停一段时间，等状态改善后再验证。
如果状态是绿色，或没有公开 incident，就使用有上限的重试预算。合理实现通常包括指数退避、随机抖动、最大尝试次数或最大总耗时，并且只重试适合重复的请求。读请求和带去重策略的生成请求更适合重试；有副作用的工作流需要更短预算或人工确认。
然后降低调用方压力。降低并发、暂停非紧急批量任务、把后台工作排队、让次要功能进入降级模式。这不是说 529 是你的错，而是所有客户端在 provider 过载时激进重试，都会把压力推回同一个受限系统。
最后做同路径验证。保持模型、endpoint、鉴权所有者、代理路径和请求形状稳定，除非你正在有意验证其中一个变量。如果一次改五个变量后成功，你无法知道是过载恢复、route 改变，还是请求变轻了。
反复 529 的生产控制
手工 playbook 只解决当下，服务本身也要有相同纪律。第一层是 retry budget，不是无限循环。按业务价值设置最大尝试次数、最大耗时和过期时间。聊天回合、后台批处理和交易性工作流不应共享同一个重试策略。
第二层是 jitter。固定间隔会把大量请求同步打回 provider，这正是过载系统最不需要的流量形态。抖动能把请求打散，让恢复过程不那么尖锐。
第三层是 circuit breaker。当 529 比例超过阈值，打开 breaker，排队非紧急任务，降级可选功能，并向用户给出清晰但不过度承诺的提示。关闭 breaker 时只用少量同路径探针，不要一次性恢复所有批量流量。
还要把“降低压力”和“改变路线”分开。降低压力是减少并发、缩小批处理窗口、延后任务；改变路线是换模型、换端点、换 provider 或换鉴权所有者。路线切换可以保护非关键流程，但它会改变证据链和产品行为，必须是明确决策。
观测字段不需要复杂到失控。记录错误类型、HTTP 状态、模型、端点、鉴权路线、请求大小等级、重试次数、最终结果和 request_id。这样就能回答关键问题：同一路径在预算内恢复了吗，还是仍然是 provider 过载？
如果调用链里有自建代理或统一网关，也要把 upstream route 与 downstream response 分开记录。代理层的排队、超时、重试或连接池耗尽，可能把 provider 侧 529 和本地拥塞叠在一起。记录两层时间线可以避免把本地排队误判成 Anthropic 全局过载，也能避免在 provider 恢复后继续用过宽的降级策略。
Claude Code 里看到 529 时
先用 API 层含义定性：529 overloaded_error 仍然是过载优先。若症状出现在 Claude Code 终端，终端面会增加自己的分支规则，但不会把 529 变成账单问题。
Claude Code 文档把反复 529 描述为跨用户的临时容量问题，并说明 Claude Code 在显示该信息前已经重试过，同时把它和 usage limit、quota wording 分开。因此，终端反复 529 更适合交给 Claude Code overloaded error 指南，而不是跳到通用账单或套餐页面。
如果终端信息混着 500、529、429、temporary limiting 或 route confusion，就用更宽的 Claude Code 500、529 与 rate limit 路由。那个分支专门处理终端把多个错误挤在一起的情况。
API 团队还要检查 route ownership。shell 里的环境变量、代理、SDK wrapper 或 provider gateway 可能让请求走到你没打算测试的路径。只有某个 wrapper path 返回 529 时，先用预期路线跑同一请求，再判断是否是整个 Claude API 表面的问题。
升级证据包
升级应该发生在有序恢复之后：当前状态已经记录，重试保持有限，能降压的地方已经降压，同一路径仍然返回 529。证据包越短越好，但关键字段不能少。
- 精确 HTTP 状态和错误类型，包括
529 overloaded_error - 完整错误体和可用的
request_id - 模型、endpoint、SDK 或 gateway route、鉴权所有者
- 带时间戳的 Claude Status 结果，以及相关近期 incident 记录
- 重试次数、backoff 窗口、是否使用 jitter
- 失败时的并发量或批处理压力
- 去除密钥后的最小复现请求形状
- 一句话业务影响，例如生产任务阻塞、用户流程降级或非紧急批处理延迟
支持团队不需要你所有本地实验。他们需要确认分支确实是 529，客户端没有制造无限重试风暴，并且同一路径在合理控制后仍然失败。到这个边界还继续随机更改，通常只会破坏证据。
常见问题
Claude API 529 和 429 一样吗？
不一样。Anthropic 把 529 定义为 overloaded_error，把 429 定义为 rate_limit_error。529 先按过载处理，429 才进入限流或额度分支。
529 说明账号或账单坏了吗？
不能这样作为第一解释。干净的 529 overloaded_error 指向容量过载。只有错误类型变化、实际 route 与预期不一致，或另有账单/鉴权信号时，才转入账号和账单排查。
Claude Status 是绿色但仍然 529，怎么办？
把绿色状态当成带时间的信号，而不是精确路径已恢复的证明。短预算抖动重试，降低你控制的流量压力，再用同模型、同 route、同鉴权、同请求形状验证。仍失败时带 request_id 升级。
重试多少次安全？
用预算，不用固定神奇数字。限制尝试次数或总耗时，加入 jitter，只重试可重复的工作。用户可见价值很快过期的请求，重试预算也应该短。
529 出现时该不该换模型或 provider？
可以作为明确的业务路线决策，但不应作为第一诊断动作。切换能保住非关键流程，却会隐藏原路径是否恢复，并改变质量、成本和证据链。
应该发什么给 Anthropic support？
发送错误体、request_id、模型、端点或 gateway route、鉴权所有者、状态页时间、重试时间线、当时压力水平和最小复现。去掉密钥，保持分支清楚。
工作规则
Claude API 529 是过载优先分支。先查带时间的状态，再用有限抖动重试和降压保护同一路径；同一路径仍返回 529 overloaded_error 时，带 request_id 和恢复证据升级。