估计不少人和我一样，最近都被 Codex 额度消耗过快的问题困扰着。
我之前用的是 Pro 20x 套餐，流量额度几乎没用完过。5.5 版本刚发布那阵子，我一直在用 5.5 的 xhigh fast 模式拉满，当时感觉很爽，活干得又快又好，额度掉得也不快。
但大约两周前，我发现日常消耗量明显比之前更快。更奇怪的是，即便我完全没碰它，一夜之间每周剩余额度也会下降 15%--25%。我没有变更正在做的项目，也没有设置任何自动化操作，而且会话日志里根本看不到这些消耗记录。
哪怕是在官方号称做了"Bug 修复"之后，这种情况仍在继续。有一回，我的剩余额度一夜之间直接从 76% 掉到了 51%。
为了弄明白到底发生了什么，我偶然看到了 OpenAI 开发者社区的这个帖子（见文末）：
帖子反映的是：Codex 在闲置、没有被主动使用时，也会持续消耗额度。
顺着这条线索，我又搜到了一些相关讨论，比如"Codex Credits 消失"、"重置后 Codex 用量异常"，还有一些报告称，哪怕只是少量任务，也会耗掉大量额度。
就我个人而言，核心问题并不仅仅是某个大型任务吃掉了大量 Credits。关键在于，即使我没有主动开启任何有意义的新工作，只要 Codex 处于打开/运行状态，Credits 就好像一直在默默。
这种情况反复出现。每天晚上，只要我还开着 Codex，额度就会减少，一直持续到现在。每次我离开电脑一段时间再回来，都会发现又有额度凭空消失了。我的工作流和以前相比并没有实质变化，Codex 的使用方式也和之前类似，包括用它来充当我家用系统的监控/监视器。
但自从 5.5 版本推出以来，不管是每周赠送的额度，还是自己另外买的 Credits，都以极快且难以预测的速度被烧光。额度消耗之快，真的吓了我一跳。为了能继续用下去，我开始付费购买额外 Credits，但这些额外购买的Credits也开始以同样诡异的方式消失。
举一个夜间的例子：Codex 照常运行，承担着监控/监管任务，到早上起来一看，大约 20% 的Credits不见了。这绝非个例。每天晚上只要我离开电脑时没关 Codex，都会出现一模一样的情况。
这里最严重的问题，就是闲置/后台状态下的额度泄漏。如果 Codex 在后台执行模型调用、重试、总结、监控动作、工具调用、上下文刷新，或者其他任何不需要我主动操作就会产生计费的行为，那么这些行为都应当清晰可见、可以控制。
目前 Codex 提供的信息完全不足以让我核实这些额度到底花在了哪里。我看不到按任务或按会话拆分的清晰说明，解释为什么在仅仅打开/挂着 Codex 的情况下，Credits 还在持续消耗。
后来，我看到有人给出了解决办法：
可以通过保存在 ~/.codex/sessions 文件夹里的会话部署日志，查看 token 消耗的详细信息，也可以在这里检查是不是有后台生成的线程在消耗额度。
我之前也遇到过类似问题，是由 Codex 的内存管理机制引起的。每次我新开一个 Thread，都会发现即使主线程已经结束，额度仍然在往下掉。那个任务实际上在 5 小时计费窗口里只消耗了大约 2% 的额度，但任务完成后，额度仍然持续下降了 10%--12%。我打开 .codex 文件夹想找到证据，结果发现原来有一些后台线程被悄悄启动了，这和 Codex 的内存管理有关。我把内存管理功能关掉之后，问题就解决了。
他的情况听起来和我的极其相似，他也提到禁用内存功能后问题就消失了。于是，我最终做了两件事，似乎也解决了我的问题：
- 在
/Users/<用户名>/.codex/config.toml文件中，于[features]下面设置memories = false，禁用记忆功能。 - 让 Codex 找出并终止了三个看起来处于孤立状态的 Codex 进程（我主要用命令行，很少用桌面应用，因为它经常卡顿甚至出故障）。这几个进程一直静静待在后台，看似什么也没做，但谁知道呢，说不定它们仍然在以某种方式消耗着额度。
因为这是早上才做的操作，我不敢百分百确定它是否能彻底解决夜间消耗问题，但我确实发现，我的可用额度恢复到了两周多以前的水平。最近用 5.5 低强度（low）模式开发一小时，过去大概会吃掉每周额度的 5% 以上，而现在，我发现只消耗了每周额度的大约 1%。
相关链接：