团队五个服务共用一个 key，某天开始零星返回 429，错误体写 rate_limit_error，控制台显示本月用量还不到一半，调用量也没有明显上涨。
一开始怀疑是「并发连接数过高触发按秒的窗口限制」，查了一圈，方向不对。
原因不止一个，得分开看。限制分 RPM 与 TPM 两条，token 维度先被打满。还有一种是新旧 key 的额度独立计算，刚切换的 key 从零开始计。
还有一种情况，输入长度暴涨导致单次请求折算的 token 极多。
上来先统计最近一分钟的请求数和 token 数
python -c "import json;d=[json.loads(l) for l in open('calls.jsonl')];print(len(d), sum(x.get('input_tokens',0) for x in d))"随后把重试集中到单点，避免五个服务各自退避
python -c "print('use shared limiter with redis token bucket')"等前面都确认过，再用最小请求探测当前是否已恢复
curl -sS -o /dev/null -w '%{http_code}\n' https://api.anthropic.com/v1/messages -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" -d '{"model":"claude-3-5-haiku-20241022","max_tokens":8,"messages":[{"role":"user","content":"hi"}]}'别只看报错消失，验证要多做一步。连续十分钟 429 占比为零，探测请求稳定返回 200，每分钟请求数与 token 数都落在控制台展示的配额曲线之下。
这里还有个坑。共用 key 的团队最容易撞限流，客户端各自退避会互相踩踏，把限速放到共享存储里统一发令牌才有效。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。