Claude Code 撞到用量限额，当前对话还会做完吗？原因与应对
有用户观察到 Claude Code 撞到五小时限额后会先把当前回合做完再停，但也有人在客户端里看到会话被直接终止。本文解释「会做完」到底指什么、结果为什么不一致，并给出一套把可能中断当成常态的工作流设计：小步提交、进度文件、恢复会话、收尾约定，以及要不要刻意把额度用满的取舍。
最近有用户发现，Claude Code 在撞到五小时用量上限之后，不再像以前那样立刻掐断，而是会把当前这一轮对话先跑完，再给出限额提示；不过同一时间，也有人在新版客户端上看到会话被直接终止。同一个产品，两种结果，于是问题就变成了：这个「会做完」能不能依赖？如果不能，工作流该怎么设计才不至于在收尾阶段丢掉成果？
需要先说明的是，这类行为属于产品侧的调度细节，随时可能调整。下面的分析基于使用者的观察与常见的限流实现方式，具体规则请以官方最新的用量说明为准。
「会做完」到底指什么
「把当前对话做完」这句话很容易被理解得过宽。它通常只覆盖到某一个粒度：
- 一个回合：从你发出消息，到模型停止生成、把控制权交回给你。
- 一次工具调用：模型发出命令、等结果返回、再继续推理。
- 一个后台任务：例如启动的构建、测试、开发服务器，这些是独立进程，不受会话限额直接约束。
所谓「撞限后做完」，比较接近前两者的组合：当前这轮生成能收尾，正在跑的那条命令能拿到结果，然后停下来。它不保证计划里剩下的步骤会继续执行，也不保证队列中的子任务、后台进程、多文件重构的后续部分会完成。所以「最起码能收尾并提交代码」是一个概率性结论，而不是承诺。真要保住成果，得靠工作流兜底。
为什么有人做完、有人被终止
结果不一致，通常来自下面几个变量叠加：
| 变量 | 造成的影响 |
|---|---|
| 客户端版本 | 新旧版本处理限流的方式不同，界面版与命令行版也可能不同 |
| 所用模型 | 不同模型走的配额通道和限流实现不一定一致，同一账号换模型结果可能相反 |
| 账号档位 | 有的档位只有周窗口，没有五小时窗口，撞限的表现自然不同 |
| 中断时刻 | 正在生成文本、正在等工具返回、正在等待你的确认，三种状态的处理不一样 |
| 运行方式 | 交互式会话、非交互的脚本调用、集成到 CI 里的调用，退出行为差别很大 |
| 提示类型 | 提示配额耗尽，和提示服务端容量不足，是两件事 |
最后一条值得单独说。配额提示意味着你这个窗口的额度用完了，只能等重置或者换档位；而容量类提示（例如提示服务暂时过载）往往与你的用量无关，属于服务端侧的问题，表现为「莫名其妙自己停了」，重试或换个时间往往就恢复。把这两种情况混为一谈，会得出完全错误的结论。所以遇到中断，第一件事是看清提示原文，而不是急着调整用法。
把「可能被打断」当成常态来设计工作流
与其猜测这一次会不会做完，不如让任务在任何时刻被打断都不至于返工。下面这份清单可以直接照做：
- 一次只推进一个可验证的小目标。改完一组相关文件就跑一次针对性测试并提交，不要攒到最后一起提交。
- 在项目说明文件里写死收尾约定。让 agent 每次都知道「先验证、再提交、最后汇报」。
- 用一个进度文件承载上下文。动手前把计划写进去，完成一项勾掉一项，中断后新会话读这个文件就能续上，不依赖聊天记录。
- 把耗时的验证单独拆成一个回合。全量测试、完整构建放在独立请求里，避免和大量代码修改挤在同一轮。
- 用会话恢复而不是重开。继续上一次的上下文，比重新描述需求省得多。
- 接近上限时切换指令模式。不要再开新功能，直接要求「只做收尾：跑测试、修失败项、提交、列出未完成项」。
- 长任务放在窗口初期开始。越早开始，越不容易在关键步骤被截断。
项目说明文件里可以放一段类似这样的约定：
## 收尾约定
- 每完成一组文件改动就 commit，提交信息写清改了什么、为什么
- 跑测试前先跑单文件测试，通过后再跑全量
- 会话可能随时因额度中断：动手前把计划写入 PROGRESS.md，完成一项勾掉一项
- 收尾时输出三段：已完成 / 未完成 / 下一步第一条命令
这样即使这一轮被硬终止，下次接手的人（或下一次会话）也能在几十秒内回到现场。
故意提一个超复杂的问题把额度用满，划算吗
有人提出：既然撞限后还会做完当前对话，那在额度快用完时丢一个超复杂的问题过去，不就能多榨一点？
从单次窗口看，这确实可能让当前窗口的额度用得更接近上限。但要看清代价：总量是由更长周期的额度决定的。在一个五小时窗口里多用掉一些，意味着后面的窗口会更早用完，本周剩下的时间可能就没得用了。是划算还是亏，取决于你的实际情况：
- 适合这么做：额度马上就要重置、确定这几天用不完，且手上正好有一个需要长期推理的难题。
- 不适合这么做：本周还有连续多天的开发任务，或者团队里还有其他人共用这个账号。
如果只是想让碎片额度不浪费，更稳的做法是把它用在「读代码、梳理方案、写测试」这类不产生大量文件改动、中断了也不心疼的任务上，而不是赌一个跑不完的大重构。
环境层面的中断，别误判成撞限
很多「会话被终止」其实和额度无关：笔记本合盖休眠、Wi-Fi 切换、SSH 连接超时、终端被关掉，都会让一个跑了几小时的任务凭空消失。判断方法很简单——看提示里有没有明确的用量字样，以及重连后能不能恢复会话。
如果你经常跑长任务，建议把会话放进 tmux 或 screen 里，断线不丢进程；或者干脆把 Claude Code 放在一台长期在线、网络稳定的机器上运行，本地只做连接。整机独享的远程 Mac（例如放在新加坡机房、按月租用、远程连接使用的那种）适合这类场景：它解决的是「机器不休眠、连接不掉线、可以长期挂着跑」的问题，对额度规则本身没有任何影响，是否值得取决于你的任务时长和本地设备状况。
需要自己确认的几点
- 用你的客户端版本和常用模型，实际撞一次限，看提示原文和会话状态，别只看别人的截图。
- 区分「额度耗尽」和「服务容量不足」两类提示，前者只能等或升级，后者重试即可。
- 当前档位的窗口长度、重置时间和计费口径，以官方文档为准；不同档位差别很大。
- 团队共用账号时，把额度当成共享资源来看，个人视角的「薅到就是赚」在多人场景下往往变成互相挤占。
小结
撞限后能否做完当前对话，是一个会随版本、模型、账号档位和中断时机变化的行为，可以当作「运气好时的额外收益」，但不能写进流程假设里。真正可控的是三件事：把任务切小并及时提交、用进度文件把上下文外置、在环境上消除休眠与断线这类假性中断。做到这三点，无论这一次是被完整收尾还是被硬终止，损失都只是几分钟，而不是一整天。
