围绕 GPT-5.6 Sol Max 是否“变笨”的讨论，这两天在 Codex 社区迅速升温。争议的核心，不是模型名称变了，也不是 OpenAI 公开宣布调整了能力边界，而是用户在实际使用中感受到，模型虽然回答更快了，但深度推理的劲头明显弱了。
一支日本市场调研团队在 Reddit 的 r/codex 板块发帖称，他们把 Codex Sol MAX 接入一套自研 CLI 工具，用来处理需要复杂计算和深度推理的任务。按该团队的描述，Codex Sol MAX 过去在这类任务上的表现一直超出预期，面对同一提示词时，经常会花 10 分钟以上反复尝试、反复推理，并多次调用工具，直到结果足够完善。
但在 7 月 15 日当天早上，该团队称模型表现突然下滑。上午 9 点开始工作，到 10 点 40 分，团队成员陆续察觉到同样的问题：模型变快了，却不再愿意往深处挖，原先那种先研究、再动手、边做边自我修正的工作方式，明显减弱。
社区质疑集中在“推理被调低”
这支日本团队的经历并不是个例。根据原文梳理，Codex 社区近几天出现了大量类似反馈，用户的体感高度一致：模型响应更利索了，但深度推理能力似乎被削弱，尤其是在复杂编码、长程任务和需要多轮自我检查的工作中。
这类变化很难直接证明。普通用户无法看到模型权重是否变化，也不知道服务端实际分配了多少算力。能感知到的，只是模型回复速度、思考时长、是否回头检查自己的答案，以及是否会调用其他智能体协同完成任务。
在这种背景下，社区用户开始通过隐藏提示词读取系统配置，试图找出能解释变化的指标。其中，用户 ns123abc 通过一段被称为“模型指纹”的隐藏提示词，读到了一个 OpenAI 从未公开说明过的内部参数：juice。
根据社区此前的观察，Sol 的 Max 档对应的 juice value 为 960；而这一次，用户读到的数值变成了 128，较此前减少近 87%。几乎同一时间，另一组截图也在社区传播，显示 Codex 客户端中用户实际可用的上下文窗口，从约 372k 回退到 272k。
这两个数字很快成为争议焦点。因为在社区看来，哪怕 OpenAI 没有更换模型权重，推理资源预算和上下文窗口的变化，也足以改变用户拿到手的实际体验。
OpenAI 回应：没有“降智”，是在做实验
针对争议，OpenAI 负责 Codex 与 ChatGPT Work 的 Thibault Sottiaux 当晚在 X 上发文回应。他写道：“没有 nerf（降智），只有好事。”
按照 Tibo 的说法，团队的调整主要涉及四点：
- 推理效率优化已经上线，省下的算力会返还给所有订阅用户，仅这一项就能带来大约 10% 的额外用量；
- Sol 的上下文上限此前从 GPT-5.5 的 272k 提升到 372k，但这导致计费消耗高于预期，因此当前已临时退回 272k，接下来几天会重新放出 372k；
- 为了查清新增用量来自哪里，团队做了一些实验，实验中改动了 reasoning effort，也就是内部所说的“juice values”，现在已经改回；
- high 和 xhigh 档位中的多智能体调用高于预期，auto-review 也存在浪费，相关问题正在修复。
这份回应并没有提到模型权重是否发生变化，但明确承认，用户实际拿到的配置在实验期间出现过调整。
“juice”是什么，公开信息仍然有限
在 OpenAI 的公开表述中，用户能直接看到的是推理档位。7 月 9 日 GPT-5.6 发布时，官方称首次引入 max 推理强度，让 Sol 获得最充足的时间进行深度推理；再往上还有 ultra 档，默认拉起 4 个智能体并行工作。
在 ChatGPT 界面里，对应的是模型选择器中的 Medium、High、Extra High 等选项，底层运行的都是 Sol，而 Pro 档运行的是 Sol Pro。
至于 juice value，按照社区目前掌握的信息，它更像是系统内部用于配置推理资源预算的标记。用户平时看不到这个数字，OpenAI 也从未公开过具体取值。
从现有公开讨论看，推理预算下降，并不自动等同于“模型变弱”。但它可能影响模型在一项任务中愿意投入多少资源，包括能探索多少条路线、会比较几轮备选方案、生成代码后是否主动运行测试、失败后愿意回滚多少次，以及一些在高难任务中才会显现的长尾能力。
这也是争议难以被迅速终结的原因。要判断争论双方谁更接近事实，需要一组严格对照实验：使用同一模型快照、同一批任务、同一套工具环境，只改变 juice 这一个变量，再观察复杂编码、长程智能体、数学推理和错误恢复会出现多大差异。原文称，这类证据目前仍然缺席。
用量压力，成为这次实验的直接背景
按照原文梳理，GPT-5.6 上线后，需求迅速放大。OpenAI 一度临时放开五小时窗口的使用限制，以承接明显增加的调用量。
而 GPT-5.6 最吸引用户的几项新特性，本身也都是高消耗配置，包括 Max 档更长时间的思考、Ultra 默认 4 个智能体并行，以及更大的上下文窗口。这些能力都直接推高了 token 消耗。
在这一背景下，Tibo 提到的实验逻辑就比较清楚了：为了排查用量为什么超出预期，先调整推理预算这个变量，看看到底是哪一部分消耗在增加。从工程角度看，这样的做法并不难理解。
但争议也恰恰出在这里。对平台来说，压缩 token 消耗是系统优化；对用户来说，最直接的感受却可能是模型“不肯想了”。而这正是社区此次反应强烈的原因。
争议背后：用户买到的是模型，还是可变配置
这场讨论并不只围绕 GPT-5.6 Sol。原文认为，随着前沿模型从实验室产品逐步走向企业工作流中的基础设施，用户对于“固定智能”的想象正在被打破。
过去，人们更容易把模型理解成一个稳定的能力体：名称相同，能力大致恒定。可从这次事件看，即便模型型号没有变化，平台仍然可以通过推理预算、上下文窗口、多智能体调用策略等参数，改变用户最终拿到的服务配置。
原文将这种关系比作买灯泡：型号固定，但亮度旋钮始终握在平台手里。对于企业用户而言，如果 AI 要成为基础设施，平台最终需要说明的不只是模型名称，还包括用户实际购买的档位到底保证了什么、哪些参数可能动态变化、变化会对任务表现产生什么影响。
截至发稿，围绕 GPT-5.6 Sol Max 的讨论仍在持续。公开可确认的信息包括：社区确实观测到 juice value 从 960 变为 128、上下文窗口从约 372k 回退至 272k；OpenAI 方面则表示，相关改动来自一次排查用量的实验，目前已经改回，并否认这是对模型“降智”。