Claude Fable 5 的 529 overloaded_error

529 到底是什么造成的

四个成因全在 Anthropic 那一侧。改请求体对它们都没有作用。

• Fable 5 的长回合拉长了暴露窗口

  在较高 effort 下，Fable 5 处理困难任务的单个请求可以跑好几分钟。请求在途时间越长，与容量事件重叠的概率越大；而流式过程中发生的过载，是在 200 已经返回之后才到达的。

• 没有任何提前预警的响应头

  和 429 不同，过载不会给你剩余容量类的响应头可以观察。你无法从响应元数据预测 529，所以处理方式只能是被动退避，而不是主动限速。

• 需求集中在某一个模型上

  容量是按模型分别追踪的，所以 Fable 5 可能已经饱和，而 Opus 5 和 Sonnet 5 仍然正常服务。Claude Code 把这一点做成了明确提示：某个模型负载特别高时，它会提示你运行 /model 切换。

• 是平台级容量，不是你的账号

  529 出现在 API 承受所有用户高流量的时候。你所在组织的档位、消费上限、速率限制都与是否遇到 529 无关。两个用量模式完全不同的客户，会在同一个时间窗口里同时看到 529。

按这个顺序修

第一、二步能覆盖绝大多数情况。第三到第五步针对持续性故障和无人值守的任务。

1. 1

   1. 用指数退避重试

   以指数增长的延迟加抖动重试。官方 SDK 对 5xx 响应默认已经重试 2 次；应该调高客户端的 maximum-retries 选项，而不是在外面再套一层重试，那样是把尝试次数相乘而不是延长等待。

2. 2

   3. 升级之前先看状态页

   去 status.claude.com 确认是否有已发布的故障公告。在其他部署形态下，检查错误信息里指明的服务商或网关主机。如果错误持续而没有任何公告，就提交工单，并附上错误体里的 request_id。

3. 3

   2. 不要立即重试，也不要整齐划一地重试

   紧凑的重试循环会让容量事件更糟，还白白烧掉你每分钟的请求配额。加上抖动，避免一整批 worker 把重试对齐成惊群，一起砸向本来就已经饱和的模型。

4. 4

   4. 自己实现切换到另一个模型

   因为容量按模型分别追踪，在 Fable 5 容量事件期间路由到 claude-opus-5 通常能拿到响应。这段逻辑要你自己写：fallbacks 参数只在安全分类器拒答时触发，过载时永远不会。

5. 5

   5. 在 Claude Code 里为无人值守任务放宽重试预算

   Claude Code 对瞬时失败已经用指数退避最多重试 10 次，由 CLAUDE_CODE_MAX_RETRIES 控制。对 CI 任务和评测流水线，把 CLAUDE_CODE_RETRY_WATCHDOG 设为 1，让 429 和 529 这类容量错误无限重试，而不是直接让整个运行失败。

相关页面