AI API 速率限制对比 2026：OpenAI、Claude、Gemini、DeepSeek RPM 与 TPM

选 AI API 的时候，大多数人第一反应是看价格。但实际跑起来之后你会发现， 速率限制才是真正卡脖子的那个因素 。

这篇文章把 2026 年 8 月主流 AI API 厂商的速率限制体系拆开讲清楚，帮你在做架构决策之前就知道瓶颈在哪里。

OpenAI — 账户分层，但限额因模型与项目而异

OpenAI 的 API 限额随累计付费金额、首次成功付款后的时间、模型和端点变化。GPT-5.6 Sol、Terra、Luna 没有一张可以安全复制到所有账号的通用 RPM/TPM 表。生产容量必须查看当前模型页、账户 Limits 页和响应中的 x-ratelimit-* 头。

账户层级的升级门槛仍可用于判断资格：

API 限流也不能和 ChatGPT/Codex 订阅额度混为一谈。个人 Codex 套餐目前仍写有滚动 5 小时窗口，并说明可能存在额外周限制；Plus/Pro 用完包含额度后可以购买 credits。Enterprise/Edu 正在把管理员原有的 每周 credit 控制 迁移为月度 Usage limits，但这不等于所有个人周限制已经统一取消。

详细区分见 GPT-5.6 Codex 限制与多 Agent 指南 。

Anthropic Claude — RPM、输入 TPM、输出 TPM 分开计算

Anthropic 的 Messages API 不适合再写成单一 TPM。官方文档按 RPM、input tokens per minute (ITPM)、output tokens per minute (OTPM) 分开计数。

Claude Opus 4.6 / Sonnet 4.6 当前速率限制：

Anthropic 官方文档把 Opus 4.x 和 Sonnet 4.x 按模型家族共享速率限制，而不是给每个小版本单独列限额。多数当前 Claude 模型的缓存读取 token 不计入 ITPM，因此缓存命中高的工作负载，实际输入吞吐会比表面数字更高。

Google Gemini — 基于层级的弹性吞吐

Google 的速率限制体系已经演变为复杂的项目配额制。官方文档明确说：实际限额取决于用量层级、账号状态等因素，应在 AI Studio 查看；文档中的指定限额也不保证一定可用。因此，Gemini 3.x 不适合在文章里写成稳定的通用 RPM/TPM 表。

Gemini 2.5 系列（用于规划器的保守基线）：

Google 体系的关键点：

• 免费层和付费层都要看项目配额 。不要把网上流传的 Gemini RPM 表直接写进生产容量规划。
• 开启结算后通常会提升配额 ，但 Google 官方仍要求到 AI Studio 查看有效速率限制。
• 上下文窗口影响 ：处理极长上下文（1M+ token）的单次请求可能会有额外的延迟，且不完全受 TPM 桶的简单加减法控制。

xAI (Grok) — 消费层级与模型池

xAI 公开 T0 到 T4 的消费层级，成功付款门槛依次是 $0、$50、$250、$1,000、$5,000。当前官方文档使用每秒请求数（RPS），不再提供旧文章中的通用免费 RPM 承诺。

当前 T0 与 T4 示例：

这些是组织级模型池，可能由同一家族中的多个模型共享。实际部署必须查看 xAI Console，不要继续按旧的 $25 注册赠金估算。

DeepSeek — 动态并发，无付费层级

DeepSeek V4 不适合写成固定 RPM/TPM 表。英文官方文档说 API 会根据服务器负载动态限制并发，达到限制时返回 429；中文官方文档则强调不限制用户并发量，但高流量压力下请求可能排队，并通过空行或 SSE keep-alive 保持连接。生产规划应按“无固定公开表 + 可能排队/429”处理。

DeepSeek V4 当前行为：

六大厂商速率限制总表（2026 年 8 月）

这张表不能直接当排行榜：xAI 公布组织池，Anthropic 分开计算输入和输出 TPM，Gemini 以项目为准，DeepSeek 动态调度，OpenAI GPT-5.6 则要读取具体账户和模型限额。

xAI Grok：按 T0-T4 升级

Grok 4.20 Multi-Agent 使用独立且更低的池，T0 是 9 RPS/2.5M TPM，T4 是 56 RPS/21M TPM。多 Agent 架构不能直接套用 Grok 4.5 的单模型池。

DeepSeek：无分层，动态并发

DeepSeek 的策略最简单——没有公开的付费层级，也没有“消费多少解锁多少 TPM”的固定阶梯。真正要关注的是排队时间、超时、429 和 503，而不是表格里的固定数值。

不过，DeepSeek 有一个其他厂商不太有的问题： 高峰期拥堵 。国内开发者集中使用的时段（工作日白天），实际响应延迟可能显著增加。建议所有生产调用都设置超时、队列和备用厂商。

Mistral：简单明了

Mistral 的速率限制在主流厂商中偏宽松，300 RPM 的默认值高于 Anthropic Tier 1（50），但低于 OpenAI Tier 2+（5000+）和 Gemini 付费（2000）。DeepSeek 现在应单独按动态并发评估，而不是拿固定 RPM 表硬比。

按场景对比：你的项目该选谁

不同阶段的项目对吞吐量的要求完全不同。下面按三个典型场景给出推荐。

场景 1：原型开发（零成本 / 免费额度）

你在做 MVP、写 Side Project、或者评估不同模型的效果。需求：不花钱或少花钱，速率限制够测试就行。

结论：原型阶段优先看 Gemini 和 DeepSeek 。Gemini 的有效配额要在 AI Studio 查看；DeepSeek 没有固定公开 RPM/TPM 表，但价格很低，适合配合队列和超时策略测试。OpenAI 和 xAI 都应先检查当前项目的实际资格与账单状态。

场景 2：创业产品（中等用量）

日均 5-10 万请求，需要稳定的速率限制和合理的成本。

结论：不要只按公开文章选厂商。 OpenAI 与 Gemini 都要读取项目实际配额，xAI 要读取组织 Tier，DeepSeek 则按动态并发做队列和备用路由。

如果你一定要用 Claude——比如因为它的代码能力确实强——Anthropic 的 OTPM 和加速限制是实际问题。长输出场景下，90K-160K OTPM 可能先成为瓶颈；缓存命中高的长输入场景则会好很多。

场景 3：企业级（高吞吐量）

日均百万级请求，需要最高的速率限制和 SLA 保障。

结论：企业级要以合同和有效项目配额为准。 xAI 公布 Grok 4.5 T4 为 100M TPM；OpenAI 和 Gemini 则需要在具体项目或企业合同中确认，不能继续沿用 GPT-5 时代的固定表。

Anthropic 在企业场景下的最大软肋通常是输出速率限制——40 万 OTPM 对于高吞吐长输出应用来说仍然偏紧。当然你可以通过缓存、模型拆分和企业提额来缓解，但这增加了架构复杂度。

DeepSeek 没有公开固定 RPM/TPM 阶梯，动态并发也不适合承诺强 SLA，但作为辅助路由的一环（尤其是处理低优先级、重复上下文、低成本任务）很有价值。

速率限制如何影响架构设计

很多开发者在写原型的时候不会想到速率限制的问题，但一旦进入生产环境，它会从三个层面影响你的系统架构。

1. 请求队列是必须的

一旦你的用户数超过几十个并发，裸调 API 必然会遇到 429 (Rate Limit Exceeded) 错误。你需要在应用层建立请求队列，按照速率限制的窗口做流控。

这不是一个 nice-to-have，而是一个架构必需品。没有队列管理的生产应用在流量波动时会出现大量请求失败，直接影响用户体验。

2. 多厂商 Fallback 策略

单一厂商的速率限制是硬约束。如果你的主力模型触发了限流，请求要有备用出路。常见的做法：

• 主力模型 → GPT-5.6 Terra 或 Claude Sonnet 4.x
• 一级 Fallback → GPT-5.6 Luna（先确认是否为独立模型池）
• 二级 Fallback → Gemini 2.5 Flash（最宽的限额）
• 三级 Fallback → DeepSeek V4 Flash（最便宜的兜底）

多厂商 Fallback 的好处不只是应对限流——某个厂商出现服务故障时，你的应用也不会完全瘫痪。

3. 预估 Token 消耗，而不是事后统计

在发送请求之前就计算好这个请求会消耗多少 token，这样你可以在应用层做精确的限流，而不是等到 API 返回 429 错误才知道超了。

用 AI Token 计算器 测量你的典型 prompt，摸清不同场景下的 token 消耗范围。这个数字直接决定了你在给定 TPM 限制下每分钟能处理多少请求。

比如：Anthropic Tier 2 的 Claude Sonnet 限额是 450K ITPM 和 90K OTPM。如果每次平均输入 3,000、输出 1,000 token，输出池大约只能支持每分钟 90 次请求，远早于 1,000 RPM。

5 个提升吞吐量的实战技巧

技巧 1：Batch API 绕过实时速率限制

OpenAI 和 Anthropic 的 Batch API 不受常规速率限制的约束（或有独立的、更宽裕的限额）。如果你的任务不需要实时返回结果——数据标注、批量翻译、内容审核——走 Batch API 既能绕过 RPM/TPM 瓶颈，又能拿到 50% 的价格折扣。

from
 openai 
import
 OpenAI


import
 json




client 
=
 OpenAI()




# 准备批量请求


batch_requests 
=
 []


for
 i, text 
in
 enumerate
(texts_to_process):


 batch_requests.append({


 "custom_id"
: 
f
"task-
{
i
}
"
,


 "method"
: 
"POST"
,


 "url"
: 
"/v1/chat/completions"
,


 "body"
: {


 "model"
: 
"gpt-5"
,


 "messages"
: [


 {
"role"
: 
"system"
, 
"content"
: 
"摘要以下文本，限 100 字内。"
},


 {
"role"
: 
"user"
, 
"content"
: text}


 ],


 "max_tokens"
: 
300


 }


 })




# 写入 JSONL 并提交


with
 open
(
"batch_input.jsonl"
, 
"w"
) 
as
 f:


 for
 req 
in
 batch_requests:


 f.write(json.dumps(req) 
+
 "
\n
"
)




batch_file 
=
 client.files.create(


 file
=
open
(
"batch_input.jsonl"
, 
"rb"
),


 purpose
=
"batch"


)




batch_job 
=
 client.batches.create(


 input_file_id
=
batch_file.id,


 endpoint
=
"/v1/chat/completions"
,


 completion_window
=
"24h"


)




print
(
f
"批量任务 ID: 
{
batch_job.id
}
"
)


# 24 小时内完成，不受常规 RPM/TPM 限制

技巧 2：指数退避重试

遇到 429 错误后直接重试只会让情况更糟。正确的做法是指数退避（Exponential Backoff）：每次重试的等待时间翻倍，加上随机抖动避免多个客户端同时重试。

import
 time


import
 random


from
 openai 
import
 OpenAI, RateLimitError




client 
=
 OpenAI()




def
 call_with_backoff
(messages, model
=
"gpt-5"
, max_retries
=
5
):


 """带指数退避的 API 调用"""


 for
 attempt 
in
 range
(max_retries):


 try
:


 response 
=
 client.chat.completions.create(


 model
=
model,


 messages
=
messages,


 max_tokens
=
1000


 )


 return
 response


 except
 RateLimitError 
as
 e:


 if
 attempt 
==
 max_retries 
-
 1
:


 raise
 # 最后一次重试仍失败，抛出异常




 # 指数退避 + 随机抖动


 wait_time 
=
 (
2
 **
 attempt) 
+
 random.uniform(
0
, 
1
)


 print
(
f
"触发速率限制，等待 
{
wait_time
:.1f
}
s 后重试 (
{
attempt 
+
 1}
/
{
max_retries
}
)"
)


 time.sleep(wait_time)




 return
 None

技巧 3：请求前预计算 Token，做精确限流

不要等 API 返回 429 才知道超限了。在发送之前就用 tokenizer 计算好每个请求的 token 数，在应用层维护一个 TPM 计数器。

import
 tiktoken


import
 time


from
 collections 
import
 deque




class
 RateLimiter
:


 """基于 token 的应用层限流器"""




 def
 __init__
(self, tpm_limit: 
int
, rpm_limit: 
int
):


 self
.tpm_limit 
=
 tpm_limit


 self
.rpm_limit 
=
 rpm_limit


 self
.token_log 
=
 deque() 
# (timestamp, token_count)


 self
.request_log 
=
 deque() 
# timestamp


 self
.encoder 
=
 tiktoken.encoding_for_model(
"gpt-4o"
)




 def
 estimate_tokens
(self, messages: 
list
) -> 
int
:


 """估算消息的 token 数"""


 total 
=
 0


 for
 msg 
in
 messages:


 total 
+=
 len
(
self
.encoder.encode(msg[
"content"
])) 
+
 4


 return
 total




 def
 can_send
(self, estimated_tokens: 
int
) -> 
bool
:


 """检查是否可以发送请求"""


 now 
=
 time.time()


 cutoff 
=
 now 
-
 60
 # 60 秒窗口




 # 清理过期记录


 while
 self
.token_log 
and
 self
.token_log[
0
][
0
] 
<
 cutoff:


 self
.token_log.popleft()


 while
 self
.request_log 
and
 self
.request_log[
0
] 
<
 cutoff:


 self
.request_log.popleft()




 current_tpm 
=
 sum
(t[
1
] 
for
 t 
in
 self
.token_log)


 current_rpm 
=
 len
(
self
.request_log)




 return
 (current_tpm 
+
 estimated_tokens 
<=
 self
.tpm_limit


 and
 current_rpm 
+
 1
 <=
 self
.rpm_limit)




 def
 record
(self, token_count: 
int
):


 """记录已发送的请求"""


 now 
=
 time.time()


 self
.token_log.append((now, token_count))


 self
.request_log.append(now)




# 使用示例：Anthropic Tier 2 的限制


limiter 
=
 RateLimiter(
tpm_limit
=
80_000
, 
rpm_limit
=
1_000
)

这种方式的好处是你可以在请求排队阶段就知道该等多久，而不是发出去之后才被拒绝。用 AI Token 计算器 测量你的典型 prompt 长度，确定 estimated_tokens 的合理估值。

技巧 4：多 API Key 轮换

如果你在同一个厂商内需要更高的吞吐量，可以注册多个账号、获取多个 API Key，然后在应用层做轮换。每个 Key 有独立的速率限制配额，N 个 Key 理论上能获得 N 倍的吞吐量。

import
 itertools




class
 KeyRotator
:


 """API Key 轮换器"""




 def
 __init__
(self, api_keys: list[
str
]):


 self
.keys 
=
 api_keys


 self
.cycle 
=
 itertools.cycle(api_keys)




 def
 get_next_key
(self) -> 
str
:


 return
 next
(
self
.cycle)




 def
 get_client
(self):


 key 
=
 self
.get_next_key()


 return
 OpenAI(
api_key
=
key)




# 3 个 Key = 3 倍 RPM/TPM


rotator 
=
 KeyRotator([


 "sk-key-1-..."
,


 "sk-key-2-..."
,


 "sk-key-3-..."
,


])




# 每个请求用不同的 Key


client 
=
 rotator.get_client()


response 
=
 client.chat.completions.create(
...
)

注意： 部分厂商（如 OpenAI）可能会按组织维度聚合速率限制，而不是按 Key。确认你的多个 Key 是否来自不同组织。另外，这种做法需要遵守厂商的 ToS，不要滥用。

技巧 5：多厂商并发 + 智能路由

最强大的吞吐量策略：不把鸡蛋放在一个篮子里。将请求分发到多个厂商，每个厂商有独立的速率限制池。

import
 asyncio


from
 openai 
import
 AsyncOpenAI




# 不同厂商的 client


providers 
=
 {


 "anthropic"
: AsyncOpenAI(


 api_key
=
"sk-ant-..."
,


 base_url
=
"https://api.anthropic.com/v1/"


 ),


 "openai_codex"
: AsyncOpenAI(
api_key
=
"sk-..."
),


 "openai_frontier"
: AsyncOpenAI(
api_key
=
"sk-..."
),


 "gemini_flash"
: AsyncOpenAI(


 api_key
=
"your-google-key"
,


 base_url
=
"https://generativelanguage.googleapis.com/v1beta/openai/"


 ),


 "deepseek"
: AsyncOpenAI(


 api_key
=
"your-ds-key"
,


 base_url
=
"https://api.deepseek.com"


 ),


}




# 每个厂商的模型和权重


routing_config 
=
 {


 "deepseek"
: {
"model"
: 
"deepseek-v4-flash"
, 
"weight"
: 
45
},


 "gemini_flash"
: {
"model"
: 
"gemini-2.5-flash"
, 
"weight"
: 
25
},


 "openai_codex"
: {
"model"
: 
"gpt-5.2-codex"
, 
"weight"
: 
15
},


 "openai_frontier"
: {
"model"
: 
"gpt-5.5"
, 
"weight"
: 
10
},


 "anthropic"
: {
"model"
: 
"claude-sonnet-4-6"
, 
"weight"
: 
5
},


}




async
 def
 distributed_request
(messages: 
list
) -> 
str
:


 """按权重分发请求到不同厂商"""


 import
 random


 total 
=
 sum
(c[
"weight"
] 
for
 c 
in
 routing_config.values())


 roll 
=
 random.randint(
1
, total)




 cumulative 
=
 0


 for
 provider, config 
in
 routing_config.items():


 cumulative 
+=
 config[
"weight"
]


 if
 roll 
<=
 cumulative:


 client 
=
 providers[provider]


 response 
=
 await
 client.chat.completions.create(


 model
=
config[
"model"
],


 messages
=
messages,


 )


 return
 response.choices[
0
].message.content




 # Fallback


 return
 await
 providers[
"deepseek"
].chat.completions.create(


 model
=
"deepseek-v4-flash"
, 
messages
=
messages


 )

这种架构下，你的吞吐量不再依赖单一厂商。OpenAI/Gemini 读取项目的实时配额，DeepSeek V4 Flash 承接低成本、缓存命中率高的重复上下文流量；GPT-5.6 Sol 和 Claude 只处理少量高难度升级任务。

错误处理：429 之外的速率限制陷阱

速率限制的错误不只是 HTTP 429。实际生产中你会遇到几种情况：

标准 429 Too Many Requests

# 所有厂商都返回 429 + Retry-After header


# 正确做法：读取 Retry-After 并等待




import
 requests




try
:


 response 
=
 requests.post(api_url, 
json
=
payload, 
headers
=
headers)


 response.raise_for_status()


except
 requests.exceptions.HTTPError 
as
 e:


 if
 e.response.status_code 
==
 429
:


 retry_after 
=
 int
(e.response.headers.get(
"Retry-After"
, 
60
))


 print
(
f
"被限流，
{
retry_after
}
秒后重试"
)


 time.sleep(retry_after)


 elif
 e.response.status_code 
==
 529
:


 # Anthropic 特有：服务器过载


 print
(
"Anthropic 服务过载，建议切换到备用厂商"
)


 else
:


 raise

Anthropic 529 Overloaded

Anthropic 有一个特殊的 529 状态码，表示服务器过载而不是你的速率限制触发。这通常发生在 Claude 的使用高峰期。遇到 529 时，重试可能没用——因为问题不在你这边，而是服务器端的负载压力。建议直接切换到备用厂商。

DeepSeek 的隐性限流

DeepSeek 在高峰期可能不会返回 429，而是显著增加响应延迟（从正常的 1-2 秒增加到 10-30 秒）。你的代码不会报错，但用户体验会急剧下降。建议设置超时阈值：

import
 httpx




async
 def
 call_deepseek_with_timeout
(messages, timeout_seconds
=
10
):


 """带超时检测的 DeepSeek 调用"""


 client 
=
 AsyncOpenAI(


 api_key
=
"your-ds-key"
,


 base_url
=
"https://api.deepseek.com"
,


 timeout
=
httpx.Timeout(timeout_seconds)


 )




 try
:


 response 
=
 await
 client.chat.completions.create(


 model
=
"deepseek-v4-flash"
,


 messages
=
messages,


 )


 return
 response.choices[
0
].message.content


 except
 httpx.TimeoutException:


 print
(
"DeepSeek 响应超时，切换到备用厂商"
)


 # fallback 到 Gemini Flash 或 OpenAI


 return
 await
 call_fallback(messages)

完整的错误处理框架

import
 time


import
 random


from
 enum 
import
 Enum




class
 ErrorAction
(
Enum
):


 RETRY
 =
 "retry"


 FALLBACK
 =
 "fallback"


 ABORT
 =
 "abort"




def
 classify_error
(status_code: 
int
, provider: 
str
) -> ErrorAction:


 """根据错误码和厂商决定处理策略"""


 if
 status_code 
==
 429
:


 return
 ErrorAction.
RETRY


 elif
 status_code 
==
 529
 and
 provider 
==
 "anthropic"
:


 return
 ErrorAction.
FALLBACK
 # 服务过载，别等了


 elif
 status_code 
==
 500
:


 return
 ErrorAction.
RETRY
 # 服务器内部错误，值得重试


 elif
 status_code 
==
 503
:


 return
 ErrorAction.
FALLBACK
 # 服务不可用，切厂商


 elif
 status_code 
in
 (
400
, 
401
, 
403
):


 return
 ErrorAction.
ABORT
 # 客户端错误，不要重试


 else
:


 return
 ErrorAction.
RETRY




def
 robust_api_call
(messages, providers_priority, max_retries
=
3
):


 """带多厂商 Fallback 的健壮 API 调用"""


 for
 provider 
in
 providers_priority:


 for
 attempt 
in
 range
(max_retries):


 try
:


 return
 call_provider(provider, messages)


 except
 APIError 
as
 e:


 action 
=
 classify_error(e.status_code, provider)




 if
 action 
==
 ErrorAction.
RETRY
:


 wait 
=
 (
2
 **
 attempt) 
+
 random.uniform(
0
, 
1
)


 time.sleep(wait)


 elif
 action 
==
 ErrorAction.
FALLBACK
:


 break
 # 跳到下一个厂商


 elif
 action 
==
 ErrorAction.
ABORT
:


 raise
 # 客户端错误，直接报错




 raise
 Exception
(
"所有厂商都失败了"
)

按日请求量选厂商推荐

最后做一个总结。根据你的日均请求量，给出最直接的推荐：

每天 100 请求以下（学习 / 评估）

这个量级不需要考虑速率限制，重点是不花钱。

每天 1,000-10,000 请求（原型 / 早期产品）

这个阶段要注意输入和输出 token 瓶颈。如果你的 prompt 平均 3000 输入 token，Anthropic Tier 1 的 30K ITPM 大约只够每分钟 10 个未缓存请求；如果输出很长，8K OTPM 会更早成为瓶颈。

每天 10,000-100,000 请求（增长期产品）

这个量级强烈建议做多厂商路由。单一厂商的限额可能在流量高峰期不够用。用 AI 模型价格计算器 模拟不同路由比例下的月费。

每天 100,000+ 请求（规模化产品）

这个量级下，你需要和厂商直接谈企业合同来获取更高的限额。同时，多厂商架构从”锦上添花”变成了”架构必需”——任何单一厂商的故障都不能打瘫你的服务。

总结

速率限制是 AI API 选型中最容易被忽略但影响最大的因素之一。总结几个核心要点：

1. 各厂商口径不同。 xAI 公布组织级 RPS/TPM 池；Anthropic Tier 4 是 200 万 ITPM / 40 万 OTPM；OpenAI 和 Gemini 必须查看当前项目限额。选型时不能只看模型能力和价格。

2. TPM 通常比 RPM 更关键。 现在的 prompt 动辄几千 token，TPM 往往先触及上限。在架构设计阶段就要测量你的典型 prompt 长度，算清楚给定 TPM 下你实际能承载多少并发。

3. Tier 只决定资格，不保证一张通用数字表。 OpenAI、Anthropic 和 xAI 升级层级后通常会提高可用容量，但生产系统必须读取当前账户的有效限额。

4. 多厂商架构是高可用的基础。 不管你的主力模型是谁，都需要至少一个备用厂商。速率限制触发、服务故障、延迟波动——这些都需要 Fallback 策略。

5. 提前限流好过事后重试。 在应用层维护 TPM/RPM 计数器，在请求发出前就判断是否可以发送，比等到 429 返回再重试效率高得多。

想精确计算你的 prompt 会消耗多少 token？用 AI Token 计算器 测量。想对比不同模型在你的用量下的月费？用 AI 模型价格计算器 。

相关文章和工具：

• AI API 降本 80%：8 个省钱策略 — Batch API、Prompt Caching、智能路由，含代码示例
• 2026 AI API 价格对比 — 7 大厂商 25+ 模型完整定价表
• AI Token 计算器 — 精确计算 prompt 的 token 数和成本
• AI 模型价格计算器 — 25+ 模型月费在线对比
• OpenAI API 定价指南 2026 — GPT-5.6 Sol/Terra/Luna、缓存与长上下文计费
• Grok API 定价指南 2026 — Grok 4.5、4.3、4.20 与 Build 0.1
• Claude API 价格指南 2026 — Opus/Sonnet/Haiku 对比，Prompt Caching 省 90%
• Google Gemini API 定价指南 2026 — Gemini 2.5 Pro/Flash、免费层和百万上下文
• DeepSeek API 价格指南 — V4 Flash 缓存命中价、V4 Pro 永久降价和 Agent 成本拆解

2026 年 7 月 14 日核对的官方限流来源： OpenAI API 限流指南 、 OpenAI Codex 定价 、 Anthropic 限流 、 Gemini 限流 、 xAI 限流 和 DeepSeek 限流行为 。