近期不少 Codex 用户反馈模型像“降智”、响应变慢、额度消耗明显加快。本文把“能力下降、速度变慢、额度变快”三种现象拆开分析，给出可操作的排查清单与省额度的使用习惯，并说明哪些说法只是传闻、需要以官方说明为准。
最近一段时间，关于 Codex 的抱怨集中在三点：模型好像变“笨”了、响应明显变慢、额度掉得飞快。有人早上问一个小问题就吃掉了可观的周额度，有人开着高推理档位去刷了会儿新闻，回来发现 5 小时窗口的额度已经见底。也有人明确表示自己没感觉到任何变化，一直用得很稳。
这些反馈互相矛盾，但并不奇怪——它们很可能说的不是同一件事。把“能力”“速度”“额度”混为一谈，就很难定位问题。下面按这三条线拆开讲，重点放在能自己动手验证的部分。
先分清三种不同的“变差”
| 现象 | 典型描述 | 大致归属 |
|---|---|---|
| 能力下降 | 回答变浅、不复盘、中途转英文 | 模型或路由差异，也可能是提示与上下文问题 |
| 速度变慢 | 首字延迟高、工具调用间隔长 | 服务端负载、网络链路 |
| 额度消耗快 | 同样的问题消耗翻倍 | 档位、fast 模式、子任务、上下文长度 |
三者可能同时出现，但解决方法完全不同。先确认自己遇到的是哪一种，再动手调。
额度消耗快：优先排查这几项
1. fast / 快速模式被默认打开
这是最容易被忽略、影响又最直接的一项。有用户反馈，新建一个工作区后，账号的默认模式被切成了 fast，连原本正常的个人账号也跟着变了。fast 模式的意义是用更多算力换更快响应，代价自然体现在消耗上。
检查动作：在客户端或网页端的模型与模式设置里，确认 fast 开关处于关闭状态；切换账号、切换工作区之后再复查一次，因为默认值可能被重置。
2. 推理档位长期挂在最高
高推理档位适合难题，不适合日常问答。同样一句话，档位越高，模型内部“想”得越久，消耗也越高。如果一直挂在最高档跑小问题，账单自然难看。
建议：日常用中档，遇到确实需要长链推理的任务再临时上调，任务结束调回来。
3. 子代理与并行任务
一个主任务派生出多个子任务时，每一次子任务调用都是一次独立的模型请求。项目里同时开几个任务、每个任务再派生几个子代理，消耗会成倍增长，而不是线性增长。
建议：先确认这个任务是否真的需要并行拆分；不需要时把子代理数量压到最低，或改成串行执行。
4. 会话太长，上下文越滚越大
长会话里，每次请求都要把前面的历史一起带上。对话进行到几十轮之后，哪怕你只问一句“继续”，实际计费的输入也比第一轮大得多。
建议：一个任务告一段落就新开会话，把结论、约定、文件清单整理成简短说明带过去，而不是把所有历史一路拖下去。
5. 提问后离开，任务还在后台跑
有用户描述，提问后去刷新闻，二十分钟回来额度已经没了。Agent 类工具在无人监督时可能持续做工具调用、读文件、重试失败步骤，每一步都在消耗。
建议：发起长任务前先想清楚验收条件；离开前确认任务是否已停止；不确定时先中断，回来再继续。
6. 多项目同时开着
多个项目、多个窗口同时挂着，每个都在产生请求。这类消耗很分散，不容易归因到某一次操作上，但累计起来非常可观。
“降智”到底有没有？怎么自测
目前没有可靠的外部方法能确认服务端是否调整了模型。反馈里既有“完全没区别”的，也有“明显缩水”的，这种分化可能来自账号类型、档位、灰度批次或路由差异，从外部无法验证，也不建议直接归因于某种“风控”。
能做的是自己建立一套可比的基线：
- 准备 5–10 个固定问题，覆盖代码生成、重构、解释、调试四类，难度中等偏上。
- 每次测试前新开会话，清空上下文，使用同一档位、同一模式。
- 记录四项指标：首字延迟、总耗时、输出长度、额度消耗百分比。
- 隔几天重跑一次，横向比较，而不是凭单次体感下结论。
如果输出长度和工具调用次数基本稳定，只是速度变慢，那大概率是链路或负载问题；如果同等任务下消耗明显上升，优先回到上一节排查档位和模式。
至于“开始用英文回答”这类信号，更可能是提示语言、上下文语言或路由策略造成的，单次出现不足以说明问题，需要在固定提示下重复观察。
一套可以直接照做的省额度清单
- 关闭 fast 模式，切换账号或工作区后复查。
- 默认使用中档推理，难题再临时上调。
- 单次会话只做一件事，结束就新开。
- 在项目里放一份说明文件（如 AGENTS.md），写清技术栈、目录结构、代码规范，避免每轮重复解释。
- 限制子代理数量，能串行就不并行。
- 长任务分阶段验收，每阶段结束后总结成几行文字再继续。
- 定期看一眼用量面板，找出消耗异常的时段和任务类型。
环境因素：网络与在线时长
如果任务需要长时间挂机跑，本地机器的休眠、断网、代理抖动都会导致请求中断重试，重试本身就是额外消耗。对需要长时间在线的场景，除了优化本地电源和网络设置，也可以考虑把执行环境放到一台长期在线的机器上，例如整台放在机房、按月租用、通过远程连接使用的 Mac 实例，网络环境相对稳定，也方便持续运行 Claude Code 一类工具。这只是可选方案之一，是否值得取决于任务对在线时长的依赖程度。
关于新版本传闻和账号选择
讨论里出现了不少关于下一个版本上线时间、能力提升、价格下调的说法。这些都没有官方依据，有用户查了预测市场的数据后也认为短期内不太可能落地。版本号、上线时间、定价都请以官方发布渠道为准，不要基于传闻调整工作计划，更不要为了“等新版本”而囤积额度或提前续费。
另外两种情况需要提醒：
- 共享或买卖账号。这类账号的归属和使用条款都存在风险，可能随时失效，数据隔离也难以保证，遇到用量异常时更难判断原因。有多人协作需求时，走官方的团队席位更稳妥。
- 通过非常规手段调整用量限制。这类做法通常违反服务条款，一旦被处理，损失远大于省下的额度。老老实实优化档位和会话结构，收益更确定。
小结
“变笨了”和“额度没了”经常被放在一起说，但前者难以从外部证实，后者却有明确的排查路径。先把 fast 模式、推理档位、子代理数量、会话长度这四项管住，多数人的消耗会有肉眼可见的下降；如果优化之后依然异常，再用固定问题做基线测试，把现象记录清楚，比凭感觉判断更有说服力。至于新版本，把它当成一个可能到来的惊喜就好，不要当成使用计划的前提。