codex额度用完了会突然中止吗

用 Codex 跑长任务，最怕跑到一半额度没了，不知道是直接断、还是能收尾、已经改的文件会不会白改。这篇不告诉你额度有多少，只讲额度耗尽那一刻通常会发生什么、你在动手前该做哪几件事，把「突然中止」变成「可预期的中止」。具体数字和档位口径，去站内对应页面核对当时的数。

用 Codex 跑长任务的时候，最容易让人心里没底的一刻，就是担心额度不够用了——它到底是干脆直接退出，还是能让这一轮先跑完再停？手头已经改动过的文件会不会白改？这篇不给你一个「额度有多少」的数字，只讲额度耗尽那一刻通常会怎么发生、哪些环节还能保住、哪些必须重来。目标很简单：把一件你无法控制的「突然中止」，变成一件你能提前安排的「可以预期的中止」。

这里说的额度，既包括订阅制客户端里按周期刷新的用量口径，也包括按量计费的 API 通道的余额口径。两者被挡的时点、报错的措辞、恢复的方式都不太一样，下面的判断标准会分别说明。至于你当前档位具体是多少、刷新节律是什么，别凭印象，去站内对应页面核对当时的数。

先分清「停止」的三种含义

很多人一看到任务停住就以为是同一种情况，其实至少分三种：一是请求被直接拒绝，压根没开始跑；二是当前这一回合跑完了，但下一轮发不出去；三是客户端直接退出、窗口关掉或者弹出报错。对任务的破坏程度完全不一样，第一种你还没改任何东西，第三种可能连上下文都丢了。先分清是哪一种，再决定怎么处理。

请求被拒

发出去就被挡回来，任务没动，改过的文件不受影响，等额度恢复或换通道就行

回合结束但上下文还在

这一轮正常收尾，下一轮发不出去，客户端里通常还能看到之前的对话，接着续跑有可能

客户端退出或报错

最麻烦的一种，本地未保存的内容、会话上下文可能都没了，只能从已有产物重来

判断自己是哪一种，最直接的办法是看报错的措辞，而不是猜。额度类、限速类、网络类错误长得不一样，处理路径也不同。如果任务本身很短，一次请求内就能完成，那基本不会体现为「中止」，你甚至感受不到额度这件事。

• 按量 API 通道：多在上游返回额度类错误时被挡，请求压根没执行
• 订阅制客户端：多在「下一次请求」处被挡，当前这一轮往往能跑完
• 并发多任务：同时打满时校验被拒的时点会提前，看起来像「瞬间」停
• 对应动作：把任务拆成能独立提交的小步，任意一步被挡都有人接手

为什么很多时候不是「立刻」断

额度校验通常发生在一次请求开始之前，而不是生成到一半时从中间掐掉。所以常见的现象是：这一轮正常跑完、输出完，到你发下一轮的时候才被挡住。你感受到的是「停顿一下然后停」，而不是「瞬间消失」。客户端如果带本地队列和自动重试，还会先重试几次再报错，表现为卡几秒到几十秒。

1. 确认是不是真被挡先别急着下结论，等十几秒看它有没有自己恢复。限速类错误等一会儿就能继续，跟额度耗尽不是一回事，别混在一起处理。
2. 看有没有重试痕迹客户端带重试时，日志里通常能看到连续几次请求的痕迹，最后才报错。看到这个模式，基本可以判定是上游拒绝，而不是本地卡死。
3. 区分本地动作和模型动作工具调用、写文件、执行命令这些本地动作不消耗额度。模型侧被挡，不代表已经落盘的改动没了，先别回滚。
4. 记下停止的时点记清是「第几轮」停的，比记现象有用。同样规模的任务反复在相近轮数被挡，说明你的排期方式需要调整。

额度耗尽时，哪些东西通常还在

被挡住之后第一件要做的事，是盘一下手头还剩下什么，而不是急着从头重来。已经写进本地工作区的文件改动、已经执行完的命令结果，一般都不受额度影响，因为这些动作发生在本地，跟模型侧能不能继续请求没关系。这部分先保留。

这里有个通用建议：分批任务的中间产物尽量落盘成文件，而不是只停留在对话里。对话能不能恢复，取决于客户端实现，你没试过就不知道；但写进文件的东西，只要工作区还在就还在。这是成本最低的一道保险。

要提醒的是，如果你的任务跑在远程沙箱或托管环境里，环境随会话销毁，那产物也可能跟着没了。这种场景下，退出前主动把需要的东西导出，是唯一可靠的补救。相反，只在本机工作区跑的任务，这一步可以省。

动手前把这几件事定好，能省一次返工

与其等被挡了再想办法，不如开工前就花几分钟把预期和边界定下来。核心就一件事：让任务在任何一步被中断，都不会导致从头再来。做到这一点，额度够不够用对你来说就只是一件排期问题，而不是一次事故。

• 先估算规模：涉及多少文件、大概几轮交互，再对照自己档位的口径，去 /coding-plans 看对应套餐的额度说明
• 给自己设一个停手点：比如核心逻辑改完就停，把收尾和跑测试留到额度刷新之后
• 把任务切成能独立验收的小块，每块产出写进文件，被挡也不至于全丢
• 开工前确认当前剩余额度和刷新时间，去 /resets 核对，别凭印象安排长任务
• 多人共用账号时，先约定错峰，别默认额度都归你一个人用

停手点的设置有个技巧：设在「一个能独立验证的阶段结束时」，而不是设在「感觉快做完了的时候」。因为感觉不靠谱，独立能验证的阶段是明确的。这样做的好处是，即便被挡，你手上也有一份能交付、能继续的中间状态。

被挡之后的第一分钟做什么

被挡住的那一分钟，处理顺序比处理内容重要。先判断性质，再看数据，最后才决定走哪条路。顺序颠倒了，容易把一次等一会儿就能恢复的限速，当成额度耗尽去折腾。

1. 先看报错措辞区分「额度类」还是「限速类」。限速类等一会儿就能继续，不用换通道也不用等刷新；额度类才需要做后面的决定。
2. 再看剩余与刷新时间去 /resets 与 /codex-radar 核对当前口径和刷新节律，别靠记忆里的印象判断，这两个页面的数字是看当时的。
3. 盘一下已保住的产物按前面那张表过一遍，确认哪些改动还在、哪些中间结果只在对话里，后者优先补落盘。
4. 再决定走哪条路等刷新、降档跑小任务、转按量计费通道继续，三条路的取舍去站内相关页面对照。任务已接近完成时，硬等刷新往往比换通道更省事。
5. 记一笔再继续把这次中断的环节和恢复方式写进日志，下次排期就有依据，不用重新试一遍。

如果你判断是限速而不是额度耗尽，那处理方式完全不同：等一段冷却时间再发就行，不需要换通道，也不需要改任务节奏。把限速误判成额度耗尽，会让你做一堆没必要的迁移动作，反而更慢。

记一份自己的中断日志，下次就有数了

额度数字会变，档位口径也会变，但「什么样的任务大概吃掉多少轮」这种相对量比较耐用。记一份简单的日志，跑几次之后你就能看出自己的任务在哪个规模上容易撞额度，排期和切分就有了依据，不用每次靠运气。

• 记任务类型：是重构、调试还是批量改动，同类任务才好横向比较
• 记起止时间与被中断的环节，重点写「第几轮」而不是「跑多久」
• 记当时提示的措辞，下次一眼就能认出是额度类还是限速类
• 记恢复方式：等刷新、换通道还是重跑，哪种更省事也记下来
• 别只记额度数字，数字会变，记相对量更耐用

这份日志不用写得多正式，五行就够。但要提醒的是，如果你只是偶尔用一次、任务都不长，维护这份日志的意义不大，反而占时间。它适合经常跑长任务、或者团队里负责排期的人。

哪些人需要认真对待这件事

这件事的重要程度，跟你的使用方式强相关，不用所有人都当成大事。判断标准很简单：你的单个任务是不是经常跨很多轮交互。跨得越多，撞上额度边界的概率越高，越值得提前安排。

最后说一句不适用的情况：如果你本来就用按量计费的 API 通道，预算也够，还设了余额告警，那你的重点不该是「会不会突然中止」，而是「告警阈值设得合不合适」。这两件事的应对方式不一样，别把精力放错地方。

额度耗尽这件事，你没法决定它什么时候来，但你能决定它来的时候手上还剩多少能用的东西。