上周三我在 Cline 里跑一个批量代码的脚本claude-sonnet-5.5 疯狂报 429。一开始以为是余额不够充了钱还是一样。折腾了大半天才搞明白429 不是一个错误是两个独立的错误——RPM每分钟请求数和 TPM每分钟 token 数各有各的桶触发阈值不同解法也不同。你得先看报错消息里写的是requests per minute还是tokens per minute然后针对性地改退避策略盲目time.sleep(5)没用。为什么 sonnet-5.5 容易触发 429根源不在模型本身在你的账户 Tier 等级和 sonnet-5.5 的 token 消耗模式。Anthropic 的限流按 usage tier 划分新账户默认 Tier 1。截至本文发布时claude-sonnet-5.5API model ID 是claude-sonnet-5.5在 Tier 1 的限制限制维度Tier 1 数值RPM每分钟请求数50TPM每分钟 token 数40,000TPD每天 token 数1,000,00050 RPM 听着还行对吧但 TPM 只有 40,000。一个中等复杂度的 prompt比如贴 200 行代码让它 review轻松吃掉 2,000 input tokens加上输出可能到 3,000-4,000 tokens。算一下40,000 ÷ 5,000 8 个请求就把 TPM 桶打满了。你根本用不到 50 RPMTPM 就先爆了。sonnet-5.5 输出更详细这是好事但代价是单次 output tokens 普遍更多TPM 桶更容易被打穿。第一步区分到底是 RPM 还是 TPM 超限报错信息里已经写清楚了很多人没仔细看。TPM 超限长这样{type:error,error:{type:rate_limit_error, message:Rate limit exceeded: Number of request tokens per minute has been exceeded.}}RPM 超限长这样# anthropic.RateLimitError: Error code: 429 # message 里是 requests per minute关键词就两个tokens per minute和requests per minute。我之前一直没注意这个区别以为 429 就是 429其实治法完全不同。graph TD A[收到 429 错误] -- B{查看 message 字段} B --|包含 tokens per minute| C[TPM 超限] B --|包含 requests per minute| D[RPM 超限] C -- E[减少单次 token 用量 / 降低并发] D -- F[降低请求频率 / 加间隔] C -- G[读取 x-ratelimit-reset-tokens 精准等待] D -- H[读取 x-ratelimit-reset-requests 精准等待]第二步别盲等——从响应头读精确重置时间很多教程教你time.sleep(60)太蠢了。Anthropic 每次响应都带了限流头告诉你还剩多少配额、多久重置。以 RPM 为例响应头长这样x-ratelimit-remaining-requests: 0 x-ratelimit-reset-requests: 30sreset-requests: 30s意思是 30 秒后请求配额重置。TPM 对应的头是x-ratelimit-reset-tokens同理。直接用这个值不用猜。读取方式用 httpx 能拿到原始响应头分别对应 TPM 和 RPM 两种情况# TPM 超限时读这个 reset_tokens resp.headers.get(x-ratelimit-reset-tokens) # RPM 超限时读这个 reset_requests resp.headers.get(x-ratelimit-reset-requests) # 返回类似 30s解析数字后直接 sleep同理还有x-ratelimit-remaining-tokens和x-ratelimit-remaining-requests可以提前判断下一个请求会不会超。第三步重写指数退避——加 jitter设上限官方推荐指数退避但很多人写的版本有两个问题没加随机抖动jitter没设最大等待。结果多个并发客户端同时醒来、同时重试、同时又被限——多个客户端同时重试、再次同时触发限流。公式wait min(2^attempt random(0,1), 64)import anthropic import time import random client anthropic.Anthropic() for attempt in range(8): # 8 次重试attempt 0–7第 7 次等待约 128jittermin 后为 64s可触达上限 try: r client.messages.create( modelclaude-sonnet-5.5, max_tokens1024, messages[{role: user, content: hi}] ) break except anthropic.RateLimitError: wait min(2 ** attempt random.uniform(0, 1), 64) time.sleep(wait)八次重试的等待序列大概是~1.5s → ~2.5s → ~5s → ~8.5s → ~17s → ~33s → ~64s → ~64s64 秒上限从第 7 次attempt62^664起开始实际触达。注意退避等待时间累计不保证限流窗口通常 60 秒一定完成重置——如果重试后仍然 429说明需要升 Tier 或改用 Batches API。如果你已经拿到了响应头里的x-ratelimit-reset-tokens或x-ratelimit-reset-requests直接用那个值替代公式算出来的 wait更精准。方案一升 Tier——花钱解决说实话这是最直接的办法。Tier 门槛截至本文发布时具体数值以 Anthropic 官方文档为准Tier累计消费门槛RPMTPMTier 1默认5040,000Tier 2$40详见官方文档详见官方文档Tier 3$200详见官方文档详见官方文档Tier 4$400详见官方文档详见官方文档充值消费达到门槛后去 console.anthropic.com/settings/limits 申请升级。$40 不算多如果你是正经在用几天就到了。方案二用 Batches API 绕开实时限流如果你的场景不需要实时返回比如批量代码、批量翻译、跑测试集Message Batches API 是正解。它不占实时 RPM/TPM 配额价格还打五折——以 claude-sonnet-5.5 为例Batches API 折扣后 input 和 output 均为官方定价的一半具体定价以 Anthropic 官网当前公布为准建议查阅时注意日期。适合一次性丢 500 个请求进去过几个小时来取结果的场景。不适合聊天、实时补全这种要即时响应的。方案三通过聚合网关做请求分流如果你同时在 Claude Code、Cline、Cherry Studio 这些工具里调 API每个工具各自重试、各自打限流桶很容易互相踩。一个思路是统一走聚合网关在网关层做限流和排队。OpenRouter 这类 API 聚合平台可以做这件事——改一个base_url就行不用改业务代码。需要注意的是聚合平台的官方授权状态及定价策略请以其官网当前公示为准使用前建议自行核实。# 以 OpenRouter 为例base_url 换成对应平台地址即可 from openai import OpenAI client OpenAI( api_keyyour-gateway-key, base_urlhttps://openrouter.ai/api/v1 ) 网关层会帮你做请求排队和限流平滑 x-ratelimit-remaining-requests / x-ratelimit-reset-requests 响应头同样可读 r client.chat.completions.create( modelanthropic/claude-sonnet-5.5, messages[{role: user, content: hi}] )好处是网关层帮你做了请求排队和限流平滑多个工具共用一个入口不会互相踩桶。当然如果你只用一个工具、请求量不大直连 Anthropic 官方 API 完全够用。常见问题 FAQQ: 怎么判断我当前是 Tier 几登录 console.anthropic.com进 Settings → Limits页面顶部会显示你当前的 tier 等级和各模型的具体限额。Q: claude-sonnet-5.5 的 API model ID 是什么API 调用时 model 参数填claude-sonnet-5.5。Q: 开了 streaming 还会被 TPM 限制吗会。streaming 只是改变了响应的传输方式TPM 按 input output 总量计算跟是否 streaming 无关。Q: 指数退避最多等多久合适建议最大 64 秒重试 8 次attempt 0–7。使用min(2^attempt random(0,1), 64)公式时attempt 需达到 6即第 7 次重试才能实际触达 64 秒上限若只重试 5 次最大等待约 17 秒64 秒上限永远不会被触达。超过 8 次还在 429说明你的请求模式和当前 tier 不匹配了应该升 tier 或改用 Batches API而不是无限等下去。Q: 多个工具Claude Code Cline共用一个 API Key限流是共享的吗是的。RPM 和 TPM 的限流绑定在 workspace 级别不是绑定在单个 key 上。多个工具用同一个 workspace 下的 key限流桶是共享的——一个工具打满了另一个也会 429。这也是为什么通过聚合网关统一管理多个工具调用会更可控后台能看到每个工具分别消耗了多少。我的最终方案我现在的做法分三层代码里加了带 jitter 的指数退避兜底充值到 $200 升了 Tier 3治本批量任务全走 Batches API不占实时配额如果你的场景是多工具并发调用、短期内升 Tier 不现实OpenRouter 提供了兼容 OpenAI 格式的base_url接入方式可以在网关层做请求排队把多个工具的流量合并到一个入口管理——具体限流策略和模型支持列表以平台官网当前公示为准。429 这个错误说白了不复杂但它有两个桶RPM 和 TPM你得分清楚是哪个桶爆了。大部分人的问题其实是 TPM 而不是 RPM因为 sonnet-5.5 的输出比较长。搞清楚这一点解法就很明确了。