Codex额度掉太快？实测两天找到根源与解决方案

先梳理几个关键现象：近期大量高频用户反馈，Codex 的额度消耗速度出现明显异常。这不是孤立案例，而是广泛蔓延的系统性问题。

Pro 20x 套餐用户最早感知到异常。5.5 版本刚上线时，即便在 xhigh fast 模式下满负荷运行，额度消耗仍在可接受范围内。但大约两周前，情况急转直下——日常使用中消耗量突然加快，更令人困惑的是，电脑处于闲置状态时，每周剩余额度也会在一夜间自动下滑 15% 到 25%。问题在于，工作项目未更换，自动化任务未开启，甚至会话日志中完全查不到任何消耗记录。

官方曾发布过一则“Bug 修复”，但问题并未根除。有用户亲眼目睹剩余额度一夜之间从 76% 暴跌至 51%。

顺着这条线索，有人在 OpenAI 开发者社区中找到了症结所在——Codex 在闲置、未被主动调用时，依然持续消耗额度。类似声音还包括“Codex Credits 凭空消失”“重置后用量异常”，甚至少量任务就能烧掉大量 Credits。这不是大型任务触发的偶发事件，而是系统层面的持续性漏洞。

问题的核心在于：只要 Codex 处于打开或运行状态，Credits 就像水龙头没拧紧一样悄然流失。晚上离开电脑前还正常的额度，第二天一早必定少一截。即便工作流没有实质变化，哪怕仅仅是将其作为家庭监控系统后台运行，这种泄漏依然准时发生。

自 5.5 版本推出以来，无论是每周赠送的额度，还是用户自费购买的额外 Credits，都以快得惊人且难以预测的速度被烧光。额外购买的 Credits 同样“人间蒸发”。一个典型场景：Codex 运行整夜监控任务，早上发现 20% 的 Credits 不翼而飞——而且这种情况每天都在重复上演。

这才是最深层的问题：闲置/后台状态下的额度泄漏。如果 Codex 在后台执行模型调用、重试、总结、监控动作、工具调用或上下文刷新等行为，这些产生计费的动作理应清晰可见、可控。但目前 Codex 提供的信息完全不足以让用户核实额度去向——看不到按任务或按会话拆分的明细，搞不懂为什么仅仅挂着就能烧掉这么多 Credits。

后来，有人找到了突破口：通过查看 ~/.codex/sessions 文件夹里的会话部署日志，可以了解 token 消耗的详细信息，也能发现是否存在后台生成的线程在偷吃额度。

另一位用户的排查过程很有参考价值。他发现 Codex 的内存管理机制是幕后黑手——每次新开 Thread，即便主线程已经结束，额度依然往下掉。那个任务在 5 小时计费窗口里实际只消耗了大约 2% 的额度，但任务完成后，额度却持续下降了 10% 到 12%。打开 .codex 文件夹一看，原来有一些后台线程被悄悄启动了，这直接关联到 Codex 的内存管理。关闭该功能后，问题迎刃而解。

结合这些线索，最终采取了两步操作：

1. 在 /Users/<用户名>/.codex/config.toml 文件中，于 [features] 下设置 memories = false，禁用记忆功能。
2. 让 Codex 找出并终止了三个处于孤立状态的进程——这类进程静默待在后台，看似毫无动作，却可能在持续消耗额度。

刚操作完毕时，效果还不能完全确定。但后续观察显示，可用额度恢复到了两周多前的水平。过去用 5.5 低强度模式开发一小时，大约会吃掉每周额度的 5% 以上；而现在，同一操作只消耗了大约 1%。这不只是巧合，而是问题被准确修复后的正常表现。