GPT-5.6 比 Claude 贵 50%？他们查完发现锅在自己

OpenAI 发布 GPT-5.6 的当天早上，一家叫 Ploy 的公司把自家生产环境 agent 的默认模型换了。不是内部灰度，不是小流量试水，是所有客户工作区的默认模型，从 Claude Opus 4.8 直接切到 GPT-5.6 Sol。

Ploy 是做营销网站自动化的，他们的 agent 干的是真活，规划页面、读代码库、写组件、生成配图、给自己的成品截图、自己判断做完没有。过去四个月这个默认位一直是 Claude Opus 的，先是 4.7 再是 4.8，每个新模型出来他们都拉去打一轮，没有一个打得过。GPT-5.6 是第一个。

这也不是孤例。GPT-5.6 发布这 48 小时，Codex 那边临时取消了 5 小时用量限制，X 上已经有人在传把 Claude Code 后端换成 GPT-5.6 Sol 的配置方法，一场换模型的小型迁徙正在进行。热闹归热闹，大多数帖子停留在跑分截图。Ploy 不一样，他们把整个迁移过程原原本本写成了一篇博客，我读完的感受是，这可能是今年公开资料里最扎实的一篇模型迁移实录。数据只是开胃菜，真正值钱的是他们踩的四个坑，每一个都指向同一件事，你以为你在换模型，其实是在给整个技术栈做体检。

先把开胃菜端上来。同一套重设计任务，agent 对照参考稿重建品牌首页，两边平均成绩，

每次完成构建的均值	Claude Opus 4.8	GPT-5.6 Sol
成本	$3.06	$2.22
耗时	8 分 00 秒	3 分 42 秒
输入 token	2.60M	1.70M
输出 token	33.0K	17.1K
视觉得分	0.936	0.970

快 2.2 倍，便宜 27%，视觉得分还更高。代码风格的差异更有意思，同一个页面，Opus 写了 17957 字符的 globals.css，174 个 CSS 变量，完整色阶铺满，大部分压根用不上。GPT-5.6 写了 2508 字符，45 个变量，渲染出来的页面不相上下，有时还更好。

这组数字够别的号写一篇《GPT-5.6 碾压 Claude》了。但 Ploy 自己的笔墨，八成花在另一件事上，这些数字差点没测出来，因为他们自己的评测在撒谎。

先修尺子，再谈换模型

我日常的工作就是 AI harness，用人话讲，给大模型搭脚手架，工具链、评测、调度、上下文管理，让模型真正能干活的那层工程。所以读到他们的第 0 步时我是会心一笑的，这些坑的形状我太熟了。

Ploy 的评测跑的是真 agent 加真实工作区的副本，几百个用例，从「从零建一个首页」到「这个克隆请求能不能安全执行」。构建类用例由一个视觉裁判打分，对着参考设计做十个是否判断，比如「hero 区是不是全幅摄影场景」「主按钮是不是圆角矩形而不是胶囊」，另外还有内容检查、工具轨迹检查、文件断言。最要紧的是，每个失败用例都要对着完整 trace 归因，看真实的工具调用和模型输出，不是只看一个分数。

就这么一套算得上讲究的评测，跨模型一跑，暴露出一个扎心的事实。

你的评测早就被调成偏心现任模型的样子了，你自己不知道。

工具调用预算是按 Opus 的串行习惯设的，GPT-5.6 喜欢并行扇出，一把调用同时撒出去，题目明明做对了，预算先爆了。评测执行器不支持批量读文件，Opus 几乎不用这个姿势，GPT-5.6 天天用。第一轮跨模型评测里，大约三分之一的失败，追到根上是评测框架的假设错了，不是模型错了。而且这些冤案不是均匀分布的，全压在新模型头上。

三分之一。你敢信。

还有个更阴间的细节。某个数据集漏配了及格线，静默继承默认值 1.0，等于满分才算过。GPT-5.6 一个拿了 0.98 的 hero 区被判死刑，Opus 也有一个每项检查全过的用例莫名其妙挂了。两种都站得住的设计方向，一起输给一个看不见的阈值。

所以他们的第一条经验，建议做 agent 的朋友抄在手边，先归因 trace，再相信通过率。不然你评的不是新模型行不行，是新模型模仿旧模型像不像。

25 个参数全填满的模型

尺子修直了，接下来是那个在暗处污染结果最久的坑。

Ploy 的 agent 有个 code 工具，25 个顶层参数，1 个必填，24 个可选。Claude 的习惯是用哪个填哪个，一般带两三个。GPT-5.6 呢，25 个全填，每次都是，用不到的参数就现编一个看起来合理的值，offset 编个 0，timeout 编个 120000，siteId 编一串全零的 UUID。

好家伙，三天生产日志拉出来，GPT-5.6 的 6635 次读文件调用，6635 次带满全部 25 个参数，100%。同期 Opus 4.8 是 0.1%，Sonnet 5 是 0。

麻烦不在啰嗦，在于编出来的值和真想传的值长得一模一样。offset 是 0，看着就像人家真想从头读。文件读取的实现把它当真参数用了，于是 GPT-5.6 的文件读取有 52% 到 64% 返回空内容，而工具两种情况都返回 success true。模型不知道自己在读空气，只觉得这活越干越费劲，就再多调几次。评测分数掉了，账单还涨了，两头挨打。

你以为提示词能救？他们全试了。工具描述里写明不用的参数请省略，没用，还是 25 个全带。每个参数上挂「可选，不用就别传」，没用。OpenAI 官方的 strict 模式，实测行为一模一样，而且开它还得把 schema 里的 pattern、format、数组边界校验全剥掉。这个行为是烙在模型生成函数调用的方式里的，指令改不动，只能绕着设计。

真正管用的修法，我觉得有点子牛逼。在供应商边界做一层 schema 变换，只对 OpenAI 系模型生效，把每个可选参数重写成必填但可空，类型上接一个 null 分支，等于给模型一个正大光明说「这个我不用」的出口。然后在所有工具调用都会路过的那一个入口，把 null 剥掉再进校验。工具的实现，一行不用改。

效果，空读从 52% 降到 0，同样的活工具调用少了 30%，因为它不再反复重读那些空气文件。

这段我来回读了几遍。它示范了跟模型怪癖相处的正确姿势，不是骂模型笨，也不是堆提示词祈祷，是在边界上给它一个能诚实表达的结构。提示词管不了的事，schema 管得了。

同一个词，两套缓存

第三个坑最贵。动手修之前，GPT-5.6 在他们的账单上看起来比 Opus 贵 50%。

对，就是标题那个 50%。不是 OpenAI 定价的问题，是缓存配置的问题。

他们 agent 的 prompt 开头有一段约 29K token 的静态前缀，工具 schema 加核心系统提示词，每个会话都一样。在 Claude 这边，用 cache_control 标记几个断点，这段前缀就在整个组织范围内共享缓存，任何会话任何客户，一个共享条目，命中率常年 92% 到 96%，基本不用想它的存在。

GPT-5.6 把 OpenAI 自家的缓存机制也换了。老 GPT 靠部分前缀匹配做隐式缓存，白拿不错的命中率，GPT-5.6 取消了部分前缀匹配，隐式缓存只按最新消息给整条 prompt 建条目。一个新会话，哪怕跟别的会话共享那 29K 前缀，命中 0%。每个会话都按原价重付一遍前缀，而且每个未命中的 prompt 还要交 1.25 倍的缓存写入附加费，不管你用没用缓存。

官方给的正确姿势是显式断点，外加一个必填的 prompt_cache_key，而这个 key 本身就是缓存身份的一部分。相同的 prompt，不同的 key，零命中。每个 key 背后是一个缓存节点，单节点大约每分钟扛 15 个请求，超了就把流量扇去其它节点，而那些节点的缓存是冷的。

于是「把缓存打开」变成了一道真正的架构题，key 按什么实体划分。按会话分，新会话永远命中不了共享前缀，首调命中率 0%，他们实测过这个错误，原话是，很贵。全局一个 key，生产流量把每分钟 15 个请求的预算秒穿，请求全溢到冷节点，又回到全 miss。按客户工作区分，甜点位，同一工作区的会话共享条目，单 key 流量又不高。

他们最后按工作区分 key，再把系统提示词拆成三层带断点的结构。第一层是工具加静态前缀，让每个新会话的首次调用变便宜。第二层加上工作区上下文，还能自愈，工作区记忆一变，这层 miss 掉，但第一层还在，补一次小的写入就好，不用 29K 全额重付。第三层是会话内的隐式整链，因为他们的 prompt 严格只追加，这层天然工作正常。

改完的数字，首次调用命中率从 0% 升到 83.7%，未缓存输入 token 总量降 28%，GPT-5.6 的整套评测成本落到了 Opus 之下。之前账单上那 50% 的差价，每一分都是配置的锅。

Ploy 这段的收尾我想原样递给你。如果你在对比两个模型的成本，而其中一个的缓存是冷的，你比的是你的配置，不是模型。

还有个小尾巴。GPT-5.6 的 Responses API 默认把前几轮的推理内容存在服务端，回放时只传一个引用，结果他们的线上会话开始间歇性报错，rs 开头的条目找不到了。修法一行，store 设为 false，SDK 就会改用加密的自包含推理内容回放。附赠一个花掉他们一下午的教训，只要服务端状态还在环路里，你发出去的字节一个没动，有效 prompt 也可能在你看不见的上游被改变。

能抄的作业

四个坑讲完，回到开头那个问题，为什么这家公司敢在模型发布当天就换生产主力。

坦率讲，答案朴素得有点让人失落。不是胆子大，是三样东西早就攥在自己手里了。

一套跑真实任务、能归因到 trace 的评测。几百个从生产里长出来的用例，一个能对照参考稿打分的裁判，新模型发布 48 小时内就能知道值不值得迁、坑在哪。这套东西不属于任何一家模型厂，模型随便换，尺子永远是你的。素材薄的团队也别慌，从十个用例起步就行，重点是每个失败都能看到完整 trace，而不是只有一个红叉。

一个所有工具调用都必须路过的边界层。参数造假那个修法之所以优雅，前提是他们的架构里真的存在「那一个入口」。schema 变换、null 剥离、供应商差异适配，全都收在一个地方。如果你的工具调用散落在二十个文件里各自解析参数，同样的修法你得改二十遍，还保证漏一遍。

一个把供应商差异当架构决策的习惯。缓存 key 按什么划分，推理状态存在谁那边，这些问题在官方文档里各占一行，在生产账单上全是真金白银。用了 Vercel AI SDK 这种通用层，改个模型名确实一行代码，但那只对 demo 成立。生产系统里，「模型」这个词还包括它填参数的手癖，它缓存的脾气，它回放推理的方式，这些都不写在模型卡里。

我一直觉得，评价一个 agent 团队的工程水位，不看它现在用的是哪个模型，看它换一次模型要花多少天。Ploy 交出的答案是两天，外加四个修完之后系统反而更结实的坑。

模型这东西，越来越像洋流，方向说变就变，力气一个比一个大。你拦不住它变，也不用拦。能攥在手里的是自己的海图，评测是海图，边界层是船舵。洋流一转向，有海图的船改个帆就走，没海图的船，只能在原地打转，等下一波浪替自己做决定。