codex额度用完任务没结束

用 Codex 跑一个大改动，跑到一半弹出额度用尽，任务还停在半路——这种卡点最难受：既不敢直接关掉，又不知道重新跑一遍要再烧多少。这篇给一套按顺序执行的恢复动作：先把当前状态固定下来，再决定是等额度、换档位还是换通道，最后回头算一遍这次到底花了多少、下次怎么把任务切小。

用 Codex 跑一个大改动，跑到一半突然弹出额度用尽，任务卡在半路——这种时候最容易犯的错就是手一抖重新发一遍指令。重跑不只是多烧额度，还可能把已经改对的部分覆盖掉，反而更难收拾。

正确的顺序是三步：先把当前现场冻住，再判断走哪条恢复路线，最后回头算清这次到底花在哪了。下面按这个顺序拆成可执行的动作，每条都写清什么情况下不适用。

第一步不是重试，是先把现场冻住

中断提示一出现，先别碰对话框。第一件事是确认改动有没有落到本地文件。如果改动已经在工作区里，能提交就提交到一个临时分支，命名带上「半成品」之类的标记；不能提交就把差异导出来单独存一份。目的是让重跑时有对照物，而不是对着一个已经变形的代码库继续改。

1. 导出差异用版本控制工具把当前未提交的改动导成补丁文件或差异文本存到项目外，验证方法：关掉编辑器再打开，这份文件还能正常读取、能还原。
2. 写任务交接说明从会话里摘出四样东西：最终目标、已完成的部分、剩余的部分、必须遵守的约束。写成一份纯文本，两三百字就够，后面不管换哪个通道接手都用这份。
3. 记下报错原文和当时时间报错文案里的关键词决定了后面是查周期额度还是单次上限；时间戳用来推算额度周期怎么滚。这两条线索别靠回忆，当场复制粘贴存下来。

三条路怎么选：等、换档、换通道

确认额度确实是这个原因之后，有三条路：等额度周期滚动、换计费档位、换到别的通道继续跑。选哪条不是看心情，是看剩余任务量和交付时间这两个变量。

不管走哪条，动手前先去站内核对两件事：你当前档位的额度按什么周期刷新、按量通道的单价是怎么算的。这些口径会变，别凭印象判断，到 /coding-plans 和 /official-api 看当时的数字。要比较模型之间的单价差异，去 /models 逐个对照。

把大任务切小，是省额度最实在的一招

一个长任务被中断，常见原因是上下文堆得太长：前面几十轮的历史全在里面，重跑一次等于把这些历史再喂一遍，额度自然吃紧。改成按模块推进，每段结束先总结成结论，下一段只带结论不带全过程。

• 先让它给出要改哪些文件的清单，清单确认没问题再逐条执行，能挡掉一部分无效往返
• 按文件或按函数拆，一次只改一个单元，改完立刻提交一次，中断了也只丢一小步
• 每段结束时让它把当前结论写成几句话，下次开新会话直接贴这段，不贴全部聊天记录
• 遇到需要跨多个文件反复对照的改动，先手动把相关文件路径和关键片段整理成一小段说明再发过去

这套做法不适用的情况是：任务本身高度耦合，改一处必须全量重跑才能验证。这种时候切分反而制造更多对不上的接口，换通道继续跑更划算。

恢复完之后，回头把这次的花费算清

活干完了不代表结束，还得知道这次花在哪了。把中断前后的用量记录合起来看：同一份活分两次跑，多出来的部分基本都在重复喂上下文上，这部分是可控成本。

• 把中断前和恢复后的用量记录对着看，找重复出现的输入部分
• 用 /tools/model-cost-calculator 把这次的实际消耗换算成一个具体数字，作为下次同类任务的预算基准
• 跑长任务之前，先去 /coding-plans 对照自己档位的额度口径，判断这类任务大概能撑几轮
• 给常跑的大任务留一份「任务模板」，把拆分方式和交接说明格式固定下来，下次直接套用

如果同一个任务反复在差不多的地方断掉，说明拆分点选得不对，不是额度不够，是任务颗粒度需要重划。这种情况先回去改拆分方式，再谈加额度。

额度耗尽只是个信号：要么任务太大，要么上下文太长，两个问题都能靠拆分解决。