OpenAI反击Anthropic：GPT-6.1 Sol性能逼近Opus，价格仅为1/73

一周之内的二次出击

Anthropic发布的Opus 5.5好评如潮，逼得OpenAI在短时间内连续推出GPT-6 Sol和GPT-6 Luna两款模型救场。但据知名技术博主Theo（t3.gg）披露，前两款并不惊艳，真正的杀手锏是随后推出的GPT-6.1 Sol——距离GPT-6 Sol发布仅隔一周。

这种节奏本身就透露了信号。Theo直言，从6.0 Sol到6.1 Sol只间隔一周时间，很难把它当成一次常规的小版本升级。6.1 Sol明显比GPT-6 Sol更聪明，每秒输出的token更慢（通常暗示模型更大），这些迹象都指向一个结论：这不是简单的snapshot更新，而是底层发生了根本性变化。

作为早期测试者，Theo特别声明自己并未收取OpenAI任何报酬，对方只能决定"何时"可以发声，而无法干预"说什么"。他在凌晨两点刚拍完Opus 5.5评测后，紧接着赶制了这期内容，目的就是抢在舆论定调之前给出自己的第一手判断。

真正的杀手锏是价格

6.1 Sol最震撼的地方不在于智能，而在于价格与性能的比值。在Terminal Bench 4这类高难度基准上，它拿到了Theo测试过的state-of-the-art成绩。但更夸张的对比出现在DeepSWE基准：6.1 Sol在Low档位只花21美分，就能拿到与Astra在Low档位花1.46美元、Opus 5.5在Max档位花14.65美元相当的分数。

换算下来，6.1 Sol做到和Opus同样的成绩，成本却便宜了73倍。Theo坦言DeepSWE远非衡量模型实战能力的完美标尺，但"同分且便宜73倍"这件事本身就值得所有人注意。

定价细节更能说明问题。6.1 Sol输入每百万token 2美元、输出10美元，与GPT-6 Sol和Astra持平。但关键在cache read价格——OpenAI破天荒地把缓存读取价格从通常的"正常价10%"降到了5%，也就是每百万0.1美元，相当于把缓存成本砍了一半。由于真实的agentic场景中96%的请求都是缓存读取，这个改动让实际使用成本直线下降。Theo判断，OpenAI几乎肯定是在压缩自己传说中高达95%的利润率。

DeepSWE基准是专门用于评估AI模型在软件工程任务上自主完成能力的测试集，考察模型能否独立完成真实代码仓库中的修复、重构等工作，属于当前最贴近工程实战的基准之一。其"Low/Max档位"指的是模型在解题时允许消耗的最大计算资源（token预算），Low档限制较严、成本更低，Max档则不设上限、允许模型反复尝试，因此Max档得分通常更高但花费也更贵。拿"Low档21美分"对比"Max档14.65美元"意味着6.1 Sol在严格预算约束下就能达到竞品不限资源时的表现，这才是价格优势的实质所在。

agentic场景指AI模型以"代理人"身份自主规划并连续执行多步骤任务，而非单次问答。这类场景会反复读取同一上下文（如长代码库或对话历史），因此缓存命中率极高。OpenAI将缓存读取（cache read）定价从标准价格的10%压缩到5%，在96%请求都走缓存的真实工作流中，相当于整体调用成本再砍近一半，对高频自动化任务的影响远大于对话类使用。

订阅模式的变化与"补贴时代的终结"

与模型发布同步，OpenAI的Thiebaud放出了一长串推文。核心信息有两点：$200的Pro订阅回归，以及用量计算方式的调整——按Theo的测算，新方式相当于把API等值花费砍到旧Pro $200计划的一半。

Theo给出的解读颇具深意。此前在$200的Claude Code订阅上，一个月能跑出8000到9000美元的等值用量，Codex订阅甚至能超过12000美元。为什么OpenAI要在Opus 5.5"好到引发内部code red"的当口收紧补贴？最合理的推断是：新模型即将到来，而它的利润率没那么高，继续以同等力度补贴，用户的电费成本都会超过订阅费。他认为，这可能标志着"补贴时代"开始走向终结。

不再"又聪明又犯蠢"

Astra最让Theo抓狂的问题是"spikiness"——它比Anthropic最强模型更聪明，却会毫无征兆地跌进"最蠢的胡扯"，严重到他几乎弃用。6.1 Sol在这方面改善明显：峰值没有Astra那么惊艳（3D能力不如Astra，多数场景略低于Opus 5.5），但稳定性大幅提升。

Theo举了个极具说服力的例子：他让6.1 Sol翻遍邮件，找出忘记支付或逾期的投资类账单，并在Chrome里为每笔待汇款项建好标签、填好细节，只等他点发送。结果一个都没出错，还主动指出他本会漏掉的项目。"我现在真的把汇钱这件事交给它了"，而Astra因为spikiness他根本不敢托付。其他测试者Julius和Ben的反馈也印证了这一点——Julius称其"incredible"，Ben则说它"incredibly boring"，而对一次模型发布而言，"无聊"恰恰是最好的评价。

Spikiness（尖刺性）是Theo用来描述模型表现方差过大的术语——模型在某些任务上能达到超越同级的水准，但在另一些看似简单的任务上却出现离谱错误，且这种崩溃毫无规律可循。对于需要长时间无人值守运行的agentic工作流而言，spikiness是灾难性的：一次意外的"聪明失误"可能让整个多步骤任务链中途崩溃，造成大量token浪费甚至需要从头重来。这正是为什么"无聊（boring）"在模型评测语境中反而是高度正面的评价——它意味着模型行为可预测、失败模式已知，可以放心托付自动化流程。

效率优势：token用得更省

6.1 Sol不仅token单价低，token利用效率也延续了OpenAI一贯的高水准。在改进T3 code的测试中，它拿到87.4分（Astra 83.8，Grok 4.7 80.7），成本却只有2.15美元，而Opus 5.5要5美元、Sonnet 5.5近9美元。

一个有趣的对照是：6.1 Sol做了三轮工作，总成本还不到Sonnet单轮的一半。原因在于它平均每次请求只读取约11万token，而Sonnet 5需要约36万。更妙的是，Theo让Opus 5.5盲评这款匿名模型，Opus直接判定它是"Frontier tier"，并估价应在每百万输入5美元左右；当被告知真实价格是2美元输入、0.1美元缓存读取时，Opus的回应是"非常激进的定价"，重做测算后发现实际花费只有它原本预估的四分之一。

模型在完成同一任务时消耗的token数量差异，根本原因在于上下文膨胀（context bloat）——部分模型倾向于在每一轮对话中将完整的历史上下文、中间推理链乃至冗余工具调用结果都塞入请求，导致输入token指数级增长。6.1 Sol平均每次请求读取约11万token而Sonnet 5需要约36万，差距超过3倍，这意味着在相同任务复杂度下，前者的有效"智力密度"更高——它用更少的上下文完成了同等质量的工作。对于需要反复调用模型的agentic代码任务，这一差距会随迭代轮次累积放大，最终体现为成本和速度上的双重优势。

短板依旧明显：前端与长任务

6.1 Sol并非没有硬伤。在Theo标志性的"fish slop"（模拟水族游戏）测试里，它把游戏包裹在大量糟糕UI和冗余文字中——"take a breather"之类的废话文案多达二十余处。画面确实精美（鱼和潜艇模型都更出色），但操作手感明显比Opus和Sonnet版本更卡，帧率也更低。Theo直言"这款模型在UI和设计上极其糟糕，毫无品味，还得你自己带审美上场"。

另一个致命短板是长时间无人值守的重写任务。Theo的TypeScript转Rust项目，用Astra和Sol折腾了几个月、烧掉数十万美元token仍停在原地；而Opus 5.5用两个Claude订阅、一个晚上就从头重启并跑通。更戏剧性的是，6.1 Sol事后审计发现，180万行代码里有130万行根本没在用——因为Opus判定其他agent写的全是无法挽救的垃圾，干脆另起一个crate重写。于是只能再让6.1 Sol进来清理Opus没注意到的残留。

最佳用法：审查与调查的"搭档"

Theo的最终结论是组合使用：6.1 Sol在代码审查、深度审计、根因排查上有一种"Rottweiler式"的死咬不放，能挖出Opus和Fable都漏掉的真实bug；而Opus则是更愉快的协作者，实际写码时更少卡壳。他已经在Claude Code配置里让Opus 5.5可以调用6.1 Sol来做调查和审查工作。

他明确表示：这是一款非常好的模型、价格惊人，几乎可以成为很多人的默认编码模型，也让Sonnet对他而言失去了存在意义。但它并没有把Opus 5.5从"日常主力"的位置上拉下来，因此他不会取消任何Claude订阅，只会更多地在Claude Code里调用Codex订阅。

如果你的工作恰好落在6.1 Sol擅长的范围内，几乎可以全程用它；如果不是，继续用Opus，并让Opus在合适的时候调用6.1 Sol，是当前性价比最高的方案。

Claude Code是Anthropic推出的AI编程助手产品，支持在订阅计划下调用多种模型，并允许用户在配置文件（如CLAUDE.md）中预设规则，指定不同子任务由不同模型完成。Theo提到的"在Claude Code里让Opus 5.5调用6.1 Sol"，实际上是利用Claude Code的orchestrator机制：Opus 5.5作为主控模型负责拆解任务、执行编码，遇到需要深度审查或根因排查时，自动将子任务转发给通过Codex订阅接入的6.1 Sol。这种"主写手+精审员"的分工模式，在控制成本的同时最大化利用了两款模型各自的优势区间，也代表了当前多模型协作工作流的一种典型实践范式。