一家公司每月让模型读取 10 亿个输入 token、生成 2 亿个输出 token。若每次请求的提示不超过 10 万 token，账单从 Claude Haiku 4.5 的 2000 美元降到 Haiku 5.5 的 200 美元——前提是两代模型消耗的 token 数相同。
Anthropic 在 10 月 7 日发布 Claude Haiku 5.5，把短请求的输入和输出价格分别从每百万 token 1 美元、5 美元降至 0.10 美元、0.50 美元。公司同时为这款小模型加入可调 effort，并把浏览器操作、短工具调用和子 Agent 列为目标场景。变化不只是“同一种模型更便宜”：当调用成本降到原来的一个数量级，Agent 系统可以把更多步骤交给小模型，但团队必须先判断哪些步骤足够窄、足够可测，失败后又能安全回退。
固定 token 账单下降九成，完成同一任务平均约便宜 75%
Haiku 5.5 的价格分界在单次请求的提示长度。不超过 10 万 token 时，输入、输出、缓存写入和缓存读取均为 Haiku 4.5 的十分之一；超过 10 万 token 后，输入和输出分别升至每百万 token 0.50 美元和 2.50 美元，只比前代低 50%。Anthropic 表示，旧版 Haiku 约 90% 的请求落在短档。
下面按每月 10 亿输入 token、2 亿输出 token 计算，假设所有请求都在短档，缓存命中部分按 cache read 计费，不含首次写入缓存、工具调用、搜索和基础设施费用：
| 模型 | 无缓存命中 | 50% 输入命中缓存 | 90% 输入命中缓存 |
|---|---|---|---|
| Haiku 5.5 | 200 美元 | 155 美元 | 119 美元 |
| Haiku 4.5 | 2000 美元 | 1550 美元 | 1190 美元 |
| Sonnet 5.5 | 4000 美元 | 3050 美元 | 2290 美元 |
这张表只回答“同样数量的计费 token 要多少钱”，不能回答“完成同样工作要多少钱”。Haiku 5.5 使用更新的 tokenizer，同一段文本可能被切成更多 token。Anthropic 把 token 化变化和长短请求分布计入后，给出的平均运行成本降幅是约 75%，不是九成。
Simon Willison 用自己的长提示比较两代 tokenizer，观察到 Haiku 5.5 的 token 数约多 25%。这是单个工作负载的实测，不代表所有文本都会增加相同比例，却说明迁移时不能只把旧用量乘以新单价。团队应重放真实请求，分别记录输入、缓存、思考和可见输出 token，再计算每个成功任务的成本。
effort 让一款模型覆盖多档成本，也把选择权交给路由器
Haiku 5.5 首次在 Haiku 系列中提供 low、medium、high、xhigh 和 max 五档 effort，默认是 medium。effort 不只是控制隐藏推理；它还会改变回答、工具参数和工具调用所消耗的输出 token。更高档位通常换来更强能力，也增加延迟与账单。
系统卡中的 Humanity’s Last Exam 无工具测试展示了这种曲线：Haiku 5.5 从 low 的 30.9% 升至 max 的 45.9%，单题公布成本则从不到 0.005 美元升到约 0.20 美元。默认 medium 得分 35.5%。因此“Haiku 每百万输出 token 0.50 美元”并不等于每项任务都很便宜；如果路由器把大量简单任务一律设为 max，低单价仍会被更长输出和更多步骤抵消。
更可操作的做法是按失败代价分层。分类、抽取、压缩上下文、查一份文件中的确定字段，可以先用 low 或 medium；需要多步搜索、严格遵循长指令的任务，再升到 high。只有内部评测显示 xhigh 或 max 的质量增益大于新增成本时，才继续上调。对不能容忍漏检或错误执行的步骤，模型置信表达不能替代独立校验与回退规则。
它已经能操作电脑，但“72.4%”不是完整任务成功率
Haiku 5.5 的能力提升让这种分层成为可能。Anthropic 在 OSWorld 2.1 的 82 个离线任务上，以 max effort、每题五次运行测试模型操作 Ubuntu 桌面的表现。Haiku 5.5 的部分得分为 72.4%，严格完成全部检查点的通过率为 37.1%；同条件重测的 Sonnet 5.5 分别为 83.9% 和 48.8%。把 72.4% 写成“电脑任务成功率”会高估模型的端到端可靠性。
复杂编码的差距更明显。Terminal-Bench 4.0 包含 66 个容器化命令行任务，Haiku 5.5 在 max effort、无联网且启用安全措施的 660 次试验中得到 39.2%；Sonnet 5.5 为 70.6%。Haiku 有 1.8% 的试验因安全措施触发而直接失败，Sonnet 的部分请求则可转交后备模型，二者运行方式并非完全相同。这个结果足以支持“Haiku 比前代可承担更多 Agent 步骤”，不足以支持它替代 Sonnet 处理长链条、复杂编码。
官方列出的早期客户案例也集中在可切分任务：从文档抽取特定财务数字、摘要、快速查找和子 Agent。AlphaSense 称其文档问答每周约有 800 万次调用，并用 400 条查询比较新旧 Haiku；Rogo 描述的流程则由大模型制作演示文稿，让 Haiku 子 Agent 去 10-K 文件中找分部收入。这些是公司发布页中的客户自报结果，提示了适用形态，但没有公开完整提示词、失败样本和生产审计。
高频 Agent 的新门槛是可评测的任务拆分
Haiku 5.5 没有让模型选择变得不重要，反而让路由错误更容易被规模放大。一个窄任务若有明确输入、机器可检查的输出和低成本回退，小模型的十倍单价差可以迅速累积成预算优势；一个边界模糊、失败后果高、需要长上下文反复行动的任务，即使单次调用便宜，也可能因重试、人工复核和错误执行吞掉节省的费用。
因此，迁移不应从“把现有 Sonnet 调用全部换成 Haiku”开始，而应先建立三组指标：每类任务的成功率与严重错误率、不同 effort 下的 token 与延迟分布、升级到 Sonnet 后挽回了多少失败。然后只把质量达到门槛的窄任务下放，并保留按复杂度、上下文长度和失败代价升级的路径。
这次降价真正改变的是实验的起点。过去团队可能因为调用太贵而不让 Agent 高频运行；现在，短请求的基础账单低到足以大规模尝试。接下来决定系统是否可靠、是否真的省钱的，不再只是模型单价，而是团队能否把工作拆成可测步骤，并让每一步购买恰好够用的推理。
