Codex明天可能还会重置，消耗异常终于讲清楚了！
图片加载中…
今天Codex刚重置，负责人Tibo又冒出来说了一句，照现在的仪表盘看，明天可能还有一个新节点可以庆祝，让大家先保管好自己的Codex。
下面马上有人追问，今天不是已经重置了吗？
Tibo回得也很直接。庆祝活动挪到明天了，因为今天的按钮已经按过。
图片加载中…
Tibo长帖里还有一个更大的数字。OpenAI说，这轮问题修完之后，同样一份Codex额度，预计能多用10%—50%。
图片加载中…
我第一反应也是，好家伙，额度涨了？
继续往下看才发现，额度池其实没变。过去Codex在后台白白烧掉了不少，现在只是把漏掉的那部分堵了回来。
我们以为Codex在干活，它有时候是在原地打转
Codex做长任务时，窗口快满了就会把旧对话压短，腾出位置继续干活。
可旧版本收拾得不干净。文字压短了，一些早就用过的图片还留在里面。刚刚腾出来的空间，转眼又被旧图片占满，然后再压一次。
这不是猜的。OpenAI在Codex公开仓库里专门修过这件事，提交说明写得很直白，旧版计算保留内容的预算时，只算了文字，没有把图片算进去。
图片加载中…
经常让Codex看截图、改UI、操作网页的兄dei，额度掉得快，有一部分就烧在这里。修完以后，重度图片用户的整体用量下降了大约10%。
Memory的问题更离谱。有些后台记忆任务会继承错误的Stop Hook。任务已经快做完了，它还在不停问自己，我到底能不能停？
受影响的人不到1%，可OpenAI抓到过一个线程，它把这个问题检查了15000次。
看到15000这个数字，我当时真愣了一下。任务早就卡住了，它还在原地反复检查能不能结束。
OpenAI的GitHub里也有同类用户报告。日志显示，隐藏的memory_consolidation子代理在Stop Hook失败后继续运行，最后吃光了一个5小时额度窗口。
图片加载中…
这张图是用户提交的Issue，能证明现实里出现过同类故障。不到1%和15000次，仍然是Tibo披露的OpenAI内部数据。
Goal也干过差不多的事。任务明明完成了，Goal却没退出。或者工具已经坏了，模型依然不死心，一遍一遍继续调用。
最夸张的案例，一个异常任务就吃掉了15%—70%的周额度。
那些只跑了几个任务、额度却突然少掉一大截的反馈，现在至少能对上一部分原因。
自动化任务有时会跑得比设定频率更勤。子代理没有收到明确要求，也可能换用更强的模型。主任务没开Fast，子代理却跑进了Fast。旧版Computer History还会把已经总结过的电脑操作，再拿回来总结一遍。个别情况下，光这一项一周就能吃掉五分之一的额度。
滚动摘要平均会让每轮Token多出大约1%。MCP有些结果被编码了两遍，工具说明被截断以后，还得重新获取。
一次多1%，你基本没感觉。可一个Agent任务经常会拆成几十次、上百次调用，每一步都漏一点，周额度就这么没了。
Reddit上有位Business Standard用户，从7月29日开始，每5分钟记一次额度，一共留下14744个快照。
他算出来，自己的周有效Token从大约3.23亿掉到了1.73亿，前后少了约46%。
图片加载中…
这是一位用户的短期记录，不能证明OpenAI给所有人统一砍了46%。它能说明的是，用户看得见进度条往下掉，却不知道是哪一个任务花的，主模型花了多少，子代理又花了多少，后台是不是还在偷偷重试。
Codex的公开代码里，图片压缩预算、MCP结果重复编码、子代理模型和速度档位，都能找到对应的修改。
可10%—50%到底怎么算出来的，Computer History最多吃掉五分之一周额度又来自多少用户，OpenAI没有公开样本量和计算方法。
Bug确实修了一批，10%—50%则是OpenAI根据内部数据给出的估算。平时图片多、子代理多、Computer Use多的人，感觉可能会很明显。只跑短任务的人，变化可能没那么大。
这也是我为什么总提ZCode
评论区说ZCode更省上下文，目前没有同项目、同模型的对照数据。我总提它，主要因为它愿意把账摊开。
ZCode的Usage Stats会直接告诉你，当前上下文里消息占多少，MCP工具占多少，系统工具、系统提示词、Skills又各占多少。5小时额度、周额度和工具调用额度，也分开摆在下面。
图片加载中…
看它官方这张示例图，MCP工具占了32%，系统工具占了30.2%，两块加起来已经超过聊天消息。
它把一件事讲明白了，和Agent聊天，占上下文的不只是你打进去的那几句话。
ZCode现在还能连接自定义模型服务，也能直接导入Claude Code和Codex CLI原有的MCP配置。换过去不需要把工具重新配一遍，这点对同时用几套Agent的人挺友好。
Claude Code其实也能把账查得很细。它的官方OpenTelemetry会记录每次请求用了哪个模型，是主线程发的还是子代理发的，子代理是谁拉起来的，跑了Fast还是Normal，用了多少Token，缓存吃了多少，又重试了几次。
只是这套东西更像给公司技术团队准备的。你得自己接监控后台，普通用户打开就能看懂这一点，还是ZCode做得更直接。
Codex也准备补这块了。Tibo在长帖最后说，他们正在做应用内的用量去向展示。这比再送一次重置更重要。
因为今天的重置，过几天总会用完。后台那些压缩、记忆、子代理和工具调用，只要还藏在一根进度条后面，下一次额度掉快了，我们照样不知道该怪任务太重，还是系统又在原地转圈。
以后Codex告诉我额度还剩30%，我希望顺手就能点开看看，哪个任务花了多少，子代理跑了几次，自动化有没有多跑，哪个坏工具重试了几十轮。
再按一次重置，救的是今天。以后不用猜，才是我更想要的惊喜。
谢谢你读我的文章。
如果觉得不错，随手点个赞、在看、转发三连吧🙂
如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章。