Claude Fable 5 的 429 rate_limit_error

你撞的到底是哪条限额

错误信息会说明超出的是哪条限额。动手改任何东西之前，先把它读完。

• 流量陡增触发的加速限制

  组织用量急剧上升时，即使你还在公布的档位数字之下，也可能因为加速限制而收到 429。应该逐步放量、保持用量模式稳定，而不是把一个新工作负载一次性开到满量。

• 每分钟输入 token

  这是大多数 Fable 5 用户最先撞上的维度：Start 档只有 500,000 ITPM，Opus 5 是 2,000,000，而 Fable 5 的 100 万 token 上下文窗口又鼓励你塞超大提示。只有未缓存的输入计入，即 input_tokens 加 cache_creation_input_tokens，缓存读取不计。

• 每分钟输出 token

  Fable 5 在 Start 档是 100,000 OTPM，Build 档 300,000，Scale 档 800,000。OTPM 是按实际产出的 token 实时评估的，max_tokens 不参与计算。高 effort 下的长时间自主运行，消耗这个维度的速度比其他模型的短回合快得多。

• 每分钟请求数

  Fable 5 在 Start 档是 1,000 RPM，Build 档 2,000，Scale 档 4,000。限流器用的是持续补充的令牌桶，而不是固定时刻重置，所以一次突发可能在一秒内耗掉一分钟的额度，即便你的平均速率远低于限额也会触发 429。

• 请求走了错误的凭据

  限额在组织层面强制执行，工作区可以另外设更低的限额。环境里残留的 ANTHROPIC_API_KEY 会把流量路由到一个低档位的 key 上，于是你撞的是那个 key 的限额，而不是你以为的那个账号的。

按这个顺序修

先读响应，再降需求，最后才申请扩容。没做好缓存就去申请提额，拿到的额度通常还不如缓存省下来的多。

1. 1

   3. 把提示里重复的部分缓存起来

   对大多数模型来说，cache_read_input_tokens 不计入 ITPM。在 2,000,000 ITPM 限额下、80% 的缓存命中率，你每分钟可以处理 10,000,000 总输入 token。把系统指令、工具定义、大型上下文文档和会话历史都缓存起来。

2. 2

   4. 从源头降低并发

   在自己的客户端里限制在途请求数，用排队代替扇出。在 Claude Code 里调低 CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY（默认 10），避免同时跑大量并行子代理，高频脚本化任务用 /model 换成更小的模型。

3. 3

   2. 从响应头判断是哪个维度

   读 anthropic-ratelimit-requests-remaining、anthropic-ratelimit-input-tokens-remaining、anthropic-ratelimit-output-tokens-remaining，以及对应的 limit 和 reset 头。优化错维度是这里最常见的无用功。

4. 4

   1. 严格等满 retry-after 给的秒数

   retry-after 头给出的是可以重试之前需要等待的秒数。早于这个时间发起的重试必然失败，所以把它当成下限而不是建议，并在一整批 worker 上再叠加抖动。

5. 5

   5. 带着真实数字去申请提额

   在 Claude Console 的 Limits 页面点 Request rate limit increase。准备好每个模型每分钟输入和输出 token 的峰值，以及输入中缓存或重复上下文所占的大致比例，申请表就是按这些来评估的。

相关页面