Claude Sonnet 5 发布：标价没涨，账单变量变多了

同样一段英文文本，放到 Claude Sonnet 5 里，token 数可能比 Sonnet 4.6 多四成左右。

这就是这次发布里最容易被忽略的地方。Anthropic 给 Sonnet 5 的标价没有涨，仍是每百万输入 token 3 美元、每百万输出 token 15 美元。但如果 tokenizer 变了，账单就不会只按标价走。

Anthropic 在 6 月 30 日发布 Claude Sonnet 5，官方说法是：性能接近 Claude Opus 4.8，但价格低于 Opus。对普通用户，这听起来是一次能力升级；对调用 Claude API 的团队，问题更具体：能不能迁、怎么迁、迁完贵不贵。

Sonnet 5 的位置：靠近 Opus，但仍是主力档

Sonnet 5 的定位不难理解。它站在 Sonnet 4.6 和 Opus 4.8 之间，继续做 Anthropic 的“主力调用模型”。

Sonnet 通常不是最便宜的那档，也不是旗舰展示肌肉的那档。它更像企业和开发者真正会大量调用的中间层：要有足够强的推理、编码和文档处理能力，也不能让账单失控。

价格也沿着这个逻辑来。Sonnet 5 标价与 Sonnet 4.6 相同：

系统卡里有一段值得留意：Anthropic 称 Sonnet 5 在网络安全任务上显著弱于 Mythos 5，因此采用类似 Opus 4.7 和 Opus 4.8 的安全措施。

这不能被写成“政府已经怎么审批”。目前能稳妥说的是，Anthropic 在公开材料里把模型能力边界和安全分级放在了一起。能力越靠近高风险任务，发布约束越重。这是大模型产品线现在绕不开的现实。

API 迁移：不是把模型名替换掉就完事

Sonnet 5 的开发者文档里，有几处变化会直接影响迁移。

最亮眼的是上下文窗口：100 万 token。最大输出也给到 128,000 token。长文档、代码库、审计报告、客服知识库这类场景，会更容易把材料一次性塞进去。

但控制方式也变了。temperature、top_p、top_k 不再支持。过去靠这些采样参数调风格、调随机性、做 A/B 的团队，需要换一套评估方法。

这里的限制很现实。大上下文能减少切片、检索和摘要链路，但它不会自动让系统更便宜。上下文塞得越多，输入 token 越多。再叠加新的 tokenizer，成本就要重新算。

对 LLM 应用开发者来说，迁移动作应该很具体：拿现有请求日志抽样，重算 token；把原来的参数配置删掉或改写；重新跑一轮质量、延迟、失败率和输出格式测试。

对技术负责人来说，采购节奏可以慢半拍。先把 Sonnet 5 放进灰度池，不要直接替掉 Sonnet 4.6。等真实任务里的单位成本和成功率稳定后，再决定是否扩大调用量。

成本判断：tokenizer 是账单里的暗线

Anthropic 文档写得很直接：同样输入文本，在 Sonnet 5 上产生的 token 数大约比 Sonnet 4.6 多 30%。

这句话比“标价不变”更接近真实账单。API 是按 token 收费的。输入文本被切成更多 token，实际输入成本就会上去。

Simon Willison 用 Claude Token Counter 测了几类样本文档，结果大致如下：

这些数字不能推成所有语言、所有代码库的固定比例。样本文档有限，业务文本也各不相同。

但它已经足够提醒两类团队。

一类是 RAG、客服知识库、合同审阅、研报分析这类长文本应用。它们的成本大头常在输入端。迁移前要用自己的语料重算，而不是用官方标价估算。

另一类是代码助手、代码审查、自动化测试工具。代码库上下文越长，tokenizer 差异越容易放大。过去能接受的“多塞一点上下文”，到 Sonnet 5 上可能要重新设上限。

接下来真正要看三件事。

第一，Anthropic 是否提供更清楚的 tokenizer 迁移工具，让团队能直接用历史日志估算账单。第二，adaptive thinking 默认开启后，在高并发场景下会怎样影响延迟和成本。第三，Sonnet 5 在真实业务任务里和 Opus 4.8 的差距，到底小到什么程度。

如果质量接近 Opus 4.8，而总成本仍低，Sonnet 5 会很快进入主力模型清单。若 tokenizer 带来的涨幅抵消了性能收益，技术负责人就会更倾向灰度、限流和分场景迁移。

回到开头那笔账：标价没涨，只说明价目表没变。开发者真正要付的钱，还藏在 tokenizer、上下文长度和默认 thinking 里。