Anthropic 统一 Claude API 速率限制分层：Sonnet/Haiku/Opus 同等配额对路由团队的影响

6 月 26 日，Anthropic 悄然推出了自 Mythos 5 上线以来最重要的速率限制更新：Claude Sonnet 4.x 和 Claude Haiku 4.5 在每个用量分层的 RPM、ITPM、OTPM 上限现已与 Claude Opus 4.x 完全一致。与此同时，五个原有分层被合并为三个——Start、Build 和 Scale——每个分层附带固定月度消费上限。如果你的路由策略建立在不同模型拥有独立配额桶的假设之上，这些假设已不再成立。

6 月 26 日的变化

此次更新前，Haiku 的 token 配额独立且低于 Sonnet 和 Opus。许多团队在构建回退链时，刻意将高并发、低优先级流量路由至 Haiku，以保留 Opus 的配额余量。这种套利策略已成过去。

各分层新的统一限制如下（适用于 Opus 4.x / Sonnet 4.x / Haiku 4.5）：

注意：速率限制仍按模型独立计算——Opus 流量不会消耗 Sonnet 的配额桶——但同一模型在各分层之间的限制已经对称统一。

Claude Fable 5 维持独立的限制表（Start：50 万 ITPM，Build：150 万，Scale：400 万），体现其更高的算力成本。

本次整合同时取消了中间分层。原本处于中间分层的组织将被自动划入最接近的分层；Anthropic 确认没有任何组织因此获得更低的限制。

各分层的月度消费上限

三层结构配套月度消费上限：

Custom 分层（合同定制）不设上限。对于 Scale 分层的团队，20 万美元/月通常足够，但请注意文档中关于加速限制的说明：流量突增会触发 429 错误，与分层限制无关，因此务必平滑扩容。

缓存感知 ITPM 的优势

Anthropic 速率限制设计中最容易被忽视的一点：哪些 token 不参与计量。除已下线的 Haiku 3.5 外，当前所有 Claude 模型的 cache_read_input_tokens（从缓存读取的 token）不计入 ITPM 配额。只有未命中缓存的输入 token（input_tokens + cache_creation_input_tokens）消耗配额。

实际效果：在 Build 分层（5M ITPM），若缓存命中率达到 80%，实际可处理的总 token 量约为每分钟 2,500 万。对于在多次请求间共享大型系统 prompt、工具定义或文档上下文的路由工作负载，这是一项持久的结构性优势。

使用共享缓存架构的路由团队——将通用系统 prompt 写入缓存后复用——可以在名义限制之外维持更高并发。速率限制 API（/manage-claude/rate-limits-api）支持以编程方式轮询剩余配额，从而构建动态路由：只有在实际未缓存 ITPM 压力达到阈值时，才降级到轻量模型，而非依赖静态预测。

对回退路由策略的影响

在旧的多分层、按模型独立配额体系下，许多团队采用如下回退链：

1. 主路由：Opus 4.x（质量最优，配额较低）
2. 回退：Sonnet 4.x（中间配额，独立桶）
3. 紧急回退：Haiku 4.5（高 RPM、低成本，独立较高限制）

这种方式通过将大量流量路由至 Haiku 独立配额桶来保留 Opus 余量。

配额统一后，以模型差异化来切分配额的策略已无效。各模型仍保持独立配额桶——Haiku 10K RPM 不会占用 Opus 的 10K RPM——但"用 Haiku 配额补 Opus 溢出"的逻辑已过时，因为两者在同一分层内上限相同。

正确的路由逻辑现在应聚焦于：

• 按任务的成本效益：高并发摘要用 Haiku，推理链用 Opus/Fable。配额对称，决策纯粹取决于成本和质量。
• 缓存命中率：设计可复用的系统 prompt 和工具 schema，在不升级分层的前提下扩大有效 ITPM。
• 月度消费上限临近预警：监控月度支出与分层上限的距离；$500/$1,000/$200,000 的硬性暂停会带来可靠性风险——在工作区级别设置低于上限的子限制，避免意外中断。

经常被忽视的 AWS 注意事项

通过 Claude Platform on AWS（Bedrock 路径）访问 Claude 的组织被分配至 Start 分层且不会自动升级。申请更高限制须联系 Anthropic 客户代表。该路径同样不支持工作区级速率限制配置和 fast mode。

如果你通过 AWS 原生架构路由 Claude 流量并期待自动升级分层，请务必向客户代表确认。

现在需要检查什么

1. 在 Claude Console 的限制页面中查看当前分层，确认配额对称是否影响你的回退逻辑。
2. 在用量页面审计缓存命中率。若共享系统 prompt 工作负载命中率低于 50%，说明你的有效 ITPM 尚未充分利用。
3. 在工作区级别设置低于分层上限的消费子限制，避免达到上限时服务硬性暂停。
4. 检查回退链逻辑：若使用模型多样化是为了分散配额压力，现在应将决策依据更新为成本和质量，而非配额桶大小。
5. AWS 用户：确认分层分配，并评估是否需要通过客户代表申请限制提升。

6 月 26 日的变更是结构性简化——更少的分层、对称的限制、清晰的消费上限。对路由团队而言，模型选择现在应由成本和能力驱动，而不是哪款模型的配额桶更大。