理解 Claude API 的速率限制

Claude API 的速率限制到底是什么

Claude API 的速率限制是吞吐上限：你的账户每分钟最多能发出多少请求、推过多少 token。一旦超过，API 返回的不是补全结果，而是 HTTP 429。apiToken.sale 不公布固定的 RPM 表——这里的 429 表示网关或上游容量受限，持久的解法是守规矩的重试加上降低并发，而不是在配置文件里调大一个数字。

在 Anthropic 官方 API 上，限流按三个维度计量：每分钟请求数、每分钟输入 token 数、每分钟输出 token 数，以组织为单位统计。直连官方时，这些上限会随着累计消费增长沿用量等级（usage tiers）上调。三个计数器每分钟都会重置——这就是为什么三十秒的突发流量可能失败，而你的小时均值看起来微不足道。

另见： Claude API 最佳实践

读懂 429 响应

写得好的客户端会把 429 当作数据，而不是失败。响应体里带有 rate_limit_error 类型的错误，响应通常还带有 retry-after 头，标明服务器希望你等待的秒数。

curl -i https://router.apitoken.sale/v1/messages \
  -H "x-api-key: sk-pool-•••" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 64,
    "messages": [{"role":"user","content":"hi"}]
  }'

# when throttled:
# HTTP/2 429
# retry-after: 17
# {"type":"error","error":{"type":"rate_limit_error","message":"..."}}

retry-after 只是建议，不是契约，也不是每个 429 都带这个头。头部缺失时，退回带抖动的指数退避——并且绝不要用紧凑循环重试 429，那只会加剧造成限流的拥塞。

能扛住生产环境的重试策略

1. 01把突发流量排队，而不是一次性打出去：每个 worker 一次只发一个请求。
2. 02收到 429 时读取 retry-after，至少睡够它指定的秒数。
3. 03头部缺失时，睡眠 base × 2^attempt 再加随机抖动，封顶约 30 秒。
4. 04重试 4–6 次后停手，让任务明确失败，而不是无限重试。
5. 05记录模型、等待时长和重试次数——如果 429 持续出现，你就有规律可以拿给支持团队看。

const sleep = (ms: number) => new Promise((r) => setTimeout(r, ms));

async function callClaude(body: unknown): Promise<Response> {
  for (let attempt = 0; attempt < 5; attempt++) {
    const res = await fetch("https://router.apitoken.sale/v1/messages", {
      method: "POST",
      headers: {
        "x-api-key": process.env.APITOKEN_KEY!,
        "anthropic-version": "2023-06-01",
        "content-type": "application/json",
      },
      body: JSON.stringify(body),
    });
    if (res.status !== 429 && res.status < 500) return res;
    const retryAfter = Number(res.headers.get("retry-after"));
    const wait = retryAfter > 0
      ? retryAfter * 1000
      : Math.min(1000 * 2 ** attempt, 30_000) * (0.5 + Math.random() / 2);
    await sleep(wait);
  }
  throw new Error("Claude API still rate-limited after 5 attempts");
}

为什么突发流量先于平均值触限

因为计数器按分钟计，并发才是真正的杠杆。在一分钟的开头并发打出五十个请求，即使接下来一小时什么都不发，也可能耗尽请求预算。token 计数器会放大这个效应：每一个并发的长生成在运行期间都在持续消耗输出 token 预算，所以十个并行的 4,000 token 回答对限流的压力，远大于十个快速短答。

流式不改变任何计量逻辑。流式调用仍然是一个请求，按与非流式完全相同的输入输出 token 计量和计费——它只是让你更早渲染 token，并在智能体拿到所需内容时提前中止。

Claude API 流式输出详解：SSE 事件与相同的计费 →

吞吐限制不是消费限制

这里有两套容易被混淆的系统。速率限制是流量整形器：临时的、按分钟计的、靠等待就能解决。消费护栏是预算刹车：它决定一个密钥总共能花多少钱。apiToken.sale 的控制台完全不提供请求吞吐配置——它提供的按密钥护栏只有可选的终身累计消费上限和到期日期。429 说的是“慢一点”，与你的余额无关，充值也解不了它。

如何为密钥设置终身消费上限和到期日期 →

不提额也能降低 429 压力

• 给定时任务和批处理任务加随机偏移，避免它们在同一分钟扎堆。
• 给 worker 并发设上限，让队列吸收突发流量。
• 精简上下文，让每个请求携带更少的输入 token。
• 把 max_tokens 限制在响应真正需要的范围。
• 用提示词缓存（prompt caching）缓存大而稳定的上下文，降低重复请求的计费输入成本。

大多数 429 风暴是自找的：没有抖动的重试循环、把 worker 数翻倍的部署、整点（:00）扇出的定时任务。先把流量形状修整好，再考虑要不要更高的上限。

当 429 变成容量问题

如果流量已经整形、重试也写对了，在目标负载下仍然规律出现 429，那就是容量问题，而不是代码问题。联系支持时说明你使用的模型、目标的每分钟请求数与 token 数、以及负载形态——持续更高的吞吐走账户沟通解决，没有自助滑块。

常见问题

相关指南