夜雨聆风你以为你在为一个AI付费，实际上你在养两个。
2026年8月的第一个周末，全球各地的开发者几乎同时按下了同一个动作，打开OpenAI的用量页面。他们看到的东西，让一些人直接从椅子上弹了起来：一条名叫 codex-auto-review 的浅蓝色曲线，像一座拔地而起的山脉，把他们实际使用的模型，sol、terra、luna，全部压成了山脚下的一条细线。
开发者Chris Banes率先晒出分析：95%的turns，都花在了codex-auto-review上。 过去6周，他的账户被吞掉了17.4亿tokens，触发了2.35万次自动审查。而他选用的主力模型gpt-5.6 sol？一天才58次调用旁边那个他从没主动选过的codex-auto-review？一天2195次
▲ Chris Banes的定量帖：auto-review的turns数是主模型的近40倍
越来越多开发者开始集体"对账"
一、第一个冤枉的替罪羊
故事的戏剧性，要从一次误判讲起
8月6日，开发者Rijn在X上怒发一帖："gpt-5.6 sol max烧credits的速度简直疯了。" 他刚充了200美元的订阅，一天下来只剩33%。矛头直指当时最新的旗舰模型，sol max太贵了，OpenAI又在悄悄涨价。
▲ Rijn的第一反应：一定是新模型太烧钱了
评论区里，一个人丢出了一张截图，只说了三个字："This is why."（原因在这。）
▲ Isaac Hinman的截图揭开了额度异动的原因
Rijn愣住了他翻开自己的usage页面，终于看到了那个陌生的名字，codex-auto-review。曲线不会撒谎他一直在为一个自己几乎不知道存在的东西买单。
▲ Rijn跟帖确认："看起来Codex Auto Review一直在吸血"
24小时后，Rijn发出了被广泛转发的纠偏帖：sol max只解释了一部分消耗，额度大头指向一个叫 "Approve for me" 的设置选项。关掉它之后，同样的工作流，credits消耗肉眼可见地放缓了。
这条帖子炸开了锅
二、"替我批准"的甜蜜陷阱
要理解这场风暴，得先搞清楚一个产品设计。
OpenAI的Codex远超普通的聊天补全。它是一个代理式编码助手，能读你的代码仓库、改文件、跑命令、调用外部工具。能力越大，风险越大于是OpenAI给它套了一层沙箱：哪些目录能写、能不能联网、危险命令要不要先问人。
当Codex需要"越界"时，比如访问网络、写工作区以外的文件、执行提权命令，系统会弹出一个审批窗口，问你："允许吗？"
问题来了：这玩意儿弹得太频繁了 跑一个长任务，你可能要点几十上百次"同意"。用户烦得不行，要么索性开Full Access（全部放行，风险自担），要么陷入"确认疲劳"乱点批准。
于是OpenAI在2026年4月推出了一个看起来很体贴的中间选项，Approve for me，中文语境可以理解为 "替我批准"。
名字听起来多温柔：帮我点一下同意按钮嘛。
但它的真实机制是：每当主agent触发一次越界请求，系统不再弹窗给人类，而是召唤另一个独立的AI agent来审查这个请求，决定批准还是拒绝。官方文档把这个机制叫做 Auto-review。
关键来了，这个审查agent会产生额外成本。它是一个完整的模型调用，要读上下文、理解意图、做风险判断。官方文档明确写道：
"Automatic review uses extra model calls, so it can add to Codex usage."（自动审查会使用额外的模型调用，因此可能增加Codex用量。）
▲ 官方文档白纸黑字：auto-review会消耗额外的模型调用
"可能增加"埋在一篇安全配置长文的中段。而设置页面上，你看到的只是一个轻巧的下拉菜单：Ask for approval / Approve for me / Full access。
你以为你打开的是一个便利功能你实际上打开的，是第二台永不下班的计费机器。
三、数字会说话，而数字令人窒息
Chris Banes的帖子带动了全球开发者的"自查运动"。人们翻出本地session记录，让Codex审计自己的transcripts，用产品审计产品。
数字如潮水般涌来：
- Chance Kelch
：6周内，约12,300次auto-review调用，11.7亿tokens - Ben Silver
：单个代码仓库，auto-review占本地token的71%（4.54亿 vs 6.39亿） - TJ Larkin
：近10天约30%的用量在审查路径，最差的一天逼近一半 一位Pro用户晒出单日2638个auto-review turns，苦笑道："200美元的套餐，20美元的体验"
▲ Ben Silver：单仓库71%的token都被auto-review吞掉了
中文社区也没缺席用户Sac搜索后恍然大悟："原来auto-review模式会调用一个独立的agent进行审批，没想到消耗了这么多token……准备切换到full-access看看了😅"
▲ 中文开发者圈的同步讨论：auto-review才是额度消耗飞快的原因
日文用户圈几乎同一时间出现了同样的操作建议，改Full Access后"超改善"。英文、中文、日文，三个语言圈独立复现了同一个结论。
四、安全的中间态，为什么最昂贵
OpenAI的Alignment团队在4月发布Auto-review时，给出过一组很漂亮的内部数据：约1万次动作中，大部分在沙箱内完成，数百次被自动审查；人工打断频率可降到手动模式的约1/200；在这些被审查的动作中，批准率约99%。
听起来完美：安全、省心、高效
但这组数字藏着一个致命的乘法：当主agent的步数从几十涨到成千上万，长会话、多工具调用、频繁撞沙箱边界，审查次数也跟着线性甚至超线性增长。同时，审查agent每次都要读一段对话上下文才能做判断，会话越长，单次审查越贵。
OpenAI Alignment博客里甚至有一句让人倒吸冷气的表述：在内部，Codex Desktop的token用量多数来自Auto-review模式，且占比还在上升。
▲ OpenAI Alignment博客承认：内部Desktop token多数来自Auto-review
这类开销很像一种控制平面税，云计算行业的老朋友了。就像你的健康检查探针有时比业务流量还密集，你的"安检费"有时比"干活的钱"还贵。云厂商的监控开销通常不从业务配额里扣，OpenAI则让审查和主任务共享同一个硬额度。
文档说了但一行埋在安全长文里的提示，和设置页上一枚轻巧的开关，它们的信息权重，完全不在一个量级。
五、三个名字，一场信任危机
事情还有一层令人哭笑不得的混乱：这个功能有至少四套名字。
文档里叫 Auto-review设置界面叫 Approve for me。用量页面叫 codex-auto-review。CLI里叫 --approve-for-me。有开发者专门开了个GitHub issue（#29452），指出文档和应用标签的不一致，建议做一张映射表。
▲ 开发者issue：文档叫Auto-review，应用叫Approve for me，用户一头雾水
当用户在usage页面看到陌生的 codex-auto-review 占了95%的turns，设置里却根本搜不到这个词，信任就在那一刻受损。
Rijn在后续讨论中坦白了自己的安全权衡困境："我一直用Full Access没出过事。后来看到有人说Full Access误删了文件，才改成Approve for me。现在credits被烧光了，只好再冒一次险。"
▲ Rijn的两难：要么当审批按钮员，要么全开权限赌运气
这是一个产品设计的死亡三角：安全、省心、省钱，你只能选两个。而大多数用户，是在第三个选项已经归零之后，才知道自己做过选择。
六、你在为"安全感"付多少钱？
OpenAI的Thomas Ricouard（@Dimillian）在Chris的帖子下回复：已标记，会转团队跟进。但截至讨论高峰期，多位联系客服要求重置额度的用户反馈并不乐观，"对方认为无异常，不给重置"。有人开始降套餐，有人考虑迁出整个生态。
▲ OpenAI侧确认已知晓问题，但用户的退款诉求并不顺利
这场风暴揭开了一个功能的计费逻辑，也带出Agent时代一个更根本的经济学问题：当我们用模型监督模型、用AI审查AI，这层"安全感"本身就是有成本的。人类审批消耗的是注意力，模型审批消耗的是token。Auto-review把成本从你的时间账户，转移到了你的钱包。
而当这个钱包有硬上限、审查又用较强模型、会话又越来越长的时候，那条浅蓝色的曲线，就会像一个沉默的寄生体，在你没注意的时候，把宿主吸干。
如果你正在用Codex，现在就去看一眼你的usage页面。 找到那个叫 codex-auto-review 的条目。如果它比你以为在用的模型还高，你知道该关什么了。