codex额度用完了为什么还在跑

很多人第一次遇到这种情况都会愣一下：界面明明提示额度用完了，正在跑的 Codex 任务却还在继续输出、继续改文件，甚至还接着开下一轮。这篇不解释额度怎么算，而是帮你判断这属于正常的结算延迟、任务已启动的惯性，还是账户已经切到按量计费，并给出照着做就能确认的操作顺序。

很多人第一次遇到这种情况都会愣一下：界面明明提示额度用完了，正在跑的 Codex 任务却还在继续输出、继续改文件，甚至还接着开下一轮。第一反应通常是「这玩意儿是不是在偷偷扣我钱」，然后手忙脚乱去关窗口。其实这里头至少有三种完全不同的原因，处理方式也不一样。

这篇不解释额度怎么算，只帮你判断眼前这个「还在跑」到底属于哪一类：是正常的结算延迟、是任务启动后的惯性、还是账户已经切到按量计费。判断清楚之后再决定停不停、怎么停，比无脑关窗口靠谱得多。

先分清你看到的「还在跑」是哪一种

同样是「额度用完了还在跑」，三种表象的成因差得很远。输出还在滚，说明这一轮会话没被中断；终端里的进程没退，可能是会话收尾、也可能是等网络返回；后台又自动开了新一轮任务，那才是真正值得警惕的信号，代表新请求正在被受理。

还有一个容易忽略的点：额度提示出现在哪个界面。客户端状态栏的数据刷新路径、网页用量页的结算口径、报错弹窗的触发条件，三者不是同一套逻辑，同一时刻显示的内容可能不一致。

这一轮没停

多半是任务惯性，已经启动的会话在自然结束前不会因为额度数字变化被掐断

新请求也被受理

涉及计费状态变化，要么尚未判定超限，要么已经切到按量计费，需要优先确认

提示和用量页对不上

典型的结算延迟，以用量页为准，客户端显示常有滞后

• 看提示出现的界面：状态栏、用量页、报错弹窗三处口径不同，各自的刷新节奏也不一样
• 看是旧会话还是新开的：旧会话跑完是惯性，新一轮被受理才涉及计费
• 看有没有副作用动作：正在批量写文件、跑迁移、发请求的，一律按最坏情况处理
• 记下最后一轮请求的时间戳，后面和用量页对账时用得上

额度、余额、订阅三套口径根本不是一回事

很多人把「额度用完」理解成「账户没钱了」，这是最大的误会。订阅档位的周期额度、账户里的余额、以及按量计费的开关，是三套独立的口径，一个归零不代表另外两个也归零。

额度耗尽后的后续行为，通常有三种：直接拒绝新请求、静默切到按量计费继续跑、或者只降级到低档模型继续服务。具体走哪条路要看套餐页写明的口径，不同档位可能不一样，去 /coding-plans 对应档位页面核对当期规则最稳妥。

为什么用量数字总比你的体感慢半拍

用量统计天生是滞后的。一次请求的执行、用量上报、结算入账是三个分离的步骤，中间隔着网络、批处理和账务周期。长任务尤其明显：任务还在跑，用量还没上报，界面看起来就会「已经超了但还在跑」。

限流判定通常基于一个滚动窗口，看的是窗口期内的历史用量。如果最近这一段还没落账，系统就暂时不认为你超了，于是请求继续被受理。这不是 bug，是绝大多数计量系统的通用做法。

想确认延迟到底有多大，别靠猜。到 /usage 看真实用量榜和结算口径说明，把自己记下的请求时间戳和用量页的更新时间对一遍，差多少心里就有数了。对完之后你会发现，很多「超额还在跑」的现象其实就是这几分钟的时间差。

1. 记录时间点在客户端记下最后一次成功请求的大致时间，精确到分钟即可；有日志的翻日志，没日志的看会话时间戳
2. 打开用量页到 /usage 查看当前周期的用量数字和最近一次更新时间，注意页面上标注的统计口径是实时还是准实时
3. 对比时间差把两个时间点对一遍，差值就是你这边的实际延迟；下次遇到类似情况，先按这个延迟量心算一遍再判断
4. 看结算说明确认用量页写明的结算周期和入账规则，有些是按请求落账，有些是按批次，规则不同延迟表现也不同

任务一旦启动，中途不会因为额度变化被掐断

多数编程类客户端的做法是：把一轮任务当成一个会话，会话内的多步工具调用不会每一步重新校验额度。额度校验发生在会话开始的时候，之后就是「一路跑到底」。所以你会看到额度已用尽，但这一轮还在改文件、还在跑命令，直到会话自然结束才停下来。

这个差异很好用。旧会话还在跑、新会话立刻被拦，基本可以确认是任务快照在起作用；如果新会话也能开起来，那就要往计费状态变化的方向查了。用这一条能在一分钟内把方向定下来。

最需要警惕的情况：静默转成按量计费

有些账户在订阅额度耗尽后会继续服务，费用从余额或者绑定的支付方式走，而界面上不一定有醒目的提示。这就是「静默转按量」，也是大家最容易事后才发现账单变多的原因。

判断线索有几个：额度页的数字不再上涨但账单有新增、出现预扣或冻结记录、收到结算类的邮件或者站内信。三条里中任意一条，就先假定已经走按量计费，按这个前提去核对。

确认之后先别急着停任务，先把结算口径弄清楚，再去 /official-api 对照官方单价，算一下剩下的步骤大概是什么量级，再决定跑完还是中断。判断标准很简单：剩的步骤不多、任务可收尾，跑完通常比中断重来划算。

• 账单页出现订阅之外的新增条目，注意看条目名称和计费周期
• 账户里出现预扣、冻结、待结算这类中间状态记录
• 收到结算提醒类的邮件或站内信，哪怕内容很模糊
• 用量页数字停滞但任务仍在产生实际消耗
• 绑定的支付方式收到小额验证或扣款通知

照着做：四步自查顺序

下面这个顺序是按「先低成本确认、再决定动作」排的。不要跳步，尤其是第三步，很多人忽略账户里还有余额这件事，结果后面看到账单才发现问题。

1. 第一步：确认会话状态在客户端看当前会话是不是仍在活动。是旧会话还是新开的，这一条直接决定后面往哪个方向查。旧会话→惯性；新会话也被受理→查计费
2. 第二步：对时间戳打开用量页，对最后一次用量上报的时间。差得远的说明是结算延迟，先按延迟量再看一遍现象，很多疑问会自己消失
3. 第三步：看账户结构确认账户是纯订阅还是有余额、有没有绑定支付方式。有余额或者有绑定的，先假定会走按量计费，按最坏情况准备
4. 第四步：核对档位规则到 /coding-plans 找到自己当前档位，看页面写明的额度耗尽后行为。确认完再决定是停、是等、还是让它跑完

四步走完，你手上应该有三条信息：是不是旧会话、延迟有多大、会不会走按量。有这三条，停不停就不是拍脑袋了。

停还是让它跑完：三个判断维度

这个问题没有标准答案，但有三个维度可以拿来判断。把三个维度各自过一遍，答案通常就浮出来了，不用纠结太久。

如果你决定算一下按量部分的量级，别凭感觉。回到 /tools/model-cost-calculator 把剩余步骤换算成钱，再和「中断重来的时间成本」比一比，这样判断才有依据。

也有不适用的时候。如果任务是可重跑的、幂等的，那就直接停，没必要为了省一点时间冒计费风险。反过来，如果任务是外部有副作用的、重跑代价很大的，那即使走按量也倾向跑完，但要先把口径记清楚。

停掉之后要做的两件收尾事

停掉任务不是终点。如果什么都不记，下次遇到同样情况你还得重新判断一遍，而且月底对账时会发现有一笔说不清来源的支出。

第一件事，把这次超额的时间、任务类型、消耗量记进自己的用量日志。字段清单可以参考 /usage 的统计口径，照着它的维度记，后面做月度预算时数据能直接对上。第二件事，如果确认走了按量计费，把这一笔单独记下来，和订阅费用分开放，核对时不容易混。

• 记下发生时间，精确到日期即可，方便和账单周期对齐
• 记下任务类型，是代码生成、批量改写还是单纯问答
• 记下当时的档位和是否开启了按量计费
• 记下是主动停的还是自然结束的，这影响你对延迟的判断
• 单独建一个按量支出的记录项，别和订阅混在一起

额度显示是给人看的，计费是按另一套节奏跑的。搞清这两者的时间差，比背任何规则都管用。