Claude Opus 5.5 实战：用 effort 分档把成本砍掉 40%

9 月 22 日，Anthropic 发布 Claude Opus 5.5。这不是一次常规的旗舰迭代：它是 Anthropic 呼吁「为前沿进展限速」之后的首个发布，定位是在大多数工作上达到家族顶级水平的同时，把典型工作负载的整体成本压低 40%。发布当天 HN 讨论冲上 1100 分以上，Reuters、各大开发者社区同步刷屏。对每天和 API 账单打交道的工程师来说，真正值得研究的不是又涨了几分基准，而是这代模型把「effort 分档」变成了正式的成本调度手段。这篇文章带你从零开始接入，并把成本优化做进架构里。

先看价格：每百万 token 降了多少

把新旧价格放在一起，降价幅度一目了然：

项目           Opus 5.5     Opus 5     降幅
输入 token      4 美元       5 美元     20%
输出 token      20 美元      25 美元    20%
缓存写入        5 美元       6.25 美元  20%
缓存读取        0.20 美元    0.50 美元  60%

输出价格降 20% 只是表面，真正的杠杆在两处。其一是缓存读取直降 60%，对长上下文应用来说是结构性利好；其二是官方数据声称「典型工作负载整体成本降低 40%」，这个数字包含了每 token 更便宜和每任务消耗更少 token 两层因素。早期客户数据可以佐证：Box 用 5.5 只花了 Opus 5 三分之一的 token 回答同样的问题，Optiver 用大约一半的轮次和输出 token 达到了上一代的质量，成本降 40% 到 50%。

另有一个 Fast mode 可选：输出速度最高提升 2.5 倍，价格变为输入 8 美元、输出 40 美元，在 Claude Code 和平台 API 上都可用。交互式产品值得关注，后台批处理可以无视。

effort 五档：把「思考多少」变成可调参数

Opus 5.5 正式提供五档 effort：low、medium（默认）、high、xhigh、max，配合 adaptive thinking 自适应分配推理预算。这里有一个容易被误读的细节：官方基准榜单上的多数成绩是 max effort 跑出来的（Terminal-Bench 4.0 用的是 xhigh），而 FrontierCode 和 CursorBench 上与竞品对比时引用的是默认 medium effort。也就是说，榜单成绩对应的是这颗引擎火力全开的样子，你按默认档调用时拿到的是另一个性价比画像。

理解这一定位差异，是做好成本分级的起点。先完成一次最基础的调用：

import anthropic

client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,
    effort="medium",
    messages=[
        {"role": "user", "content": "审查这段 SQL 并指出注入风险"}
    ],
)
print(resp.content[0].text)

接入之后，第一件要做的事是给业务任务分档。官方给出的客户数据非常有指导意义：Deloitte 用最低档捕获了 72% 的已知 bug，而 Opus 5 开高档只有 56%；Rogo 用最低档击败了 Opus 5 的高档结果，输出 token 还少了约 60%；Factory 用 medium 匹配 Opus 5 高档表现，输出 token 少 20% 到 25%。这些数字背后的规律很一致——上一代需要开高档才能做好的任务，这一代中低档就够了。

一个可直接落地的分档参考：

low     分类、抽取、格式转换、简单改写、路由判断
medium  常规代码修改、文档生成、单文件审查、问答
high    多文件重构、复杂调试、架构评审、长文档写作
xhigh   疑难 bug 定位、跨系统迁移、安全审计
max     极难问题、基准复现、其他档位反复失败的兜底

比静态分档更省钱的，是「低档起步、失败升级」的级联调度：先按 low 或 medium 发请求，校验输出（测试通过、schema 合法、自评达标）不通过再以高档重试。绝大多数请求会停在低档，长尾难题才触发升级，整体账单远低于全员高档。

缓存重写：60% 降幅改变了什么

缓存读取从 0.5 美元降到 0.2 美元，意味着长上下文场景的成本模型变了。以前「要不要把整个代码库塞进上下文」是一笔要精打细算的账，现在同样的缓存命中成本只有原先的四成。三件事值得立刻做：

第一，重新划分缓存断点。稳定不变的前缀（系统提示、工具定义、领域知识库）放在最前面，享受长周期的缓存读取；把会话历史、动态检索结果放在后段。第二，agent 工作流尽量复用会话前缀，多轮任务里每轮都从同一前缀出发，命中率越高省得越多。第三，给缓存命中和未命中分别埋点，上线一周后看真实命中率，再决定是否值得为提升命中率重构提示词结构。

迁移清单：五个容易踩的点

结合发布说明和平台文档，从 Opus 5 或更早版本迁移时按这份清单过一遍：

1. 模型名换成 claude-opus-5-5，AWS、Google Cloud、Azure 已同步上线，各云渠道命名可能有差异，查对应平台的模型目录。
2. 默认 effort 是 medium。直接原样迁移会觉得「好像没变强」，对质量敏感的任务要显式调高档位——官方在 FrontierCode 上对标时用的就是默认档。
3. thinking 模式不能关闭了。如果你的应用依赖「无思考直出」的低延迟路径，需要改用 low effort 代替，并重新评估延迟预算。
4. 可靠知识截止是 2026 年 6 月，涉及时效性事实的任务要保留检索增强链路。
5. 2026 年 8 月 31 日之后创建的 API 账户默认搭载 preserved thinking 防蒸馏机制；零数据保留可用；输出包含符合 EU AI Act 的水印。合规敏感场景提前核对。

到底值不值得迁移

最后给一个直觉校准。能力侧，Opus 5.5 在 Terminal-Bench 4.0 拿到 66.4%（对比 Opus 5 的 52.3%），FrontierCode v1.1 拿到 54.4%，官方也坦承在这个能力水平上基准分差对实际体验的参考价值在下降。但成本侧的对比是实打实的：早期测试者把 HAProxy 从 C 翻译成 Rust 只用 9.5 小时，比家族顶级模型快 2.5 小时且成本便宜 51%；一个 20 万行的代码库审计修复从 20 多小时压到 3 小时以内。

一句话总结：如果你的场景此前因为 Opus 价格被迫降级到中档模型，现在可以回去了；如果已经在用 Opus 5，迁移几乎是无痛的降本动作。先在测试环境用 medium 档复跑一批真实任务，对比账单和质量曲线，再决定全量切换的节奏。