Claude Code 撞到用量限制怎么办？计费与额度说明
**Claude Code 的”用量限制”是按时间窗口滚动计算的额度上限：用订阅时它是一个会随时间自动恢复的滚动配额，用 API Key 时它则是按 token 实际消耗付费、几乎不设硬上限。**搞懂你用的是哪一种，撞到限额时就不会慌——这篇带你分清两种计费模型、看懂”还能用多少”，并给出几招实实在在省额度的办法。
如果你还没装好工具，可以先看 Claude Code 教程 跑通第一个任务，再回来看额度怎么管。
原理：两套计费模型，先认清你在哪一套
Claude Code 同一个命令行工具，背后可以接两种”钱包”，计费逻辑完全不同：
- 订阅模式（Pro / Max 等套餐）：你按月付固定费用，平台给你一个用量额度。它不是”用完即止”的一锤子买卖，而是按滚动时间窗口恢复——常见的是几个小时一个短窗口，叠加一个更长的周限概念。窗口内用得猛会先撞短窗口上限，歇一会儿额度自动回血。
- API 按量模式：你用自己的 API Key，按实际消耗的 token（输入 + 输出）计费，用多少付多少。除了你自己在后台设的预算上限，基本不会”被限速”，但花费完全跟随用量浮动。
一句话判断口诀：订阅 = 包月吃额度、会回血、可能被限速；API = 按表计费、不回血、花真金白银。
各套餐的具体额度倍数、窗口时长、周限阈值会随官方政策调整，以官方文档为准，本文只讲不变的机制。
撞到限额时，先做这 3 步判断
报错弹出”已达用量上限 / usage limit reached”时，别急着重装或换号，按顺序排查：
- 看提示里的”恢复时间”。订阅模式撞短窗口时，提示通常会告诉你大致什么时候额度恢复。如果只是几小时后回血，等一等是最省事的解。
- 确认是短窗口还是周限。短窗口很快恢复；若提示触及的是周级别上限，说明这一周用量确实偏大，需要靠下文的省额度方法或切到 API 顶过去。
- 分清”限额”还是”故障”。如果不是额度提示，而是连接超时、模型报错，那是另一类问题，跟额度无关，别误判。
省额度的核心办法：精简上下文
不管订阅还是 API，消耗的本质是 token。同样一个任务，喂进去的上下文越臃肿、来回轮次越多，烧得越快。精简上下文是性价比最高的省额度手段：
- 及时清理会话。一个长会话里塞了几十轮无关历史，每次请求都会把这堆历史重新带上。任务切换时新开干净会话，比在旧会话里硬接省得多。
- 只给相关文件。让模型读整个项目，不如精准指向几个关键文件。范围越聚焦，单次 token 越少，结果还更准。
- 善用项目说明文件。把项目背景、规范固化到
CLAUDE.md这类”新人入职文档”里，省去每次反复解释的口舌。 - 拆小任务。一次让它改十个文件，往往要反复纠错、来回拉扯；拆成小步，每步上下文短、命中率高，总消耗反而低。
想系统性地对比不同工具的花钱方式，可以看 AI 编程工具的成本怎么算（规划中）。
5 个现在就能做的省额度动作
道理讲完了，光知道”要精简上下文”没用，你得知道按哪个键。这几招我自己天天用：
- 失败超过 3 次就
/clear，别硬扛。调试一个 bug，模型第一次改错、你反馈、它再改还错——这种来回每多一轮，前面所有失败尝试都会作为”历史”重新塞进下一次请求。超过三轮还没解决，先把已经确认的信息（报错栈、涉及文件、排除掉的错误方向）整理成一句话喂给新会话，比在旧会话里死磕省得多。 - 用
/compact而不是攒着。这个命令会让模型自己把当前会话历史压缩成摘要再继续，相当于”手动瘦身”，比等它自然涨到爆炸再清空更可控，尤其适合一次改动横跨很多文件、你还想保留关键结论的场景。 - 大文件别整篇贴进对话。几千行的日志、生成的 SQL 结果、超长配置文件，直接粘贴当上下文是隐藏的 token 大户——十有八九模型只需要其中几行报错或几个字段。让它自己用工具读文件、按需截取，比你手动贴全文省得多。
- 简单任务别用最贵的模型顶。改个变量名、写个样板代码、生成注释，这类活儿用轻量模型就能搞定，没必要每次都调用最强的模型去处理。把”简单活配轻模型、复杂活配强模型”变成习惯，长期下来省的额度很可观。
- 大重构先过一遍”计划模式”再动手。直接甩给它”把这个模块重构一下”，它容易一次性铺开改十几个文件，改错了还得整体回滚重来，等于烧两遍。先让它只列改动计划、不动代码，你确认思路没问题（尤其是边界情况有没有漏），再放开手让它按计划逐文件改，返工率明显更低，返工本身就是最贵的那种消耗。
错峰使用：把重活挪到额度宽松的时候
订阅模式的额度按窗口滚动，意味着节奏比总量更影响体验。错峰使用的思路是：
- 别把所有大任务挤在同一个窗口。要重构一大坨代码、跑一连串生成时，分散到不同时间段，避免在一个短窗口里集中引爆额度。
- 高频小事和低频重活分开。日常补全、改小 bug 这类轻活随时干；动辄读全库、长链路推理的重活，挑额度刚回血的时候做。
- 重度需求考虑切 API。如果你经常在订阅限额上撞墙，说明用量已经超出套餐设计的”舒适区”，换成 API 按量反而更顺——不被限速，按真实消耗付费，重度用户常更划算。
三个真实踩坑案例，看看你有没有中招
这几个坑我自己带团队用下来见得最多，都不是理论问题，是实实在在把额度烧光的日常习惯：
- 坑 1：调试陷入”死循环”却不肯清会话。测试一直红，改一版再改一版，同一个会话堆了二三十轮失败尝试，每次新请求都要把这堆历史原样带上，越到后面越贵，模型还容易被前面的错误方向带偏。设一个心理阈值——连续三次没解决就停下，把已排除的方向和确认的报错写成几句话，开新会话重新起步，反而更快。
- 坑 2：团队共享一个订阅账号，撞车式抢额度。几个人用同一账号跑各自的重构任务，扎堆在同一时间段提交大任务，额度瞬间打满，谁都干不了活。要么上 API + 预算上限按人头分开算账，要么约定错峰排队——“反正额度共享随便用”这种心态在多人协作里必翻车。
- 坑 3：把整个项目当上下文喂进去图省事。不想一个个指文件，干脆让它”读一下整个项目再改”，看着省事，实则每次请求都在为你用不到的代码付费，还会因无关信息太多拉低判断准确度。先想清楚改动涉及哪几个文件再动手，是最高性价比的办法。
订阅还是 API？按用量画像选
| 你的情况 | 推荐 | 原因 |
|---|---|---|
| 每天稳定写代码、用量可预期 | 订阅套餐 | 包月封顶，成本可控，额度回血够日常用 |
| 偶尔用、用量很轻 | API 按量 | 用多少付多少，闲置不浪费 |
| 经常撞限额、批量重活多 | API 按量 | 不被限速，重度用户按量往往更省 |
| 团队多人协作、要管预算 | API + 预算上限 | 后台可设花费上限，账单清晰可分摊 |
没有绝对的”哪个便宜”，关键看你的用量是平稳还是爆发：平稳选订阅图省心，爆发或重度选 API 图不卡。
怎么验证额度还够不够
- 看工具内提示：撞限额时的报错本身就带恢复时间，是最直接的信号。
- API 模式查后台用量：用 API Key 的话，到对应平台后台能看到 token 消耗和花费明细，按天监控避免超预算。
- 观察响应节奏：明显变慢、频繁要你”稍后重试”，往往是接近短窗口上限的前兆，这时主动放缓比硬刚更明智。
具体在哪个页面看用量、各端点字段名是什么，以官方文档为准，平台界面会迭代。
常见问题
Q：Claude Code 撞到限额是不是这个月就不能用了？ A：订阅模式绝大多数是短窗口限速，几小时后额度自动恢复，不是整月封停。只有触及更长的周限时才需要等较久或切 API。
Q：为什么我感觉额度掉得特别快？ A：多半是上下文太臃肿——长会话历史、让模型读了整个项目、任务一次铺太大。清理会话、聚焦关键文件、拆小任务，消耗会明显下降。
Q：用 API Key 会不会也被限速？ A：API 按量模式基本不设这种额度限速，按实际 token 付费。但你可以（也建议）在后台设花费预算上限，避免账单失控。
Q：订阅和 API 能同时用吗？哪个更省钱？ A：可以按需切换。用量平稳选订阅（包月封顶省心），用量爆发或重度选 API（不卡、按量算常更划算），没有放之四海皆准的答案，看你的用量画像。
👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全 把基本功打扎实。