Claude API 速率限制 — 429、Retry-After 与吞吐建议
ClaudeStore 的 429 处理、Retry-After、保护性限流与高吞吐场景建议。
限流是如何工作的
| 范围 | 说明 |
|---|---|
| 每个 API Key | 单个 Key 可能被独立限流 |
| 按 Key 并发 | 过多同时进行的长请求可能触发 429 |
| 网关全局保护 | 高负载时网关会主动保护稳定性 |
| 大附件 / 多模态 | 这类请求可能比纯文本更严格 |
我们不公开固定的 RPM/TPM 数字表作为外部契约。如果你需要更高持续吞吐，请联系客服并说明你的负载模式。
HTTP 429 处理
当超过限额时，API 返回：
HTTP/1.1 429 Too Many Requests
retry-after: 8
{"error": {"type": "rate_limit_error", "message": "..."}}客户端应解析 retry-after 头并等待对应秒数后重试。建议结合指数退避，并降低并发而不是盲目重试。
最佳实践
- 使用 客户端排队（p-limit / bottleneck）控制并发
- 启用 缓存 降低重复流量
- 对长流式请求和多模态请求使用更保守的并发与重试策略
- 不同项目 / 服务使用独立 Key，避免相互影响
- 如需更高限额，联系客服开通
Cursor / Claude Code 往往会自动重试 429，但如果频繁触发，真正该做的是降低并发或联系支持，而不是堆更多重试。