如果看到 "Claude API Error: Rate limit reached"，先不要连续重试。第一步不是换 key、升级套餐或改供应商，而是确认这次请求到底由谁处理：Anthropic 直连 API、Claude Code、Bedrock、Vertex AI、第三方网关，还是短时间突发桶。
| 使用入口 | 可能归属 | 先做什么 | 证据 | 下一步 |
|---|---|---|---|---|
| Anthropic 直连 API | workspace 与模型限制 | 按 retry-after 暂停，缩小请求 | HTTP 429、rate_limit_error、anthropic-ratelimit 头 | 同一路由重试一个更小请求 |
| Claude Code + API key | API key 所属 workspace | 跑 /status 并确认凭证路径 | Claude Code 状态与 API 日志 | 降低 Code 调用量或查 Console |
| Claude Code 订阅会话 | 计划或 session 窗口 | 不要先查 API header | 文案提到 period、window 或 plan | 转到 Claude Code 用量限制处理 |
| Bedrock / Vertex AI | 云厂商项目 | 打开厂商 quota 页面 | provider 429、ThrottlingException、region quota | 调 quota 或换区域容量 |
| 第三方网关 | 网关租户或上游策略 | 先查网关日志 | gateway 429、租户 policy 命中 | 调整网关限额或联系供应商 |
| Burst / acceleration | 你的流量形状 | 降并发、排队、慢启动 | RPS 或 concurrency 突增 | 等窗口、缓冲、同路验证 |
停止规则：在归属没有确认前，不要连续重试、不要换 key、不要升级套餐、不要切换供应商。你一旦换路由，原始错误就不再可验证。
先确认是哪条路由产生限制
"rate limit reached" 只是症状，不等于所有情况都是同一个 API 桶。服务端直接请求 api.anthropic.com 时，证据在 HTTP 状态、响应体和 header。Claude Code 如果设置了 ANTHROPIC_API_KEY，终端请求可能走 API key 计费，而不是你以为的 Pro 或 Max 订阅。Bedrock、Vertex AI 或网关返回类似限流文案时，归属可能在云项目、区域、租户或代理策略。
先问三个问题：谁处理了这次凭证？哪个控制台拥有这个凭证？能否在不换模型、不换 provider、不改 prompt、不改 region 的前提下，同一路由复现一次？如果每次都换变量，你得到的是绕过，不是诊断。
如果终端其实是 500、529 或 Claude Code usage window，不要把它塞进本页，可以转到 Claude Code 500/529/rate limit 路由表。Claude Code 专门的 rate limit 分支见 Claude Code rate limit。
Anthropic 直连 API：先相信 header
直连 Anthropic API 的 HTTP 429 对应官方 rate_limit_error。真正有用的不是固定 tier 数字，而是 retry-after、anthropic-ratelimit 请求桶、输入 token 桶和输出 token 桶。月度额度还剩，不代表当前一分钟窗口没有耗尽；预算正常，也可能被 output token 或并发请求压住。
下一次请求要更小、更慢、更可测。按 retry-after 等待，减少并发，降低 max output，把大任务拆开，缓存稳定上下文，然后只在同一模型、同一凭证、同一路由上重试一个请求。
Claude Code：先查 active route
Claude Code 多了一层路由。/status 会告诉你当前认证路径；ANTHROPIC_API_KEY 会让请求走 API key workspace。不要用订阅升级去修 API-key 429，也不要用 API header 去解释订阅 session window。计费和权限归属可参考 Claude Code API key vs subscription billing，配置边界见 Claude Code API configuration。
为什么用量看起来还够，请求却被挡
速率限制通常是滚动窗口。RPM、输入 token、输出 token、burst、provider quota 可以分别触发。一个长上下文会压输入 token；一个很长的回答会压输出 token；很多小请求会压 RPM；突然放大流量还可能触发 acceleration 控制。
修下一次请求，不要制造更多噪音
一次只改一个变量：加 jitter backoff，限制 worker 并发，降低输出上限，把同步任务放进队列，记录 status、request_id、路由归属、model、workspace、region、retry-after 和 remaining/reset header。验证必须保持同一路由，否则错误消失也无法说明原问题。
如果团队里有人同时改 prompt、切模型、换网关和调 worker 数，这次排查就会失去价值。更稳妥的做法是先冻结失败路径，把最近一次成功请求、第一次失败请求和当前失败请求放在同一张表里比较。你要找的是哪个维度突然变化：请求数、输入 token、输出 token、区域、项目、租户、模型还是凭证。这个比较能把“服务不稳定”的直觉变成可操作的限流证据，也能避免把本应由网关处理的问题误报给 Anthropic。
provider 或 gateway 限制
通过 Bedrock、Vertex AI 或网关调用 Claude 时，Anthropic Console 不一定拥有这次失败。Bedrock 看 service quota 和 region，Vertex AI 看 project/location/model quota，网关看租户限额、上游策略和 per-key throttle。
升级前准备证据包
同路复现仍失败后再升级处理。证据包包括 exact message、时间与时区、request_id、response headers、model、workspace/project/region、路由归属、最近流量变化、状态页结果和最小复现请求。不要发送 API key、token、用户隐私内容或猜测性结论。
真正有用的升级不是长篇描述，而是一组能让对方复核的字段。对于直连 API，header 和 request_id 最关键；对于 Bedrock 或 Vertex AI，项目、区域和 quota 页面截图更关键；对于网关，租户 key、上游路由和限流策略更关键。把这些分清楚，support 才能判断应该扩容、等待窗口、修客户端排队，还是把问题转给正确的平台。
常见问题
这个错误一定是 Anthropic 直连 API 429 吗？
不一定。直连 API 429 最清楚，但 Claude Code、云厂商、网关和 burst 控制都可能出现相近文案。
要不要先换 API key？
不要。先证明 active route。换 key 可能改变归属，让原错误无法复现。
为什么额度页面还显示可用？
因为月度额度、订阅窗口和滚动 RPM/token/burst 窗口不是同一个东西。
Claude Status 正常怎么办？
继续查本路由证据：直连 API 看 header，Claude Code 看 /status，云厂商看 quota，网关看日志。
什么时候联系 support？
同路验证仍失败且证据包完整时再联系对应归属方。