你在跑一个用 Claude API 的脚本——比如批量翻译 200 篇文章、用 agent 自动处理客服工单——结果跑到一半就开始反复报 429 rate_limit_exceeded，而你的脚本死循环式重试，反而把限流锁得更死。又或者你在 Claude Code 里让 agent 跑大任务，agent 自己撞墙也不停手，越撞越紧。
Claude 的 rate limit 有两层：RPM（每分钟请求数）和 TPM（每分钟 token 数）。两层都会触发 429。问题不在限流本身，而在你的客户端没正确处理 retry-after，越急越糟。
常见原因
按命中率从高到低：
1. 死循环重试，不看 Retry-After header
Anthropic API 在 429 响应里会带 retry-after header（秒数）。如果你的脚本拿到 429 就立刻 retry，每次都被拒，触发更长的限流。
如何判断：你的代码里 retry 逻辑是固定 sleep（如 sleep(1)）还是读 retry-after？固定 sleep = 这就是原因。
2. 并发扇出太大，瞬时打爆 RPM
你 Promise.all 同时发 50 个请求，瞬时 RPM 远超你 tier 的上限。即使每分钟平均没超，瞬时峰值也会触发。
如何判断：脚本是否用 Promise.all / 多线程 fan-out？多大？
3. 长 context 把 TPM 用爆
每个请求都带 100K input token，跑 5 个 = 500K，超 Sonnet tier 1 的 TPM 上限。Output token 也算 TPM。
如何判断：算一下你单请求的 input token × QPS，对比 Anthropic Rate Limits 你的 tier。
4. Agent 不知道停手
Claude Code 或自定义 agent 看到 tool 返回 429，可能把它当成”暂时不可用”继续 retry。如果你没写明确的失败处理，agent 会无限拖。
如何判断：agent 日志里 429 出现 > 5 次。
5. Pro / Team 套餐到日上限
订阅版有 daily message cap（按 5 小时 window）。撞了之后所有请求都 429，要等 window reset。
如何判断：UI 上是否出现 “You’ve reached your daily limit, resets in X hours.”
6. 多个 client 共用一个 API key
后端、cron job、CI 都用同一个 key，每个都觉得自己 RPM 够用，加起来超额。
如何判断：API console 看 key 的请求来源 IP 是否多个。
最短修复路径
Step 1：先把循环停了，退避 5-10 分钟
# 找到正在跑的脚本 PID 并 kill
ps aux | grep my-script
kill -9 <PID>或在 Claude Code 里 Ctrl+C 中断 agent。等 5-10 分钟让限流窗口完全 reset，再处理。
Step 2：实现正确的指数退避
# Python 示例
import time
import anthropic
from anthropic import RateLimitError
client = anthropic.Anthropic()
def call_with_backoff(prompt, max_retries=5):
for attempt in range(max_retries):
try:
return client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[{"role": "user", "content": prompt}]
)
except RateLimitError as e:
wait = int(e.response.headers.get("retry-after", 2 ** attempt))
print(f"Rate limited, sleeping {wait}s")
time.sleep(wait)
raise Exception("Max retries exceeded")关键：读 retry-after，不要固定 sleep。
Step 3：限制并发
# 用 semaphore 限制同时只跑 N 个
import asyncio
sem = asyncio.Semaphore(3) # 同时最多 3 个
async def safe_call(prompt):
async with sem:
return await call_with_backoff(prompt)Tier 1 推荐并发 ≤ 5，Tier 2 ≤ 10，按 RPM/60 算自己的上限。
Step 4：合并请求
把 10 个小翻译合并成 1 个 prompt 让 Claude 一次返 10 个结果，RPM 立即除以 10：
prompt: 翻译下面 10 段英文为中文，按 JSON 数组返回：
[
"text 1",
"text 2",
...
]注意输出 token 仍占 TPM，但 RPM 大幅降低。
Step 5：换轻模型 / 用 batch API
不需要 Opus 的任务用 Sonnet / Haiku，TPM 配额相对更宽松。或用 Batch API——异步、不占实时 quota、价格 50% off。
Step 6：升级 tier 或拆 key
如果是 production 工作量，申请升 tier。短期方案：给不同 service 用不同 API key，每个 key 独立 quota。
Step 7：日上限的话只能等
Pro / Team 撞日上限：在 UI 顶部会显示 reset 时间，等到那时再用。或临时切到 API + pay-as-you-go。
预防建议
- Anthropic SDK 自带 retry 机制（默认 2 次指数退避），用
max_retries=N调整而不是自己实现 - 任何脚本启动前先估算 peak TPM/RPM，对比 tier 上限留 20% buffer
- 不要在 cron 整点（00:00, 05:00, …）发批量任务，加随机抖动避开峰值
- 后端、CI、cron 用不同 API key，便于隔离故障
- 监控 429 比例：> 1% 就该考虑升 tier 或优化请求模式
- 大批量任务首选 Batch API，省钱省 quota