Haiku 5.5：便宜的小模型能在哪些方面帮助编程智能体

Anthropic 擅长制作大型编程模型，但我一直对它的小模型感到失望。Haiku 4.5 的能力不配它的价格，我甚至配置工具避开它。Haiku 5.5 改变了这一局面：它看起来速度快、价格低，可能适合承担大模型周边的工作。

我想要一个小模型，让其他智能体调用它搜索文件、检查修改和处理重复工作，而不必付出前沿模型的价格。以前我有时会把这些任务交给 OpenAI 的模型。我很高兴看到 Anthropic 自己的模型家族中终于可能有了合适的选择。

Anthropic 将 Haiku 5.5 定位于高频、成本敏感的任务，例如摘要、上下文压缩、数据库查询和分类，也可作为编程子智能体。公告称平均运行成本比 Haiku 4.5 低约 75%；实际节省取决于工作负载和价格档位。

此次发布还将 Sonnet 5.5 的缓存读取价格从每百万 token 0.20 美元降至 0.10 美元。这对我很重要，因为缓存上下文可能占智能体工作负载账单的很大一部分。只比较输入和输出价格可能会忽略这一成本。

对于不超过 10 万 token 的 Haiku 5.5 提示词，画面显示的每百万 token API 价格分别是：缓存读取 0.01 美元、缓存写入 0.125 美元、输入 0.10 美元、输出 0.50 美元。这些是发布时展示的价格，缓存写入费率还应结合供应商适用的缓存条款理解。

当提示词超过 10 万 token，画面中的费率上涨五倍：每百万输入 token 为 0.50 美元，输出为 2.50 美元，缓存费率也随之上涨。对长时间运行的编程智能体来说，这个区别很重要。我认为门槛与基础设施和定价激励有关，但这只是推测，并非 Anthropic 的内部成本核算。

我提到一个建议的 Claude Code 设置：在 Haiku 上下文接近 10 万 token 时进行压缩，以帮助子智能体工作维持在较低价格档。这可能减少模型可用的上下文，因此要一起评估成本和任务质量；单靠设置不能证明结果好坏。

Anthropic 展示的基准表显示，Haiku 5.5 在 Terminal-Bench 4.0 上得到 39.2%，Haiku 4.5 为 0%，GPT-6 Luna 为 16.4%。同一张表给出的 OSWorld 2.1 离线子集成绩为 72.4%。这些是选定的基准结果，不能作为编程或计算机操作能力的通用衡量。

据介绍，速度因供应商而异，大约为每秒 100 到 200 个 token；我自己的 Claude Code 测试约为 180。Prime 在关闭推理的自动化任务中报告，Haiku 的通过率更低、速度也比 Luna 慢。我怀疑设置有影响，但一个人的工作负载不足以给模型做通用排名。

除了 token 单价，token 效率也很重要。在我查看的 Artificial Analysis 数据中，Sonnet 5.5 使用最大推理级别时，每项任务消耗的 token 非常多。移除这个设置会改变成本图及呈现出的取舍。解读基准数据点之前，一定要检查推理级别。

我先在成本与智能对比图中比较 Anthropic 自家的模型。Haiku 位于较便宜的区间，Opus 和 Sonnet 位于更高的区间。帕累托前沿表示在所选模型和设置中，特定任务成本下测得的最佳分数；改变选择，曲线也会改变。

加入竞争对手后，画面发生了变化。在这次基准快照中，Luna 通常更便宜，Haiku 位于相近的能力区间，GPT-6.1 Sol 则占据前沿的另一部分。这些结果不涵盖所有应用，缓存价格或基准数据更新也可能改变数据点。

即使其他供应商在基准的每美元表现上稍有优势，仍然有理由使用同一家族的模型：现有订阅、合同、统一 API 或智能体协作方式。我并没有证明同家族协作总是更好，但 Haiku 现在感觉是一个合理选择，不再需要自动排除。

基准数据更新、反映 Sonnet 更便宜的缓存读取价格后，它的成本位置有所改善。具体影响取决于任务账单中缓存读取所占比例，因此更新后的图对该基准更有参考价值，却不能保证每次智能体会话都有相同节省。

公告还介绍了 Claude Max 订阅用户的每月 API 额度：5x 用户为 100 美元，20x 用户为 200 美元，团队另有规定。这些额度用于构建调用 API 的应用，与订阅中的交互使用是两回事。Anthropic 还宣布在 Python 和 TypeScript SDK 中提供计算机及浏览器操作的测试版支持。

我更喜欢把 Haiku 集成到应用中，或让更强的智能体把范围明确的工作委派给它，例如分类输入数据、探索代码仓库或检查单个可能性。面对困难的端到端编程项目，它不一定是我会选择的主导模型。

Anthropic 的鸡蛋落下演示比较了单独使用 Opus 与由 Opus 协调十个 Haiku 子智能体。Theo 报告单独运行约需三分半钟，尝试 25 个设计、花费 0.47 美元；组合运行用了 58 秒、尝试 86 个设计、花费 0.14 美元。这是供应商对单项任务的演示，适合说明并行搜索，而不能证明普遍加速。

当许多便宜的尝试都能得到验证，而且普通尝试和仔细推理的尝试差距不大时，这种模式最有吸引力。寻找难以定位的文件或测试多个可能性可以从并行中受益。但更强的智能体仍需要选择合适的任务并评估结果。

社区成员还展示了一个生成视频，据称 API 用量约为 0.60 美元，耗时不到 20 分钟。考虑到价格，这个结果让我印象深刻。但它只是使用特定提示词和流程的一个演示，并不是每个视频都能复现的成本。

在前端例子中，我喜欢部分字体和动画；在我看到的例子里，设计 skill 也带来了明显变化。审美判断是主观的。作为便宜模型，它的输出可用，但我不会说它能取代所有专业设计流程。

我还让 Haiku 审核和分类 T3 Code 的拉取请求，包括与性能相关的修改。早期结果找到了约 40 个相关 PR，但它对可以合并的判断似乎依赖 GitHub 的干净状态，而不是深入的独立审查。我把一个有希望的例子交给 Opus 做更深入的检查。

Fish Slap 游戏演示比较粗糙：没有鼠标移动和声音，角落处理别扭，部分时序也没有忠实还原原作。我最初以为它避免了严重错误，后来又注意到更多问题。与能力更强的模型相比，即使有些失败不那么显眼，它的最佳表现也较低。

画面中的核算显示，两次 Fish Slap 运行按 API 费率约为 0.97 美元。51 个请求中有 47 个超过 10 万输入 token，因此使用了更高价格档。限制上下文可能降低成本，但我预计也可能让游戏质量下降。

我通常更喜欢让更强的模型编写关键代码。按照我的经验，收集上下文、测试、验证和失败后的重试，往往比生成最终代码本身更昂贵。便宜模型如果能降低这些周边成本就很有价值，但一次失败且消耗大量 token 的运行也可能很贵。

如果几个候选实现都能以低成本验证，小模型就可能适合负责生成。它也可以阅读文档、比较项目或调查多个假设。关键问题是工作是否容易拆分，以及能否检查所得答案。

我的大范围 PR 审核撞上了 GitHub 速率限制。脚本把错误响应当作数据保存，181 个 PR 需要重新获取。模型说会等待配额重置，但我没有看到它安排等待，因此线程停下，直到我介入。这是一次观察到的失败，不是经过测量的失败率。

我重新尝试这个思路：让 Opus 负责协调，Haiku 作为被委派的工作者，并要求 Opus 除了收集数据和协调外尽量少做其他工作。Opus 考虑分批处理约 1,495 个 PR。视频没有展示这次更大规模后续任务的完成结果，因此我不能声称它解决了速率限制问题。

低单价并不是全部。如果更强的模型用 10 万 token 解决任务，而小模型用了 100 万仍然失败，那么单价更低的模型总体成本可能更高。我把基准成本数据点当作线索，而不是完整工作流测试的替代品。

在自己的工作流中，我仍喜欢组合使用 Opus 和 GPT-6.1 Sol。我觉得 Sol 很适合审查，因为它可能提供不同视角，发现 Opus 遗漏的问题。Haiku 可以加入这组工具，在更强的智能体判断合适时负责收集信息、阅读大量材料和分类。

我的最终判断是，Haiku 5.5 填补了 Anthropic 产品线中的一个实际空缺。它在某些时候值得使用，尤其适合范围明确、对成本敏感的工作，但仍需要仔细选择任务并验证结果。我也期待这个模型家族接下来的发展。