小模型档位，正在顶替旗舰

过去处理长周期任务，开发者几乎没有选择，只能上旗舰模型、开最高推理强度——原因在于成本优化型模型在长上下文和工具调用上的差距太大。GPT-5.6 改变了这个格局。在同样的测试框架下，Luna 和 Terra 这两档较小的模型，往往能接近 GPT-5.4、5.5 的表现，价格却低得多。

几个数据很能说明问题。文档智能公司 Hypha 的工程师表示，Luna 在保持 GPT-5.5 约 98% 提取精度的同时，成本只有后者的十八分之一。在 BrowseComp 这项考察冷门事实检索能力的基准上，三个月前 GPT-5.5（超高推理）得分 84.36%、花费 33.27 美元；GPT-5.6 的 Luna（超高推理）得分 84.04%、花费仅 1.33 美元——性能几乎一致，成本差了约 25 倍。浏览器自动化公司 Browser Use 的联合创始人给出的数字更具体：他们用 Luna 跑了 106 个最难的浏览器任务，完成率 78%，总花费约 14 美元；而当前最强模型跑到 80% 要花大约 235 美元。

工程分析平台 PlayerZero 的创始人则报告，在一个关键的代码探索任务上，Luna 把推理成本降低了 64%，响应时间缩短 90%，F1 分数还提升了 5 个点。

推理强度，不是越高越好

指南里另一个反直觉的发现是：降低推理强度，有时反而得到更好的结果。在 Agents' Last Exam 测试中，当测试框架保持不变时，GPT-5.6 的 Sol 档在「低」推理强度下的表现，超过了 GPT-5.5 在「高」推理强度下的表现。生产环境里也有类似反馈——多家初创公司表示，把推理强度从默认值调低后，多种工作流都看到了明显的成本改善。

数据分析公司 Hex 的 AI 研究负责人描述得很形象：把 GPT-5.6 放进现有框架后，低推理强度反而给出了最好的结果——模型知道数据不存在时就停下来，不追错误线索，用更少的 token 得到正确答案。

三个接口原语，把确定性工作交给代码

除了模型本身，OpenAI 还给 Responses API 引入了三个新的架构原语，分别对应智能体工作流里的几类效率问题。

第一是推理复用与原生压缩：通过把推理结果跨模型轮次持久化保存，并对长对话做原生压缩，模型能在更长任务周期内保持连贯，而不必反复重建上下文。在 ARC-AGI-3 基准上，Sol 用标准框架得分 13.3%；开启推理持久化与压缩后，得分跃升至 38.3%，输出 token 只有标准框架的约六分之一。

第二是原生多智能体编排：对可并行的复杂任务，把行动和推理分发给多个智能体并行推进。这也是 ChatGPT 里「ultra」能力设置的运作方式。研究公司 Quadrillion 的创始人评价，GPT-5.6 的 Sol 在开放式研究问题的多智能体协作上表现突出，相比 5.5 有明显提升，完成速度也几乎是最快的。

第三是程序化工具调用：让 GPT-5.6 编写 JavaScript 来编排工具、并行执行独立调用，并在上下文窗口之外处理输出，模型只专注于真正需要判断力的部分。金融研究公司 Rogo 的负责人表示，在评估中，使用程序化工具调用的 GPT-5.6 在质量标准上达到同等水平，同时输入 token 减少了 21%——这正是「能讨论金融研究」和「能真正执行金融研究」之间的区别。

缓存窗口拉长，也能省一笔

在整个 GPT-5.6 模型家族里，提示缓存的存活时间已延长到至少 30 分钟，并且可以在上下文窗口内确定性地设置缓存断点。AI 工程公司 Ploy 的工程师报告，他们在一个共享的 2.9 万 token 提示里加入缓存断点和专属密钥，把未缓存输入减少了 28%；30 分钟的缓存窗口让智能体能在多次运行间复用同一段上下文，而不是每次从头开始。

指南传递的信号很清晰：企业客户对 token 成本的敏感，已经到了必须正面回应的程度。过去那种「每一步都用最强模型」的做法，正在被更精细的分层调度取代。对开发团队而言，真正可操作的做法有两条——把高频、简单的任务下沉到便宜档位，把旗舰留给最难的部分；以及在选型时，用「单位任务成本」而不是「单价」来做横向比较。

来源：OpenAI 官方博客《The builder’s guide to GPT-5.6》