Anthropic 在 9 月 28 日发布了 Claude Sonnet 5.5。官方给出的卖点很直接相比 Sonnet 5新模型快了 30% 以上多数工作成本最高可降低 30%。这两个数字足够让开发者重新看一遍自己的模型配置但真正需要注意的并不只是价格表上的变化。如果应用已经接入 Claude API或者把 Claude 放进了工具调用、代码 Agent 和长上下文工作流直接把模型名换成claude-sonnet-5-5并不一定结束迁移。thinking 的设置方式、强制工具调用、thinking blocks 的处理方式甚至 computer-use 工具的版本都可能影响原来的请求。图 1Anthropic 官方发布帖中的 Claude Sonnet 5.5 速度与成本表述。来源Anthropic Claude 官方 X。先把这个模型的基本信息对上Release Notes 显示Claude Sonnet 5.5 的模型 ID 是claude-sonnet-5-5发布日期为 2026 年 9 月 28 日。官方列出的接入方向包括 Claude API、Amazon Bedrock、Claude Platform on AWS、Google Cloud 和 Microsoft Foundry。这个列表说明产品已经覆盖这些平台具体能否调用仍要看地区、账户权限和服务目录不能把平台名称直接等同于所有环境都已同步开放。模型详情页给出的参数更适合用来做迁移前基线默认上下文窗口为 1M token最大输出为 128K token输入价格为每百万 token 2 美元输出价格为每百万 token 10 美元。页面还列出了 5 分钟缓存写入、1 小时缓存写入和缓存读取的价格。对长上下文应用来说缓存字段和输出上限同样会影响预算不能只盯着输入单价。图 2Claude Sonnet 5.5 模型页中的参数和迁移提醒。来源Claude Sonnet 5.5 模型详情页。它的定位是把能力和成本重新组合Anthropic 对 Sonnet 5.5 的定位不是单纯追求最高能力而是把它放在速度、智能和成本的交叉位置上。官方介绍页把它称为更快、更低成本的 Sonnet 5 升级也将它作为 Opus 5.5 的补充。换句话说它更像是一个适合频繁调用的工作档位而不是只在最复杂任务上偶尔启用的旗舰档位。官方展示的评测覆盖了 Agentic coding、Knowledge work、Computer use 和 Visual chart recognition 等任务。比如编程和知识工作数据说明 Anthropic 希望开发者把它用于持续执行、多步判断和较长上下文的工作流计算机使用与图表识别数据则展示了它在工具和视觉输入上的覆盖范围。这些数字是 Anthropic 自己的评测结果能够说明官方如何定位模型但不能直接替代某个团队的业务验收。图 3Anthropic 官方基准对比覆盖编程、知识工作、计算机使用和视觉图表识别。来源Anthropic Claude 官方 X。另一个容易被忽略的变量是 effort。模型页面默认开启 adaptive thinking默认 effort 为 high官方成本图也显示同一个模型在不同思考深度下任务得分和单次成本会一起变化。因此比较模型时不能只看每百万 token 的价格。一个模型单价更低如果为了完成同一任务消耗了更多输出 token 或更高的思考预算实际成本未必按比例下降。图 4Anthropic 按 effort 展示知识工作得分与成本关系。来源Anthropic Claude 官方 X。迁移时四个 API 细节比模型名更重要第一是 thinking 设置。Sonnet 5.5 默认使用 adaptive thinking如果原来的请求显式发送thinking: {type:disabled}迁移后需要改为thinking: {type:between_tools}这是该模型支持的最低思考设置。已经用参数控制延迟或输出形态的应用应该先搜索代码中的 thinking 配置再重新记录 token 消耗和响应时间。第二是强制工具调用。官方迁移文档明确说明tool_choice的any和tool在 Sonnet 5.5 上会返回 400。原来要求模型必须调用某个工具的流程不能只替换模型 ID可以按迁移建议使用auto再结合 strict tool use 或结构化输出约束工具参数并重新验证模型是否在正确的时机调用工具。第三是 thinking blocks 与模型、会话的绑定。工具调用之间的文本可能以 thinking block 返回应用如果把历史消息保存下来重新播放或者在工具循环中自行筛选消息就需要检查这些 block 是否被完整保留。只测试一次普通问答很难发现这种问题。第四是 computer-use 工具的变化。在 Claude API 和 Google Cloud 上旧的computer_20251124工具不再接受需要按对应渠道文档改用新的 toolset。对于已经接入计算机操作的 Agent这属于请求校验阶段就可能暴露的兼容问题。这些变化在 What’s new 和 迁移指南 中都有明确说明。它们共同指向一个事实模型升级的检查重点不只是一串新的模型 ID。官方价格之外还要看实际 API 服务官方模型页提供的是模型本身的定价基线。真正接入时还需要确认目标 API 服务展示的模型 SKU、输入和输出价格、缓存计费单位以及当前服务状态。同一个模型通过不同服务调用时价格字段和可用条件可能并不完全相同。图 5OkenAI 模型详情页中的 Claude Sonnet 5.5 服务价格与接入信息。来源OkenAI这类核对以前往往要在不同页面之间来回查找先确认模型是否收录再对照输入、输出和缓存价格最后检查当前服务是否有可用状态。OkenAI 的模型详情页把这些字段放在同一处适合用来完成第一轮筛选和价格核对。页面展示的是当前服务数据不等于最终业务账单也不替代真实任务的稳定性和质量验收。迁移前先做一轮最小验证不必一开始就重做整套系统。可以先用同一个固定任务分别调用旧模型和 Sonnet 5.5记录输入、输出和缓存 token再分别测试普通回答、thinking、工具调用和流式输出观察响应结构、错误码和耗时是否发生变化。最后把任务完成情况和实际成本放在一起比较再决定直接迁移、灰度并行还是继续观察。这样看 Claude Sonnet 5.5它的吸引力确实来自速度、价格和长上下文能力的组合。但要不要迁移不能只看发布页上的一句“更快”或“更便宜”。先用官方文档确认兼容点再用 OkenAI 核对目标模型的服务价格和状态最后拿自己的固定任务复测模型升级才会变成一次有数据依据的接入决策。