Opus 5.5：Theo 使用新编程模型的第一天

Opus 4.5 改变了我使用编程代理的方式，但后续版本并非都能延续这种体验。我起初喜欢 Opus 5，后来却发现它的文字和代码错误让人难以依赖。使用 Opus 5.5 一天后，我又兴奋起来，但现在下最终结论还太早。

目前它给我的感觉是更便宜、交流更清楚，也更善于遵循指令和编写代码。它能否在我的工作中取代 Fable 仍未知。我想展示让我兴奋的证据和例子，也包括它的弱点。

Anthropic 表示，Opus 5.5 在许多工作中接近 Fable 5.1，并且在默认设置下，典型工作负载的运行成本比 Opus 5 低 40%。公司还提到一位测试者完成了 68 万行代码迁移。这些是公司的说法和案例；实际表现与成本取决于任务。

画面中的发布价格是每百万输入 token 4 美元、每百万输出 token 20 美元、每百万缓存输入 token 0.20 美元。Anthropic 表示缓存读取价格比以前低 60%，输出生成速度快 30% 以上。输出速度更快本身不能决定完整任务的耗时或价格。

我最喜欢的变化是交流方式。Anthropic 表示，他们致力于让解释更清楚自然；我自己也已经注意到差异。重要信息放在前面，让长时间代理任务更容易跟进，但文字清楚并不能证明底层工作正确。

公司挑选的编程基准显示了强劲结果。在 Terminal-Bench 图表中，medium 档的 Opus 5.5 分数超过 max 档的 Fable 5.1，报告成本低得多。但具体基准、推理档位和测试条件都很重要，这些图表不能解决所有实际比较。

其他图表，包括 FrontierCode 和 CursorBench，显示提高推理强度并不总能提高分数。我用 Artificial Analysis 的数据另做了一份可视化，方便比较成本和分数。在画面中的指数里，Opus high 得分高于 Astra high，成本也更高。

在我的初步使用中，medium、high 和 x-high 都有用，而 low 和 max 让我有所顾虑。这是基于有限测试的个人偏好；其他任务或预算可能适合不同设置。

Anthropic 的写作示例涉及一个计费 bug。新版回答先给出发现，再清楚区分免费套餐的影响，以及遗漏了月底最后一天用量的回归问题。我觉得这个解释比旧版容易读得多。

我还讨论了零数据保留选项，认为这可能是企业选择某个模型的原因。能否使用这类选项取决于具体产品、账号和合同；某模型符合条件，不代表每个订阅用户自动享有零保留。组织应核实自己的条款。

一条公开承认前代模型问题的评论，让我觉得公司的交流方式有所改善。我从发布期间的帖子推测其文化更开放，但这只是外部印象，并非经过验证的内部政策变化。

回到基准之前，我展示了第三方的动作游戏演示，还提到另一位开发者报告的缓存改进：在会话中更改推理强度不一定再让缓存提示失效。实际行为取决于相关实现和版本。

在展示的 Artificial Analysis 指数中，Opus 5.5 排名领先，但我也质疑几分的差距在实践中意味着什么。基准汇总的是选定任务的表现，可能掩盖日常编程中真正重要的品质。

输出 token 图表显示了另一项权衡。在比较中，max 档 Opus 5.5 每项指数任务使用近 12 万个输出 token，Opus 5 约为 7.3 万，Astra 约为 2.7 万。如果生成的 token 多得多，即使单个 token 输出更快，任务仍可能耗时更久。

较低价格有助于抵消 token 用量增加。在 max 档，画面中的每项任务成本接近上一代 Opus；medium 或 high 档则低得多。这些是特定指数的成本，不能保证适用于所有工作负载或订阅。

我把成本和分数画成一条前沿曲线，还指出 MiMo V2.6 在较低价格下似乎具有竞争力。这份可视化基于单一数据源的一次快照，应帮助比较档位，而不是充当永恒的排行榜。

Artificial Analysis 将成本没有大幅上涨的很大一部分原因归于输入、输出和缓存读取价格下降。另一位观察者认为 medium 档 Opus 以更低成本达到 Fable 的智能水平；即使测得的价格差距有意思，我仍觉得这一结论超出了证据支持的范围。

我对 max 的不满也来自一次实际运行：一个规划任务循环了六个半小时，我停下时仍只完成一部分。我切换档位并询问状态。一次失败不能证明 max 总是不合适，但说明我为什么更愿意留意长任务。

在我的 Skate Bench 实验中，x-high 每个问题约用 330 个 token，而画面中的 max 运行尚未结束，平均已接近 5000 个。初步分数只提高约一个百分点。对于这次特定测试，我认为额外成本不值得。

我展示了自己在多个账号上高强度使用一天后的订阅面板。扣除此前的 Fable 用量后，我估计其中一个账号约 20% 的每周限制来自 Opus。这只是个人估算，不是保证额度；限制、资格和条款可能变化。

这些工作包括制作基准可视化、将其适配到不同托管位置，并使用浏览器验证。我发现另一个项目有 bug 后，代理找到仓库、更新过时的检出、创建独立 worktree 并准备修复。我说这些任务只占每周额度的一小部分。

就我自己的订阅用量而言，与当天使用的其他选择相比，这个价值很有吸引力。但比较取决于我的工作负载和套餐，不应当作普遍的价格或价值保证。

我还做了一个个人测试，让模型调查大型代码库并提出改进建议。在这个设置中，Grok 4.7 和 OpenAI 模型更深入；根据我的评审设置，Opus 5.5 比 Opus 5 提高很多。我推测了 Grok 表现背后的训练数据，但并不知道实际原因。

深入代码库审计很有用，但我并非每天都做。这揭示了我感受到的 Anthropic 模型相对于部分替代品的一项弱点，不能决定所有编程任务的最佳模型。发现仍需要独立验证。

前端设计方面，情况比较复杂。在使用和不使用设计技能的示例里，许多 Opus 结果在我看来只是尚可。我更喜欢所查看示例中 Fable 的细微布局和动画选择，但这些判断很主观，样本也有限。

其他人的看法不同。Mia 生成了 100 个 HTML 示例，称 Opus 5.5 是她测试过最好的模型；我查看了纸张风格布局、霓虹设计和国际象棋游戏。不同反应说明提示、示例和审美都会影响设计比较。

我展示了其他人的演示，包括把 T3 Code 带进 Minecraft 的集成，以及一系列游戏实验。受 Dark Souls 启发的演示、飞行模拟器和动画片段都是令人印象深刻的原型，但它们不等同于完成的商业游戏。

另一位开发者用 C++ 制作了滑板游戏，也制作了基于浏览器的第一人称演示。我观察到网页示例在某些方面更出色，而模型辅助的电脑操作有时能发现渲染问题。这些例子展示了可能性，并非对引擎或语言的系统比较。

我的 Fish Slop 游戏最初在自己的机器上运行流畅，模型和控制都不错。我后来发现使用的是 medium 推理强度，于是用 x-high 要求模型优化视觉表现。后来的结果建立在先前版本之上，并不是独立的一次生成。

改进后的演示包含鳐鱼、鱼的动画、光照和镜头模式。我尤其惊讶的是，游戏循环让我想继续玩下去，尽管仍能看到光照瑕疵。视频记录的是我对这个特定原型的反应，并非对产品质量的量化结果。

模型仍有一些问题。在一个长时间性能优化任务中，一个代理报告另一个任务接近上下文自动压缩，并警告如果崩溃，未提交的工作可能丢失。考虑到机器和工作流程，我认为警告的部分内容有些混乱，但未提交的工作在不同故障条件下确实可能面临风险。

我推测，早期训练和上下文限制可能解释模型为什么担心自动压缩，但这个例子不能证明其机制。短基准也难以评价长任务及恢复行为，因此我希望取得更多证据后再作宽泛结论。

经过性能优化的游戏在我的演示中运行流畅，但我注意到水面附近有透明度问题。我喜欢这个结果，同时也承认外观精致的演示仍可能存在视觉或功能 bug。

第一天我只检查了大约五个中等规模的拉取请求。我的粗略印象是，与自己的 Fable 示例相比，严重问题相似或更少，轻微问题和细节意见相似或略多。这个样本远远不足以确定可靠的错误率。

我预计偶尔仍会出现糟糕的低谷：任务越长，即使相对可靠的模型也可能陷入不必要的修复，或误解自己的上下文。我不准备仅凭一天的体验就放弃 Fable。模型输出和验证它们的系统仍需审视。

我的初步结论是，对我的订阅用量来说，Opus 5.5 是有价值的日常编程选择，尽管 API 成本和限制有所不同。我也想进一步测试 GPT-6 Sol。竞争格局变化很快，应随着证据积累重新审视选择。