速率限制与配额
有两类限制让 API 对所有人都保持快速：
- 密钥的速率限制：每秒可以发送多少个请求，并允许短时高峰的突发。
- 组织的配额：组织的所有密钥加起来，每分钟、每天和每月可以发送多少个请求。
两者都取决于组织的套餐。每个响应都会告诉您当前的使用情况，因此行为良好的客户端无需猜测。
密钥的速率限制
每个密钥有一个稳定速率和一个突发量。突发量允许一次发送这么多请求；之后按稳定速率放行请求。
| 等级 | 速率 | 突发 |
|---|---|---|
basic | 每秒 5 个请求 | 25 |
standard | 每秒 20 个请求 | 100 |
high | 每秒 50 个请求 | 250 |
等级由组织的套餐决定。GET /v1/me 显示调用它的密钥的等级、速率和突发量（rate_limit）。无论有多少台 API 服务器处理您的请求，该限制都针对整个密钥生效。
流式接口 POST /v1/chat（无论是否带 "stream": true）和 GET /v1/jobs/stream 不受密钥速率限制的约束：它们不消耗密钥的速率限制，其 RateLimit 头中也没有 "key" 项。但它们会计入组织配额，每个请求在开始时计入一次。提问另有自己的限制，见下文。
组织的配额
套餐可以为组织设置请求配额：每分钟、每天和每月。时间窗口是 UTC 的日历周期：一分钟从 :00 秒开始，一天从 UTC 00:00 开始，一个月从当月第一天的 UTC 00:00 开始。使用该组织密钥或 OAuth 令牌的每个请求都会计入，无论发往哪个地址。流式请求无论持续多久，都只在开始时计入一次；配额用完时，它与其他请求一样被拒绝并返回 429。被拒绝并返回 429 的请求不计入。
响应头
对带有密钥的请求，每个响应都会给出适用于该请求的限制：
RateLimit-Policy: "key";q=100;w=5, "minute";q=1200;w=60, "day";q=200000;w=86400
RateLimit: "key";r=87;t=1, "minute";r=1150;t=23, "day";r=180311;t=40213
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1
RateLimit-Policy 和 RateLimit 遵循 IETF 草案 RateLimit header fields for HTTP。每一项是一个限制：
| 项 | 含义 |
|---|---|
"key" | 密钥的速率限制。q 是突发量，w 是用完的突发量重新补满所需的秒数。 |
"minute"、"day"、"month" | 组织的配额（如果套餐设置了配额）。q 是配额，w 是以秒为单位的时间窗口。 |
r（在 RateLimit 中） | 该限制下还剩多少个请求。 |
t（在 RateLimit 中） | 距离该限制恢复还有多少秒。 |
X-RateLimit-Limit、X-RateLimit-Remaining 和 X-RateLimit-Reset 以更简单的形式报告其中最严格的限制，供 RateLimit 出现之前编写的客户端使用。X-RateLimit-Reset 以秒为单位。
达到限制时
API 返回 429 Too Many Requests，并带有以秒为单位的 Retry-After 头：
| 错误码 | 含义 |
|---|---|
api.rate_limited | 密钥发送请求的速度超过了其速率。Retry-After 通常为一两秒。 |
api.quota_exceeded | 组织的某项配额已用完。details 说明是哪一项以及何时重置。 |
{
"detail": "the organization has used its API request quota for this period",
"error": {
"code": "api.quota_exceeded",
"message": "the organization has used its API request quota for this period",
"details": {"quota": "day", "limit": 200000, "reset_at": "2026-10-25T00:00:00Z", "retry_after": 40213},
"request_id": "01JB7…"
}
}
等待 Retry-After 后重复请求。重复 POST 和 PATCH 时使用同一个 Idempotency-Key。错误中的重试辅助函数两者都会处理。
套餐的其他限制也返回带有 Retry-After 的 429，例如每天的提问数量（limits.questions）或同时进行中的回答数量（limits.concurrent_answers）。请用同样的方式处理。