Claude API 限额上调：Start、Build、Scale 新分层该怎么看

Mon, 29 Jun 2026 05:04:40 +0800

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 也更好懂了。对开发者来说，真正的动作不是“放心猛冲”，而是趁着限额变宽，把自己的调用链、监控和重试策略整理清楚。这样限额上调带来的余量，才会变成稳定性，而不是更快撞到下一堵墙。

速率限制 on KnightLi的博客