最近两天，OpenAI Codex的用户社区炸开了锅。不少开发者发现，自己明明没怎么使用，订阅额度却以肉眼可见的速度归零。有人五个小时耗尽当日限额，有人一周配额直接跌到1%。社交媒体上充满了抱怨和猜测，甚至有人怀疑OpenAI在暗中削减配额。
事件始末：从“反欺诈”到“缓存问题”
面对汹涌的舆论，OpenAI Codex团队成员Tibo最初回应称，大量受影响用户涉嫌使用sub2api工具将个人订阅转卖为API调用，属于滥用行为，会被反欺诈系统封禁。这一说法立刻激怒了普通开发者——他们花钱订阅，正常写代码，却被当成灰产分子，谁能接受？
舆论失控后，OpenAI迅速改变策略。Tibo宣布Codex活跃用户突破2000万，并向付费用户赠送一次Banked Reset（预存重置额度）作为补偿。但这并没有平息怒火，用户要求公布真实原因。
直到Tibo再次发文，提到“部分用户本周缓存命中率比前几周更差”，才把问题引向技术层面。缓存命中率下降，为什么会导致额度消耗加速？这才是事件的核心。
缓存机制：AI代理的“记忆”如何影响你的钱包
要理解这个问题，先得明白Codex这类编码代理的工作方式。与普通ChatGPT问答不同，Codex在执行任务时会反复调用工具、读取文件、查看报错，每次请求都要携带一个巨大的“背景包”——包括系统指令、工具定义、项目配置、历史对话等，动辄数万甚至几十万Token。
如果每次都让模型从头计算这些内容，不仅速度慢，费用更是天文数字。于是OpenAI引入了Prompt Caching（提示缓存）技术：第一次请求时，模型把长前缀的计算结果存起来；后续请求只要前缀完全一致，就直接复用，只需计算新增部分。在OpenAI的计费模型中，命中缓存的Token成本仅为未命中的10%左右，相当于打一折。
打个比方：正常情况下的AI就像一个记忆力超群的服务员，每次加菜只收新菜的钱；可一旦缓存失效，服务员瞬间失忆，必须把之前上过的所有菜重新做一遍，账单自然暴涨。这就是为什么你只写了几行代码，额度却瞬间见底。
代理系统的脆弱平衡：一个字符就能让缓存全部作废
但缓存为什么会失效？OpenAI官方工程博客曾介绍过Codex的代理循环设计，其中最关键的限制是：缓存必须精确匹配，而且是字节级的“从头匹配”。只要长前缀最前端有任何变动——比如MCP工具列表排序变化、底层模型切换、沙箱环境微调，或者会话过长触发上下文压缩——后面数十万Token的缓存就会全部作废。
这不是第一次出问题。2026年5月，OpenAI就曾因长会话压缩算法破坏缓存命中率，被迫回滚并全员重置限额。2025年8月，Codex团队也通过紧急提升缓存命中率来解决额度过快耗尽的问题。可见，缓存命中率与额度消耗的联动，一直是代理系统的阿喀琉斯之踵。
有趣的是，第三方机构Galileo的实测显示，像Codex和Claude Code这类顶级系统，通过极致的“前缀钉住”设计，缓存命中率可以稳定在91%到92%，每轮交互即使携带7万Token上下文，成本也只有几美分。而一些设计粗糙的竞品，缓存命中率只有20%到50%，虽然发出的Token更少，但因为没有折扣，综合成本反而高出数倍。
这场风波暴露了一个行业趋势：大模型代理的成本竞争，已经从单纯的Token数量转向了“缓存控制力”的竞争。对用户而言，他们买到的不是固定的算力，而是一种依赖缓存命中率的浮动购买力。当AI成为每天并肩作战的同事，提供透明、可查、可追溯的用量仪表盘，就不再是锦上添花，而是维系信任的底线。