Claude API 报错 429 怎么办？4 种方案实测，最后一种最省事

上周用 Claude Opus 4.6 跑一个批量代码审查脚本跑到第 30 条请求的时候控制台开始疯狂刷429 Too Many Requests。这个错我之前零星遇到过但这次直接把整个流水线卡死了排查加修复折腾了差不多一天半。把踩过的坑和最终方案记录下来省得再走一遍。Claude API 返回 429 错误本质是触发了 Anthropic 的速率限制。解决方案有四种调整请求频率加退避重试、申请更高 Tier 的速率配额、用令牌桶做客户端限流、或者换聚合 API 平台绕开单一供应商的限制瓶颈。下面逐个讲怎么操作。先说结论方案实现难度见效速度适合场景指数退避重试⭐ 低即时偶尔触发 429请求量不大申请提升 Rate Limit Tier⭐ 低1-3 个工作日长期高频调用有充值记录客户端令牌桶限流⭐⭐ 中即时批量任务、脚本场景换聚合 API 平台⭐ 低即时不想折腾、多模型切换为什么会触发 429先搞清楚 Anthropic 的限流逻辑不然瞎调参数没用。Claude API 有三层限制同时生效RPMRequests Per Minute每分钟请求次数TPMTokens Per Minute每分钟 Token 吞吐量TPDTokens Per Day每日 Token 总量上限2026 年 Anthropic 的 Tier 体系大概是这样具体数字以官方文档为准这里列的是我账号实际看到的量级TierRPMTPM (输入)TPM (输出)触发条件Tier 1新号5040,0008,000注册即有Tier 21,00080,00016,000充值 $40Tier 32,000160,00032,000充值 $200Tier 44,000400,00080,000充值 $1,000我那次翻车就是因为脚本没做任何限流30 个并发请求一口气打上去Tier 2 的 RPM 上限直接打满了。429 响应头里会带retry-after字段告诉你多少秒后可以重试。很多人不看这个字段直接疯狂重试反而会被限得更狠。Claude API你的代码Claude API你的代码不看 retry-after立即重试 ❌读取 retry-after等待后重试 ✅请求 1-50正常200 OK请求 51超限429 Too Many Requestsretry-after: 30疯狂重试429限制加重等待 30s 后重试200 OK方案一指数退避重试最基础必须有不管你用哪种方案这个都是兜底逻辑必须加上。importtimeimportanthropic clientanthropic.Anthropic(api_keyyour-key)defcall_claude_with_retry(prompt,max_retries5):forattemptinrange(max_retries):try:responseclient.messages.create(modelclaude-sonnet-4-20250514,max_tokens1024,messages[{role:user,content:prompt}])returnresponseexceptanthropic.RateLimitErrorase:ifattemptmax_retries-1:raise# 优先读 retry-after 头retry_aftergetattr(e,response,None)ifretry_afterandhasattr(retry_after,headers):wait_timeint(retry_after.headers.get(retry-after,0))else:wait_time0# 没有 retry-after 就用指数退避ifwait_time0:wait_timemin(2**attempt*1.5,60)# 1.5s, 3s, 6s, 12s, 24sprint(f429 了第{attempt1}次重试等{wait_time:.1f}s)time.sleep(wait_time)returnNone# 测试resultcall_claude_with_retry(用一句话解释什么是 Rate Limit)ifresult:print(result.content[0].text)偶发的 429 基本第一次重试就过了等 1-2 秒的事。但如果是持续高频调用这个方案只是在拖时间治标不治本。踩坑点anthropicSDK 从 0.39 版本开始RateLimitError的异常结构变了老版本直接 catchAPIStatusError然后判 status code 才靠谱。建议先pip install --upgrade anthropic升到最新。方案二申请提升 Rate Limit Tier如果确实需要高频调用最正经的方式就是充钱升 Tier。操作路径Anthropic Console → Settings → Limits → 查看当前 Tier → 充值到对应门槛自动升级。花钱解决问题但有两个坑升 Tier 不是实时生效的充完 $200 等了差不多 6 小时才看到 Tier 3 的配额生效Tier 4 以上需要人工审核要填申请表说明用途提交后等了 3 个工作日方案三客户端令牌桶限流批量任务必备这是我最终在脚本里用的方案。原理很简单在客户端主动控制请求速率别等服务端拒绝你。importtimeimportthreadingfromopenaiimportOpenAIclassTokenBucketLimiter:简易令牌桶限流器def__init__(self,rpm40): rpm: 每分钟最大请求数建议设为实际限额的 80% self.rpmrpm self.interval60.0/rpm# 每次请求的最小间隔self.lockthreading.Lock()self.last_request_time0defwait(self):withself.lock:nowtime.time()elapsednow-self.last_request_timeifelapsedself.interval:sleep_timeself.interval-elapsed time.sleep(sleep_time)self.last_request_timetime.time()# 用 OpenAI 兼容接口调用 Claude方便切换不同平台clientOpenAI(api_keyyour-key,base_urlhttps://api.ofox.ai/v1# 聚合接口一个 Key 调所有模型)limiterTokenBucketLimiter(rpm40)# Tier 1 限 50留 20% 余量defbatch_review(code_snippets):results[]fori,codeinenumerate(code_snippets):limiter.wait()# 自动控制速率try:responseclient.chat.completions.create(modelclaude-sonnet-4-20250514,messages[{role:system,content:你是一个代码审查助手},{role:user,content:f审查这段代码\n\n{code}\n}],max_tokens512)results.append({index:i,review:response.choices[0].message.content,status:ok})print(f[{i1}/{len(code_snippets)}] 完成)exceptExceptionase:results.append({index:i,review:None,status:ferror:{e}})print(f[{i1}/{len(code_snippets)}] 失败:{e})returnresults# 模拟 50 个代码片段的批量审查snippets[fdef func_{i}():\n return{i}* 2foriinrange(50)]resultsbatch_review(snippets)successsum(1forrinresultsifr[status]ok)print(f\n完成{success}/{len(snippets)}成功)50 个请求跑下来零 429总耗时约 75 秒RPM40 的话平均 1.5s 一个请求。比之前不限流然后疯狂重试反而快——之前那种方式跑 50 个请求要 3 分多钟重试等待的时间累积起来很夸张。方案四用聚合 API 绕开单一供应商瓶颈这是我现在的日常方案。原理不复杂聚合平台后面挂了多个供应商节点Azure、Bedrock、VertexAI 等请求会被分发到不同节点相当于把流量天然打散了单一节点的 Rate Limit 很难被触发。ofox.ai 是一个 AI 模型聚合平台一个 API Key 可以调用 Claude Opus 4.6、GPT-5、Gemini 3、DeepSeek V3 等 50 多个模型低延迟直连无需代理支持支付宝付款。它后面有多供应商冗余备份实测高频调用下 429 的概率比直连 Anthropic 官方低很多。改造成本极低就改一行base_urlfromopenaiimportOpenAI# 官方直连容易 429# client OpenAI(api_keysk-ant-xxx, base_urlhttps://api.anthropic.com/v1)# 换聚合平台改这一行就行clientOpenAI(api_keyyour-ofox-key,base_urlhttps://api.ofox.ai/v1)responseclient.chat.completions.create(modelclaude-sonnet-4-20250514,messages[{role:user,content:解释一下 429 状态码}],max_tokens256)print(response.choices[0].message.content)用同样的批量脚本50 个请求不加任何限流测了一下全部 200零 429。当然聚合平台也有限制只是阈值高很多日常开发基本碰不到。踩坑记录坑 1并发 重试 雪崩一开始用asyncio开了 10 个并发每个协程各自有重试逻辑。结果 429 一触发10 个协程同时等retry-after秒然后同时重试又同时 429……来回震荡了好几轮。解决办法是重试时加随机抖动jitterimportrandom wait_timemin(2**attempt*1.5,60)random.uniform(0,1)坑 2Streaming 模式下 429 的表现不同非 Streaming 模式 429 会直接抛异常但 Streaming 模式下有时候连接能建立前几个 chunk 能收到然后中途断掉抛APIConnectionError。一开始没把这个归类到限流问题排查了半天以为是网络问题。坑 3不同模型的 Rate Limit 是独立的Claude Opus 4.6 和 Claude Sonnet 4.6 的 RPM 限制是分开算的。混合调用不同模型时别按总量算限流要按模型分别算。小结四种方案怎么选看场景偶尔 429方案一指数退避就够了几行代码的事长期高频调方案二升 Tier 方案三客户端限流组合用不想折腾、多模型切换方案四聚合平台改一行base_url搞定最佳实践方案三 方案四叠加客户端限流兜底聚合平台扛峰值我现在就是方案三和方案四叠着用跑了两周批量任务再没遇到过 429。