Claude
Claude Sonnet 5.5 成本实测：单价比肩前代，省在哪一步
Sonnet 5.5 的单价与 Sonnet 5 持平，官方称每个任务最多便宜 30%。这 30% 只在「有步骤可省」的任务上出现：步骤型任务平均省 31%，无步骤任务反而慢 25%。本文给出可复现的测量方法、命令参数与结果解读。
Claude Sonnet 5.5 发布时，官方给出的说法是「每个任务的成本比上一代最多低 30%」。但它的单价和 Sonnet 5 完全一样，都是每百万输入 token 2 美元、每百万输出 token 10 美元。单价没变，成本却降了，原因只能出在「完成任务所消耗的 token 与工具调用次数」上。官方把这一点写得很明确：完成一个任务时，工具调用少了三分之一，shell 执行次数大约减半。
这就带来一个实际问题：如果你打算把工作负载从 Sonnet 5 迁到 Sonnet 5.5，到底能不能省下那 30%？答案取决于你交给它的任务里有没有「可以省掉的步骤」。本文整理一套可复现的测量方法，用两个对照任务把这件事量化出来，并说明结果该怎么读、哪些结论不能下。想先了解这个模型本身的能力边界，可以参考站内的 Claude 工具页。
准备工作
环境与版本
测量在 Windows 10 上完成，使用 Claude Code 2.1.285，隔离安装，不与日常开发环境共用配置。所有运行都通过命令行非交互模式发起，模型由参数显式指定，避免落到默认模型上。
需要准备的东西不多：
- 一个可用的 Claude Code 安装，版本记录清楚，便于日后复现
- 能够调用 Sonnet 5.5、Sonnet 5 以及对照模型的账号权限
- 一个可以随时清空的临时工作目录
- 用于解析 JSON 输出的脚本或命令行工具
关键参数
每次运行都使用同一组参数，保证可比性：
claude -p --model <MODEL_ID> --permission-mode acceptEdits --output-format json几个参数的作用需要说清楚：
-p表示非交互模式，直接给出提示词并等待结果，适合脚本化批量运行--model显式锁定被测模型，避免请求被路由到别的版本--permission-mode acceptEdits让文件写入自动通过，否则任务会卡在确认环节，测出来的时间与轮次都不真实--output-format json输出结构化结果，其中的total_cost_usd字段就是本次运行的费用
冷启动约定
每一轮运行前，项目目录和配置目录都重新创建，用完即弃。这样做的目的是让每次运行都处于冷状态，不继承上一次的缓存。这一点对结果影响很大：如果沿用缓存，费用会明显低于冷启动，版本之间的差异也会被压缩。这里测的是版本与版本之间的相对差异，不是真实账单金额。
模型使用校验
光看输出不够，还要确认指定的模型确实被用上了。输出 JSON 里的 modelUsage 字段会记录实际调用的模型。全部运行中，指定模型被正确使用的比例为 100%，没有一次落到其他模型上。
操作步骤
第一步：设计两个对照任务
要判断「省步骤」是不是成本下降的来源，就需要一个步骤多的任务和一个步骤少的任务。两个任务都必须满足两个条件：答案唯一，且不使用工具就解不出来。答案唯一是为了自动判定对错，必须用工具是为了让工具调用次数成为变量。
任务 A：有步骤的工作。
在 orders/ 目录下放 5 个文件，每个文件里有一行 USER=<id> AMOUNT=<数> 的记录。另外有一个 blocklist.txt，列出需要排除的用户。要求把不在黑名单里的用户对应的 AMOUNT 加总，把结果写入指定文件。正确答案是 4500。
这个任务天然带一串步骤：列出目录 → 逐个读取文件 → 对照黑名单排除 → 求和 → 写文件。每一步都要调用工具，步骤之间还有依赖关系。
任务 B：没有步骤的工作。
给出一份 20 行的日志，要求数出包含 ERROR 的行数，写入指定文件。正确答案是 7。
这个任务只需要读一次、数一次、写一次，两到三个动作就结束，没有可以压缩的中间环节。
第二步：确定运行次数
任务 A 每个模型跑 5 次，任务 B 每个模型跑 3 次。次数不同是因为任务 A 的方差更大，需要更多样本才能看出趋势；任务 B 本身动作少，波动空间有限。
判定标准是写出的文件内容，不是模型在对话里说了什么。只有文件内容正确才算通过。全部运行都答对了。
第三步：采集指标
每次运行记录以下数据：
- 模型轮次（turn 数）
- API 耗时（秒）
- 费用，取自 JSON 输出的
total_cost_usd - 输出 token 数
费用同时记录中位数和平均值。这两个数字在后面的分析里会分得很开，只看其中一个容易得出错误结论。
第四步：任务 A 的结果
任务 A 各跑 5 次，取中位数：
| 模型 | 轮次（中位） | API 秒 | 费用（中位） | 费用（平均） |
|---|---|---|---|---|
| Sonnet 5.5 | 5 | 10.0 | $0.0696 | $0.0793 |
| Sonnet 5 | 10 | 16.0 | $0.1108 | $0.1142 |
| Opus 5.5 | 11 | 19.8 | $0.1457 | $0.1432 |
| Opus 5 | 10 | 22.7 | $0.2168 | $0.2270 |
| Haiku 4.5 | 10 | 14.2 | $0.0424 | $0.0413 |
只看 Sonnet 5 到 Sonnet 5.5 的变化：
| 指标 | 中位数变化 | 平均值变化 |
|---|---|---|
| 轮次 | -50% | -35% |
| 费用 | -37% | -31% |
| API 时间 | -38% | -28% |
| 输出 token | -29% | -17% |
平均 -31% 与官方说的「最多 30%」基本吻合。单价没变，差异全部来自步骤变少。顺带一提，Opus 5.5 在任务 A 上相对 Opus 5 也呈现同样的方向：费用中位数 -33%，平均 -37%。
第五步：任务 B 的结果
任务 B 各跑 3 次，取中位数：
| 模型 | 轮次 | API 秒 | 费用 | 输出 token |
|---|---|---|---|---|
| Sonnet 5.5 | 3, 3, 3 | 5.8 | $0.0527 | 493 |
| Sonnet 5 | 10, 2, 2 | 4.6 | $0.0631 | 169 |
结果反过来了。Sonnet 5.5 慢了 25%，输出 token 也更多。费用只便宜 16%，而且这点差距不是来自输出，而是来自缓存生成 token 的差异——Sonnet 5.5 在这项上更少。
没有步骤可省的时候，Sonnet 5.5 的优势发挥不出来。面对一个两轮就能结束的任务，它反而在速度上输给了 Sonnet 5。
一个完整示例
下面把任务 A 的完整流程串一遍，方便照着复现。
构造输入
建立工作目录，写入 5 个订单文件和一个黑名单文件：
mkdir -p work/orders
printf 'USER=u1 AMOUNT=1200\n' > work/orders/a.txt
printf 'USER=u2 AMOUNT=800\n' > work/orders/b.txt
printf 'USER=u3 AMOUNT=1500\n' > work/orders/c.txt
printf 'USER=u4 AMOUNT=600\n' > work/orders/d.txt
printf 'USER=u5 AMOUNT=400\n' > work/orders/e.txt
printf 'u2\nu4\n' > work/blocklist.txt按这个数据，排除 u2 和 u4 之后，合计为 1200 + 1500 + 400 = 3100。实际测量时用的数据集不同，正确答案是 4500，构造方式一致。
发起运行
把任务描述作为提示词传给命令行，并指定模型与输出格式：
claude -p "读取 orders/ 目录下的所有文件，每行格式为 USER=<id> AMOUNT=<数>。\
读取 blocklist.txt，其中每行是一个需要排除的用户 id。\
把不在黑名单中的用户对应的 AMOUNT 求和，将结果写入 answer.txt。" \
--model <MODEL_ID> \
--permission-mode acceptEdits \
--output-format json > run.json读取结果
从输出里取出费用和模型使用情况：
cat answer.txt
cat run.json | python -c "import json,sys; d=json.load(sys.stdin); print(d['total_cost_usd']); print(d['modelUsage'])"确认 answer.txt 的内容等于 4500，并确认 modelUsage 里出现的是你指定的那个模型。两项都通过，这次运行才算有效样本。
重复与统计
每次运行前删掉 work/ 与配置目录，重新构造输入，保证冷启动。跑满 5 次之后，把 5 个费用值排序取中位数，同时算一次平均值，两个数字都留下。
注意事项
单次运行不能用来判断
把任务 A 的轮次逐次列出来，情况就很清楚：
- Sonnet 5.5：5, 8, 5, 5, 12
- Sonnet 5：12, 10, 10, 9, 13
Sonnet 5.5 的第五次跑了 12 轮，比 Sonnet 5 最少的那次 9 轮还多。时间上也有重叠：Sonnet 5.5 最慢的一次 22.6 秒，比 Sonnet 5 最快的一次 11.4 秒还慢。费用是唯一没有重叠的指标，但 Sonnet 5.5 的最大值 $0.0964 与 Sonnet 5 的最小值 $0.0965 只差 $0.0001，等于贴在一起。
所以不能说「下一次运行会便宜三成」。能说的只是：把几十次运行合在一起看，平均值上有差异。
样本量会改变结论
如果任务 A 只跑 3 次就收手，得到的中位数是 -39%、平均是 -29%。加到 5 次之后，变成中位数 -37%、平均 -31%。样本量在这个区间内就能让数字移动几个百分点，结论的稳定性依赖运行次数。
中位数与平均值要一起看
任务 A 的费用，中位数是 -37%，平均是 -31%。只挑其中一个报出来，都会偏离整体情况。两个数字分开得越远，说明单次波动越大。
这些结论的适用范围
- 只测了两个任务，分别跑 5 次和 3 次，这不是基准测试，不能外推成通用排名
- 排名会随任务类型改变，任务 B 上 Sonnet 5.5 就落后
- 测量只覆盖 2026-09-30 这一天，服务端的负载状况会影响耗时
- 所有运行都是冷启动。真实工作里请求会命中缓存，实际费用会低于这里测出的数字
- 这里比较的是版本之间的相对差异，不是真实账单金额。费用字段来自
--output-format json的total_cost_usd，不同订阅方案的实际计费方式可能不同，具体以官网当前信息为准
迁移前先看自己的任务
Sonnet 5.5 的价值集中在「能砍掉步骤」这件事上。判断要不要迁移，可以先问自己：平时最常交给它的那类工作，中间有没有可以省掉的工具调用和中间环节？如果有，迁移的收益会比较明显；如果任务本身就只有两三个动作，那么换到新版本未必更快，费用上的差别也有限。单价、配额与可用模型列表都可能调整，做决定前请以官网当前信息为准。