以 2026 年 10 月 14 日核验的官方文档为准，Claude Sonnet 5.5 为每百万输入 2.00 美元、每百万输出 10.00 美元；缓存读取每百万 0.10 美元；缓存写入 5 分钟档每百万 2.50 美元、1 小时档每百万 4.00 美元。Anthropic 模型概览
它处在中间价档：输入是轻量档的二十倍，输出是前沿档的一半。这种“输入相对贵、输出更贵”的结构，决定了优化方向。本文只回答一个问题：怎么给 Sonnet 5.5 的调用做成本预算，并把任务放到正确的档位。
一、先看输出占比
Sonnet 5.5 的输入输出比价是 1:5（2 美元对 10 美元）。对成本影响最大的是任务里输出占多大比重。
按官方单价做算术推算（假设算例，非实测）：
| 输入 | 输出 | 无缓存成本 | 输出占比 |
|---|---|---|---|
| 4,000 | 500 | 0.008 + 0.005 = 0.013 美元 | 38% |
| 20,000 | 4,000 | 0.040 + 0.040 = 0.080 美元 | 50% |
| 60,000 | 2,000 | 0.120 + 0.020 = 0.140 美元 | 14% |
第二行说明：输出密集的任务成本容易被输出主导；第三行说明：输入密集的任务成本容易被输入主导。两类任务的优化手段完全不同。
二、输入密集任务：靠缓存
如果任务是“长材料 + 少量输出”，成本主要在输入。缓存读取价格是普通输入的 5%（0.10 对 2.00），价值最大。
让缓存生效：
- 系统说明、规则、工具定义放前缀。
- 前缀逐字节稳定。
- 动态材料放末尾。
- 用用量字段确认命中。
注意缓存写入按普通输入的 1.25 倍（5 分钟档）或 2 倍（1 小时档）计费，只调用一次的任务享受不到缓存价值。
三、输出密集任务：靠规格约束
如果任务是“短输入 + 长输出”，成本主要在输出。优化手段是约束输出的规模与结构：
- 明确要求输出哪些章节。
- 设定合理的长度目标，避免“写满”。
- 用结构化输出替换大段散文。
- 分段生成并复用已确认内容。
输出的每一千 token 都按更贵的档计费，所以输出规格写清楚，比换模型更有效。
四、effort 是被忽略的成本旋钮
官方把 Sonnet 5.5 的默认 effort 设为 high。这意味着：
- 同一段输入，默认会做较多推理。
- 对简单任务，评估下调 effort 是否仍达标。
- 对困难任务，与其在这一档加 effort，不如评估是否该上浮到 Opus。
effort 与模型档位是两个独立的旋钮。 只比较模型单价而不看 effort，很容易得出错误结论。
五、档位迁移：先迁错配的任务
很多团队的浪费不在模型本身，而在档位错配：
- 简单任务跑了中间档 → 应下沉到 Haiku。
- 困难任务跑了中间档 → 应上浮到 Opus。
- 中间任务跑了前沿档 → 应下沉到中间档。
迁移方法：
- 按任务列出当前使用的档位。
- 用样本在三档各跑一遍，记录正确率、延迟、成本。
- 找出“用更低档也能达到同等质量”的任务，降档。
- 找出“用当前档经常出错”的任务，升档。
- 改配置，不改代码。
六、路由规则怎么写
if 出错代价高 or 需要长链条推理:
前沿档（Opus / Fable）
elif 量大 and 判断简单:
轻量档（Haiku）
else:
中间档（Sonnet 5.5）
再叠加两条修正：
- 中间档任务重试率偏高 → 升档。
- 中间档任务重试率很低且质量稳定 → 考虑降档。
七、单位任务成本
中间档的优化目标是单位合格交付成本：
单位任务成本 =
模型调用成本
+ 重试成本
+ 人工校验成本
+ 返工成本
只看单价会得出错误结论：如果因为换到更便宜的档位而增加了重试和人工校验，最终可能更贵。每次迁移档位后，都要重算这个指标。
八、日志要记什么
task_id
task_type
tier # light | mid | heavy | frontier
model
effort
input_tokens
cached_tokens
output_tokens
retry_count
cost_estimate
latency_ms
quality_flag
tier 与 quality_flag 是档位迁移的核心依据：前者说明用了哪一档，后者说明这一档是否够用。effort 则用来解释同一档位内的成本波动。
九、验证与限制
验证建议：
- 用真实样本统计输入/输出 token 分布。
- 记录缓存命中率。
- 统计各档位的重试率与不合格率。
- 对比迁移前后的单位任务成本。
需要明确的限制：
- 本文价格来自 2026 年 10 月 14 日官方文档，属于可变事实。
- 成本数字是假设算例，不是实测。
- 跨平台价格可能不同，需分别核算。
- 质量判断依赖人工标注样本，样本偏差会影响迁移结论。
十、常见误解
- “中间档最不划算”：它覆盖的任务区间最宽。
- “输入便宜输出就便宜”：两者单价相差数倍，占比决定成本。
- “迁移档位只改模型名就行”：还要同步调整提示词、输出规格与校验标准。
- “缓存是自动的”：前缀不稳定时不会命中。
十一、一个可复用的成本表
| 任务 | 条数 | 平均输入 | 平均输出 | 缓存命中率 | 档位 | 直接成本 | 重试率 | 人工成本 | 合计 |
|---|---|---|---|---|---|---|---|---|---|
| 代码审查 | 待填 | 待填 | 待填 | 待填 | mid | 待填 | 待填 | 待填 | 待填 |
| 文档撰写 | 待填 | 待填 | 待填 | 待填 | mid | 待填 | 待填 | 待填 | 待填 |
| 日志分析 | 待填 | 待填 | 待填 | 待填 | mid | 待填 | 待填 | 待填 | 待填 |
填表要点：输出占比高的任务，优化重点在输出规格；输入占比高的任务，优化重点在缓存。
十二、缓存前缀的实操模板
把请求结构固定下来，缓存才稳定命中：
[稳定] 系统说明与角色
[稳定] 工具定义
[稳定] 业务规则与固定示例
[稳定] 输出规格
[动态] 本次材料
[动态] 本次问题
前四段在同一批任务里保持不变，是缓存的价值所在。后两段的顺序也要固定，避免因拼装抖动破坏前缀。上线前用响应里的用量字段确认命中量，不要凭感觉。
十三、批处理与异步
中间档任务常常既有实时也有离线：
- 实时任务：走同步或优先通道，接受较高单价。
- 离线任务：走批处理或队列，降低成本、削峰填谷。
判断标准：实时性要求低的任务进批量，高的走同步。 把所有任务都走同步，往往会因为并发过高触发限流，重试又把成本推上去。
十四、跨厂商对照时看什么
同一价位的中间档不止一家。对照时建议看四项：
- 单位任务成本：完成同一任务的总花费。
- 缓存折扣力度：缓存读取相对普通输入的比例。
- 批处理折扣：是否支持、折扣多少。
- 迁移成本：接口兼容性、现有代码改动量。
单价接近时，后两项往往才是决定性因素。
十五、把成本信号接进运营
建议周度关注：
- 缓存命中率。
- 各档位条数占比。
- 重试率与不合格率。
- 单位合格交付成本。
当缓存命中率下降或重试率上升时，通常意味着提示词结构或任务分布发生了变化，应回到工程侧排查，而不是先换模型。
限制与结论
Claude Sonnet 5.5 的成本由输入输出占比决定：输入密集靠缓存，输出密集靠规格约束；effort 是同一档位内的第三个成本变量。比换模型更重要的，是把任务放到正确的档位。
落地建议是先做一次档位审计，把错配的任务迁移到合适档位，再用单位合格交付成本校验效果，并把 effort 一起纳入评估。价格与档位请在上线前回到官方页面重新核对。