Anthropic API 速率限制：三条轴怎么计量、撞上了该怎么修
多数团队遇到速率限制的方式都一样：开发阶段跑得好好的，上了生产、并发一起来就开始返回 429。解决办法很少是"申请更多配额"，而通常是先搞清楚是哪一条限制在卡——因为它们的计量方式不同，缓解手段也完全不同。
三条限制，分别计量
Anthropic 的 API 同时在多个维度上执行限制。只要请求会超出其中任意一条，它就会被拒绝。
每分钟请求数（RPM）。 一个组织在滚动的一分钟内可以发起多少次 API 调用。大量小请求突发时最先撞的就是它——它不关心每个请求有多大。
每分钟输入 token 数（ITPM）。 每分钟可接受的提示内容总量。长上下文的工作负载远在撞到请求数上限之前就会撞上它。一个每次调用都发送超大提示的流程，几次调用就能把它吃光。
每分钟输出 token 数（OTPM）。 每分钟生成内容的总量。长文本生成、以及会产出大段 diff 的智能体循环，通常是原因。
由此带来的实际后果是：两个应用发出同样次数的调用，限制表现可能完全不同，因为一个发的是 2000 token 的提示，另一个发的是 15 万 token 的提示。排查 429 时，第一个问题是哪条轴被打满了，而不是"我发了多少请求"。
限制按组织计、按模型分别计，并随用量层级提升——层级依据付款历史与累计消耗自动推进，而不是靠申请。由于具体上限会调整，任何公开数字都应视为"阅读当时有效"，设计前请以自己账户的限额页面为准。
怎么读这个响应
被拒的请求返回 HTTP 429。响应里有两样东西比状态码本身更重要：
retry-after响应头告诉你该等多久。遵守它比用固定退避更有效，因为它反映的是真实窗口，而不是你对窗口的猜测。- 错误信息会写明是哪条限制被超出——请求数、输入 token 还是输出 token。这是整次交互里最有用的诊断信息，而只记录状态码的客户端代码通常把它直接丢掉了。
响应里还带有描述当前窗口剩余容量的响应头。把这些和自己的请求指标一起记录下来，限额排查就从猜谜变成了算术。
每种情况各自该怎么修
如果卡在每分钟请求数： 减少调用次数，而不是调用大小。任务允许的话，把彼此独立的条目合并成更少的调用。在客户端加并发上限，别让并行 worker 加起来超过天花板——不设上限的 worker 池每次都能把限额找出来。
如果卡在每分钟输入 token： 这是 prompt 缓存作用最大的地方。智能体和 RAG 类负载每轮都重发一大段稳定前缀；命中缓存的前缀既更便宜，在输入 token 这条轴上也更轻。除缓存外，还要真正精简重发的内容——没有变化的完整文件正文、已经失去价值的历史对话、检索回来但没用上的片段。
如果卡在每分钟输出 token： 把 max_tokens 收到任务真正需要的量，别为了"以防万一"留一大截余量；长生成拆成多个阶段。一个 800 token 就能完成的任务却允许它生成 8000 token，等于为同样的结果消耗十倍预算。
值得上线的重试逻辑
带抖动的指数退避，有 retry-after 时优先遵守，并设最大延迟与最大重试次数上限。有两个细节常被忽略，而且都会引发故障：
抖动不是可选项。 没有抖动时，同一秒失败的所有客户端会在同一秒重试，重试风暴会把导致失败的条件重新制造一遍。
要区分 429 和 529。 速率限制是"你的流量撞上了你的上限"，靠控速解决。过载响应是上游的容量状况，需要更长、更有耐心的退避，而不是更激进的重试。
对延迟不敏感的请求应该走 Message Batches API，它是异步处理、有自己独立的容量——把后台任务挪过去，就能给交互路径腾出空间。
容易被忘掉的一层
如果请求不是直连 Anthropic，而是走网关或中转端点，那么同时存在两套限制：上游账户的，以及中间端点对自己用户执行的那一套。429 可能来自任何一边，靠错误响应体才能分辨。评估一个端点时要问清楚：它自己的每个 key 限额是多少、prompt 缓存是否端到端支持、以及限额响应头是否透传——一个把这些头剥掉的端点，等于剥夺了你主动控速的能力。这一层在哪些地方帮忙、在哪些地方反而增加故障点，见 LLM API 网关是什么。
成本与速率限制也是联动的：能降低账单的那套缓存，同时也在降低输入 token 的压力。同一机制的计费侧见 Claude API 价格。
常见问题
为什么我请求数很少也会被限速？
几乎可以肯定是输入 token 这条轴。少量的长上下文调用，完全可能在请求数很低的情况下超出每分钟 token 上限。
怎么提高限额？
限额随用量层级提升，而层级依据付款历史与累计消耗推进。标准层级没有单次请求的临时放宽；持续大流量的组织需要直接谈容量。
prompt 缓存只是省钱，还是也能缓解限速？
两者都有。命中缓存的前缀内容更便宜，在输入 token 吞吐上的计入方式也不同，所以对长上下文负载来说，缓存是杠杆最大的一项改动。
429 和 529 有什么区别？
429 是你的流量超了你的限额——请自己控速。529 是服务过载——退避要更久、重试要更有耐心。把两者同等对待会让后者更糟。
后台任务该和交互请求走同一条路吗？
不该。异步批处理有独立容量，把不紧急的工作挪过去，可以避免它和交互路径抢配额。