Anthropic 在 2026 年 6 月 26 日更新了 Claude Platform release notes：Claude API 的 rate limits 上调，Claude Sonnet 和 Claude Haiku 的限额现在会在各个 usage tier 上对齐 Claude Opus；原来的 usage tiers 也被合并成三个更简单的层级：Start、Build、Scale。
官方说法是：大多数组织会进入更高层级，没有组织会拿到比以前更低的限额，也不需要开发者手动操作。你可以在 Claude Console 里查看自己的 tier 和当前 limits。
发布说明：
https://platform.claude.com/docs/en/release-notes/overview
Rate limits 文档：
https://platform.claude.com/docs/en/api/rate-limits
Rate Limits API 文档：
https://platform.claude.com/docs/en/api/rate-limits-api
这次更新最重要的点
如果你只是日常用 Claude API 写脚本、做小工具，可能一时感觉不到变化。但如果你在跑 Claude Code、AI Agent、批量总结、RAG 问答或后台队列，这次更新值得看一眼。
变化可以拆成三句话：
- Claude API 的整体限额上调了。
- Sonnet 和 Haiku 的限额，在每个 usage tier 上对齐 Opus。
- usage tiers 简化为
Start、Build、Scale。
这意味着什么？过去一些开发者可能会觉得 Opus、Sonnet、Haiku 的限额口径不太一样，做模型切换时要额外检查。现在分层和模型限额更容易理解，对多模型应用、Agent 产品和内部平台会友好一些。
但这不等于可以随便开并发。Claude API 仍然会按请求数、输入 token、输出 token 和流量增长速度限制请求。
为什么这条新闻对开发者有用
很多人接 Claude API，真正卡住的不是“模型会不会回答”，而是上线后突然遇到 429。
典型场景包括：
- 本地脚本一次性丢几百个文件给 Claude 总结。
- Agent 应用同时开很多工具调用和长上下文请求。
- RAG 系统把检索结果、历史对话和系统提示词一起塞进 prompt。
- 后台队列消费太快，几分钟内把 token 打满。
- 失败后自动重试，越重试越拥堵。
这次 Anthropic 上调限额，确实能让一部分任务跑得更顺。但只要你的应用会放大请求，还是要认真处理 rate limit。限额提高是好消息，限流、排队和重试策略仍然不能省。
Start、Build、Scale 怎么理解
新的 usage tiers 变成三个层级：
| 层级 | 更像适合谁 |
|---|---|
Start |
个人开发者、小脚本、早期原型 |
Build |
已经有稳定调用量的应用、团队内部工具 |
Scale |
生产业务、高并发 Agent、批处理和企业级集成 |
具体额度不要照搬文章里的数字，应该以 Claude Console 和官方文档为准。Anthropic 的限额会根据账户、组织、workspace、模型和产品策略变化。
更接地气地说：如果你只是偶尔写脚本，重点是别把并发开太大；如果你在做一个真实产品，重点是把 Claude 当成一个需要容量规划的外部服务，而不是普通函数调用。
还是要看 RPM、ITPM、OTPM
Claude API 的 rate limits 不是只有“每分钟多少次请求”。文档里最常见的是三个指标：
| 指标 | 含义 | 容易踩坑的场景 |
|---|---|---|
RPM |
requests per minute，每分钟请求数 | 小请求太密、并发太高、自动重试太多 |
ITPM |
input tokens per minute，每分钟输入 token | prompt 太长、上下文太大、RAG 结果塞太多 |
OTPM |
output tokens per minute，每分钟输出 token | max_tokens 给太大、批量生成长文或代码 |
很多 429 不是因为请求次数多，而是 token 多。比如每分钟只发 10 个请求，但每个请求都带几十万 token 的上下文，就可能先撞到 ITPM。反过来，如果 prompt 很短，却让模型批量输出长报告，就可能先撞到 OTPM。
所以排查时不要只看接口调用次数。至少要记录模型名、workspace、输入 token、输出 token、响应状态和重试次数。
Agent 和批处理更容易吃到红利
这次限额上调，对普通聊天请求当然有帮助，但更明显的受益者应该是 Agent 和批处理任务。
因为 Agent 的一次“用户请求”背后，可能不是一次 Claude API 调用，而是一串调用：
- 读文件。
- 总结上下文。
- 调工具。
- 看工具结果。
- 再规划下一步。
- 最后输出结果。
如果多个用户同时使用，或者后台还在跑批量任务，token 很快就会上去。限额上调后，这类任务的余量会更大，模型切换也更顺。但生产环境仍然建议分通道：在线请求走低延迟通道，批处理走队列，长任务单独限并发。
429 不要只怪模型
遇到 429，先别急着换模型，也别直接把重试次数拉满。更实用的排查顺序是：
- 看错误信息，确认是 rate limit、quota 还是其他限制。
- 看响应头里的 limit、remaining、reset 等字段。
- 统计最近一分钟的
RPM、ITPM、OTPM。 - 看是否有前端、后端、队列、SDK 同时重试。
- 看后台任务是否和用户请求共用同一个组织或 workspace。
- 看最近是否突然放量，触发了 acceleration limits。
Anthropic 文档里也提到，短时间流量突然上升可能触发 acceleration limits。也就是说，即使平均请求量看起来没那么夸张，只要增长太猛，也可能被限。
上线新功能时，最好逐步放量。比如先给 5% 用户开，再看 429、延迟、token 消耗和成本曲线，而不是一次性把所有流量打到 Claude API。
Rate Limits API 可以接到监控里
Anthropic 还提供 Rate Limits API，用来查询组织和 workspace 的限额配置。这个接口适合接到内部监控、管理后台或运维脚本里。
它的用处主要有几个：
- 部署前确认当前 workspace 的限额。
- 给不同业务线展示可用容量。
- 解释为什么测试环境能跑、生产环境会 429。
- 根据当前限制调整队列并发。
- 做容量告警，而不是等用户报错。
但它不应该替代应用自己的限流。业务代码里仍然要有队列、并发上限、指数退避和最大重试次数。
现在应该怎么改自己的代码
如果你已经在用 Claude API，可以先做几件很实际的事：
- 去 Claude Console 看自己的 tier 是否已经变成
Start、Build或Scale。 - 确认常用模型的当前 rate limits，不要靠旧截图或旧文档记忆。
- 把并发数、每分钟请求数和最大输出 token 做成配置项。
- 给批处理任务加队列，不要直接
for循环猛打 API。 - 对
429做指数退避，并限制最大重试次数。 - 记录输入 token、输出 token、模型名、workspace 和请求耗时。
- 如果有长上下文重复使用，评估 prompt caching，但别把缓存当成完全不占限额。
这次更新是一个明确利好：Claude API 的容量更宽了，usage tier 也更好懂了。对开发者来说，真正的动作不是“放心猛冲”，而是趁着限额变宽，把自己的调用链、监控和重试策略整理清楚。这样限额上调带来的余量，才会变成稳定性，而不是更快撞到下一堵墙。