订阅明明没用完却报 Rate limit reached？先分清限流、配额和并发三件事

2026-08-08

有一类报错特别让人窝火：你花钱买了高档订阅，用量显示才走了不到两成，它告诉你限流了。

GitHub 上 issue #29579（仍开放，153 条评论）的标题就是这个：API Error: Rate limit reached despite Claude Max subscription and only 16% usage。

这篇要说清楚的是：在 Claude Code 里，「被拦住」其实有三种完全不同的机制，它们的报错长得像，但一个是服务端的短期限流、一个是你的套餐配额、一个是你自己的并发设置。看错了类型，怎么调都没用。

一、三种机制，先对号

报错原文	机制	跟你的套餐有关吗
`Server is temporarily limiting requests`	短期限流，API 侧施加	官方明确写了：与计划配额无关
`You've hit your session limit` / `You've hit your weekly limit`	套餐配额用尽	有，就是你的配额
`Request rejected (429)`	速率限制，针对 API key / Bedrock 项目 / GCP 项目	跟凭证和并发有关

第一行是关键。官方对 Server is temporarily limiting requests 的说明里，专门点出了「与计划配额无关」——这解释了 issue #29579 那种「订阅没用完却被拦」的体感：你撞的可能根本不是你的配额。

二、机制一：短期限流（跟你的套餐无关）

报错：Server is temporarily limiting requests

官方处理：等待后重试；如果持续，去查 status.claude.com。

就这两条，没有别的。因为这是服务端侧的短期措施，不在你这边。

怎么认出它：报错文本里说的是「temporarily limiting」（临时限制），不是「hit your limit」（你的额度到了）。这两种措辞的区别是本文最值钱的一句话——一个是它临时不接，一个是你确实用完了。

该做什么：等。以及别去动订阅、别去买额度——买了也不会解决这个，因为它跟配额不是一回事。

三、机制二：套餐配额用尽

报错：You've hit your session limit 或 You've hit your weekly limit

官方给的处理有五条：

等消息里显示的重置时间
如果是 Opus 的限制：运行 /model 换一个模型
/usage 查看你的计划限额
/usage-credits 购买额外用量，或者向管理员申请
升级计划：claude.com/pricing

第二条特别值得单独说。Opus 类模型往往有独立于整体配额的限制——也就是说，你可能只是 Opus 用完了，换个模型立刻能接着干。这条是五条里唯一能立刻恢复工作的，遇到限额先试它。

第三条 /usage 是判断的关键：它告诉你真实的限额状态。如果 /usage 显示你还剩很多，那你撞的就不是这一类，回去看机制一和机制三。

还有一条相关的：Usage credits required for 1M context。成因是你选的模型带了 1M token 的扩展上下文窗口，但你的计划不包含。处理是：

/model 选不带 [1m] 后缀的变体
或 /usage-credits 启用计量计费
或检查 CLAUDE_CODE_DISABLE_1M_CONTEXT=1 这个环境变量的设置

那个 [1m] 后缀是个明确的视觉标记——在 /model 列表里看到它，就知道那是要额外计费的。

四、机制三：429，跟并发有关

报错：Request rejected (429)

成因：API key、Amazon Bedrock 项目或 Google Cloud 项目达到了速率限制。

官方处理四条：

/status 确认活跃凭证
去提供商控制台查当前的限额，必要时申请更高层级
Anthropic API key 用户参考速率限制文档
降低并发：调整 CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY

第四条是这一族里唯一一个你自己就能改的旋钮，也是最容易被忽略的。

什么时候该动它：如果你在跑那种一口气调很多工具的任务——批量改文件、批量读代码、多个子代理并行——请求会在很短时间里密集打出去。这种情况下撞 429，不是因为你用得多，是因为你用得太挤。

把这个值调小，总量不变，但摊得更开，就不容易撞线了。代价是慢一点。

这里有个容易搞混的地方：429 和前面的 529 都是「被拒」，但

429 是速率限制，跟你的凭证和并发有关，降低并发有用
529 是服务端容量不足（overloaded_error），跟并发无关，调并发没用，只能换模型或等

看报错体里的 type 字段，比看数字可靠。

五、issue #29579 里那条社区办法

回到开头那个「Max 订阅只用了 16% 却持续限流」的 issue。

这条 issue 到核对日仍然是开放状态，没有官方结论。但评论区有一条被提到的绕过办法：

把模型从 opus 切到 haiku（那个能用），然后再切回 opus。

这是社区在 issue #29579 里给出的做法，官方没有确认过，也没有解释为什么会有效。

要不要试？可以试，它没有破坏性——切模型是个可逆操作，/model 来回切就行，不会丢对话。但别把它当成解释：它能不能有效、为什么有效，公开信息里都没有答案。

如果它有效，其实也侧面印证了本文的分类：你撞的可能是某个特定模型的限制，而不是账户整体的配额。

六、一条判断路径

下次被拦住，按这个顺序走，两分钟内能定位：

读报错文本的措辞
- 「temporarily limiting」→ 服务端短期限流，等就完了，别动配置
- 「hit your session/weekly limit」→ 你的配额，走第 2 步
- 「Request rejected (429)」→ 速率/并发，走第 4 步
/usage 看真实限额状态
- 显示确实用完了 → 等重置，或 /model 换模型（尤其 Opus 限制），或 /usage-credits
- 显示还剩很多 → 你撞的不是配额，回去看第 1 步的措辞，多半是短期限流
/model 换一个模型立刻试
- 换了就通 → 是那个模型的限制，不是你的账户
- 换了还不通 → 继续往下
看你刚才是不是在跑高并发任务
- 是 → 调小 CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY
- 不是 → 回到第 1 步重新看措辞
/status 确认凭证来源
- 走的是 API key 而不是订阅？那你的限额来自那个 key，跟订阅无关——这也是「订阅没用完却被限」的一种常见真因

第 5 步值得强调。如果环境里有 ANTHROPIC_API_KEY，你的订阅可能压根没在生效，用的是那个 key 的限额。这种情况下再怎么升级订阅都没用。unset ANTHROPIC_API_KEY 之后 /login，问题就变了。

七、控制台用户还有第四种「被拦住」

前面三种机制说的是订阅和 API key 场景。如果你用的是控制台组织的预付额度，还有一种：

Credit balance is too low

成因是控制台组织的预付积分用完了。官方处理三条：

去 platform.claude.com/settings/billing 加额度，可以考虑开自动充值
或者用 /login 切换到订阅认证
在控制台里设置按工作区的支出上限

第二条值得注意——它是一条「换条路走」的建议，而不是充钱。如果你本来就有订阅，环境里的 API key 又刚好没钱了，那 unset ANTHROPIC_API_KEY 加 /login 就能立刻恢复。

跟它相关的还有一条 Could not update your spend limit（改支出上限被服务器拒绝）。官方处理：报错里如果说了原因就按那个原因选一个符合要求的额度；如果是通用报错就重试；一直失败的话，从浏览器里的 claude.ai 计费设置去改。

第一条建议里的「自动充值」是个双刃：它能避免月中突然停摆，但也意味着支出没有硬性上限。官方给的第三条（设按工作区的支出上限）正好是配套的——开自动充值的同时设支出上限，两个一起用才是完整的做法。

八、总结

「临时限制」和「你的额度到了」是两种不同的措辞，对应两种不同的机制。先读措辞。
/usage 是分水岭：显示还剩很多，就说明你撞的不是配额。
Opus 类模型可能有独立限制，/model 换模型是最快的一次尝试。
429 才该调并发（CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY），529 调了没用。
环境里的 API key 会盖掉订阅——这是「订阅没用完却被限」最容易被忽略的一种真因。
issue #29579 里的「切模型再切回」是社区办法，官方未确认，可以试，别当结论。

本文所引官方内容来自 Claude Code 官方错误参考文档，issue 编号与社区办法来自 anthropics/claude-code 仓库 issue #29579（核对日仍为开放状态），核对日 2026-08-08。