限制分为两种类型:
API 在组织级别强制执行服务配置的限制,但您也可以为组织的工作区设置用户可配置的限制。
Start、Build 和 Scale 层级各自带有月度支出上限,即您的组织每个日历月在 API 上可支出的最高金额。一旦达到您所在层级的支出上限,API 使用将暂停至下个月,除非您申请更高的限制。您可以在账单页面查看您组织的月度支出上限并设置自己的限制。
| 使用层级 | 月度支出上限 |
|---|---|
| Start | $500 美元 |
| Build | $1,000 美元 |
| Scale | $200,000 美元 |
Custom 层级的组织没有月度支出上限;限制由其客户团队协商确定。
您还可以设置低于所在层级上限的自定义支出限制以控制成本:
导航至账单页面
在 Claude Console 中前往设置 > 账单。
打开支出限制编辑器
在支出限制部分,点击调整限制(如果当前未设置限制,则点击设置限制)。
调整您的支出限制
输入新值。您的支出限制不能超过当前层级的上限。
Messages API 的速率限制针对每个模型类别以每分钟请求数(RPM)、每分钟输入令牌数(ITPM)和每分钟输出令牌数(OTPM)来衡量。
如果您超出任何速率限制,将收到 429 错误,其中描述了超出的是哪个速率限制,并附带 retry-after 标头指示需要等待多长时间。
许多 API 提供商使用统一的"每分钟令牌数"(TPM)限制,该限制可能包含所有令牌,无论是缓存的还是未缓存的、输入的还是输出的。对于大多数 Claude 模型,只有未缓存的输入令牌才会计入您的 ITPM 速率限制。 这是一个关键优势,使得速率限制实际上比初看起来更高。
ITPM 速率限制在每个请求开始时进行估算,并在请求过程中根据实际使用的输入令牌数进行调整。
以下是计入 ITPM 的内容:
input_tokens(最后一个缓存断点之后的令牌)✓ 计入 ITPMcache_creation_input_tokens(正在写入缓存的令牌)✓ 计入 ITPMcache_read_input_tokens(从缓存读取的令牌)✗ 对于大多数模型不计入 ITPM示例: 在 2,000,000 ITPM 限制和 80% 缓存命中率的情况下,您每分钟实际上可以处理 10,000,000 个总输入令牌(200 万未缓存 + 800 万缓存),因为缓存令牌不计入您的速率限制。
OTPM 速率限制在生成输出令牌时实时评估,仅计算实际生成的令牌。max_tokens 参数不会纳入 OTPM 速率限制的计算,因此设置较高的 max_tokens 值不会对速率限制产生不利影响。
速率限制针对每个模型单独应用;因此您可以同时使用不同的模型,直至各自的限制。 您可以在 Claude Console 的速率限制页面查看当前的速率限制和行为,或使用速率限制 API 以编程方式读取已配置的限制。
| 模型 | 每分钟最大请求数(RPM) | 每分钟最大输入令牌数(ITPM) | 每分钟最大输出令牌数(OTPM) |
|---|---|---|---|
| Claude Fable 5 | 1,000 | 500,000 | 100,000 |
| Claude Opus 5 | 1,000 | 2,000,000 | 400,000 |
| Claude Opus 4.x* | 1,000 | 2,000,000 | 400,000 |
| Claude Sonnet 5 | 1,000 | 2,000,000 | 400,000 |
| Claude Sonnet 4.x** | 1,000 | 2,000,000 | 400,000 |
| Claude Haiku 4.5 | 1,000 | 2,000,000 | 400,000 |
| Claude Haiku 3.5(已停用,Bedrock 和 Google Cloud 除外) | 1,000 | 100,000† | 20,000 |
* Opus 速率限制是一个总限制,适用于 Claude Opus 4.8、Opus 4.7、Opus 4.6 和 Opus 4.5 的合并流量。Claude Opus 5 有单独的速率限制,不属于此合并配额。
** Sonnet 4.x 速率限制是一个总限制,适用于 Sonnet 4.6 和 Sonnet 4.5 的合并流量。Claude Sonnet 5 有单独的速率限制,不属于此合并配额。
† 该限制将 cache_read_input_tokens 计入 ITPM 使用量。
Message Batches API 有自己的一套速率限制,在所有模型之间共享。这些限制包括对所有 API 端点的每分钟请求数(RPM)限制,以及对可同时处于处理队列中的批处理请求数量的限制。此处的"批处理请求"是指 Message Batch 的一部分。您可以创建一个包含数千个批处理请求的 Message Batch,每个请求都会计入此限制。当批处理请求尚未被模型成功处理时,即被视为处于处理队列中。
| 每分钟最大请求数(RPM) | 处理队列中的最大批处理请求数 | 每批次的最大批处理请求数 |
|---|---|---|
| 1,000 | 200,000 | 100,000 |
Claude 托管智能体端点按组织进行速率限制。这些限制与上述 Messages API 速率限制相互独立。
| 操作 | 限制 |
|---|---|
| 创建端点(例如智能体、会话和环境) | 每分钟 300 个请求 |
| 读取端点(例如检索、列出和流式传输) | 每分钟 1,200 个请求 |
在 Claude Opus 5 或 Opus 4.8 上使用带有 speed: "fast" 的快速模式(研究预览版)时,将应用专用的速率限制,这些限制与标准 Opus 速率限制相互独立。当超出快速模式速率限制时,API 会返回带有 retry-after 标头的 429 错误。快速模式在 Claude Opus 4.7 上不可用(请求会返回错误),在 Claude Opus 4.6 上也不可用(对 claude-opus-4-6 使用 speed: "fast" 的请求将以标准速度运行)。请参阅快速模式。
响应中包含 anthropic-fast-* 标头,用于指示您的快速模式速率限制状态。有关这些标头的详细信息,请参阅快速模式速率限制。
您可以在 Claude Console 的使用情况页面监控您的速率限制使用情况。
除了提供令牌和请求图表外,使用情况页面还提供两个独立的速率限制图表。使用这些图表可以查看您还有多少增长空间、识别何时可能达到峰值使用、了解应申请哪些速率限制,以及学习如何提高缓存率。这些图表针对给定的速率限制(例如按模型)可视化了多项指标:
要申请更高的速率限制或更高的月度支出上限,请在速率限制页面使用申请提高速率限制。
有关工作区的更多信息,请参阅工作区。
为了保护组织中的工作区免受潜在的过度使用,您可以为每个工作区设置自定义的支出和速率限制。
示例:如果您的组织限制为每分钟 40,000 个输入令牌和每分钟 8,000 个输出令牌,您可以将一个工作区限制为每分钟 30,000 个输入令牌。这可以保护其他工作区免受潜在的过度使用,并确保资源在整个组织中更公平地分配。剩余的每分钟未使用令牌(如果该工作区未用满限制,则会更多)可供其他工作区使用。
注意:
要以编程方式读取当前的组织和工作区速率限制,请使用速率限制 API。
API 响应包含标头,显示所执行的速率限制、当前使用情况以及限制何时重置。
返回的标头如下:
| 标头 | 描述 |
|---|---|
retry-after | 您可以重试请求之前需要等待的秒数。更早的重试将会失败。 |
anthropic-ratelimit-requests-limit | 任何速率限制周期内允许的最大请求数。 |
anthropic-ratelimit-requests-remaining | 在触发速率限制之前剩余的请求数。 |
anthropic-ratelimit-requests-reset | 请求速率限制将完全补充的时间,以 RFC 3339 格式提供。 |
anthropic-ratelimit-tokens-limit | 任何速率限制周期内允许的最大令牌数。 |
anthropic-ratelimit-tokens-remaining | 在触发速率限制之前剩余的令牌数(四舍五入到最接近的千位)。 |
anthropic-ratelimit-tokens-reset | 令牌速率限制将完全补充的时间,以 RFC 3339 格式提供。 |
anthropic-ratelimit-input-tokens-limit | 任何速率限制周期内允许的最大输入令牌数。 |
anthropic-ratelimit-input-tokens-remaining | 在触发速率限制之前剩余的输入令牌数(四舍五入到最接近的千位)。 |
anthropic-ratelimit-input-tokens-reset | 输入令牌速率限制将完全补充的时间,以 RFC 3339 格式提供。 |
anthropic-ratelimit-output-tokens-limit | 任何速率限制周期内允许的最大输出令牌数。 |
anthropic-ratelimit-output-tokens-remaining | 在触发速率限制之前剩余的输出令牌数(四舍五入到最接近的千位)。 |
anthropic-ratelimit-output-tokens-reset | 输出令牌速率限制将完全补充的时间,以 RFC 3339 格式提供。 |
anthropic-priority-input-tokens-limit | 任何速率限制周期内允许的最大 Priority Tier 输入令牌数。(仅限 Priority Tier) |
anthropic-priority-input-tokens-remaining | 在触发速率限制之前剩余的 Priority Tier 输入令牌数(四舍五入到最接近的千位)。(仅限 Priority Tier) |
anthropic-priority-input-tokens-reset | Priority Tier 输入令牌速率限制将完全补充的时间,以 RFC 3339 格式提供。(仅限 Priority Tier) |
anthropic-priority-output-tokens-limit | 任何速率限制周期内允许的最大 Priority Tier 输出令牌数。(仅限 Priority Tier) |
anthropic-priority-output-tokens-remaining | 在触发速率限制之前剩余的 Priority Tier 输出令牌数(四舍五入到最接近的千位)。(仅限 Priority Tier) |
anthropic-priority-output-tokens-reset | Priority Tier 输出令牌速率限制将完全补充的时间,以 RFC 3339 格式提供。(仅限 Priority Tier) |
anthropic-ratelimit-tokens-* 标头显示当前生效的最严格限制的值。例如,如果您已超出工作区的每分钟令牌限制,标头将包含工作区每分钟令牌速率限制的值。如果工作区限制不适用,标头将返回剩余的总令牌数,其中总数是输入和输出令牌之和。这种方法确保您能够了解当前 API 使用中最相关的约束。
Was this page helpful?