10月7日，Anthropic 发布了 Claude Haiku 5.5。
我对这款模型一直挺好奇。Claude 家族里，Opus 和 Sonnet 的编程能力已经有不少人讨论，Haiku 的关注度相对低一些。毕竟它是 Claude 系列最便宜的型号，很多人习惯拿它做些简单任务。
刚刚我先让它做了一款超级马里奥游戏。
用 Claude Code，通过 OpenRouter 调用 Haiku 5.5，从开始开发到生成游戏，总共19分钟，32次请求，花了0.342美元。
游戏效果让我挺意外，经典的像素风格，人物能跑能跳，能收集金币、吃蘑菇变大，还有敌人、水管和各种平台。
我把游戏放到网上，还专门写了篇文章。
上一篇：2块钱，让Claude Haiku 5.5做了个超级马里奥
不过，做小游戏毕竟容易一些。从零开始，代码量有限，也没有历史包袱。现在 AI 写个网页、小游戏，早就不是什么稀奇事了。
我更关心它能不能用来干日常开发工作。
于是，我又开了一个 Claude Code 会话，让 Haiku 5.5 处理手头的实际项目，当然就是聚模合。
这一跑就是一个小时。
一小时，163次请求
下午4点36分开始，到5点36分结束。
打开 OpenRouter，看到这次的统计：
| 项目 | 实际数据 |
|---|---|
| 模型 | Claude Haiku 5.5 |
| 开发工具 | Claude Code |
| API 平台 | OpenRouter |
| 上游服务 | Claude Platform on AWS |
| 运行时间 | 60分钟 |
| 请求次数 | 163次 |
| 模型数量 | 1 |
| 总费用 | 1.5869美元 |
163次请求，1.59美元。
相比之前做马里奥时的32次请求、0.342美元，这次调用次数增加了不少，费用却依然控制在两美元以内。
这里先说明一下：两次测试的任务不同，游戏是从零生成，另一项是修改现有项目。它们只能说明各自的实际资源消耗，不能拿来直接比较编程效率。
改项目，Token 消耗完全是另一回事
我把这163次请求的明细打开，发现输入 Token 的数量相当可观。
下午4点53分左右，模型连续发起了多次请求：
- 158,887 Tokens 输入，337 Tokens 输出。
- 160,773 Tokens 输入，399 Tokens 输出。
- 161,406 Tokens 输入，369 Tokens 输出。
- 162,638 Tokens 输入，131 Tokens 输出。
- 163,612 Tokens 输入，1,849 Tokens 输出。
后面的请求中，输入规模一度达到16万多 Tokens。
你没看错，有些请求带着16万 Tokens 的输入，最后只输出一两百个 Tokens。
这在 AI 编程过程中其实很常见。
维护现有项目，Agent 需要处理之前的对话、读取过的代码、工具返回结果，以及前面修改过的内容。会话越长，累积的信息通常越多。
比如让 AI 修改一个现有功能，它可能需要先搞清楚原来的代码在哪里、相关模块之间有什么联系、以前为什么这样设计，然后才能动手修改。
这些内容会在后续请求中反复出现。
我这次项目会话里，多次请求都带着十几万 Tokens 的输入。即使最后只需要输出几行内容，模型依然要处理大量上下文。
16万 Token 输入，一次才花多少钱？
我随手点开其中一条记录。
下午5点02分：
- 输入：154,866 Tokens
- 输出：132 Tokens
- 费用：0.00988美元
- 上游：Claude Platform on AWS
- 结束原因：tool_calls
15万多个输入 Tokens，输出132个，最后只花了不到1美分。
看着这个数字，我开始怀疑自己是不是漏看了什么。
后来注意到，OpenRouter 的请求记录旁边有一个缓存标志。
再点开另一条请求，答案就清楚了。
原来大量上下文都命中了缓存
下午5点27分的一条请求，输入为101,732 Tokens，输出347 Tokens。
鼠标移到缓存图标上，OpenRouter 显示：
Provider cached 94,200 prompt tokens
也就是说，这次输入的101,732 Tokens 中，有94,200 Tokens 被上游缓存命中。
算下来，这条请求约92.6%的输入来自缓存。
这下就容易理解了。
Agent 连续开发时，大量历史内容都会反复送给模型。如果每次都按照普通输入价格收费，长会话的成本会迅速增加。
但缓存命中的内容可以按照更低的价格计费。
Anthropic 官方给 Haiku 5.5 的定价是：
| 计费项目 | 输入≤100K | 输入>100K |
|---|---|---|
| 普通输入 / 百万 Token | $0.10 | $0.50 |
| 输出 / 百万 Token | $0.50 | $2.50 |
| 缓存读取 / 百万 Token | $0.01 | $0.05 |
Haiku 5.5 有一条需要特别注意的规则：单次输入超过100K Tokens 后，会进入更高的价格档位。
但即使进入高价档，缓存读取单价仍然只有普通输入的十分之一。
当然，缓存首次写入也需要费用，完整账单还涉及不同类型的 Token，不能只看缓存读取价格。
这些价格可以在 Anthropic 官方模型文档中查到。
同一个模型，换个上游，成本也可能不同
OpenRouter 还有一张表，我以前并没有太关注。
同一款 Haiku 5.5，可以通过 Google Vertex、Azure、Anthropic、Amazon Bedrock 等不同 Provider 调用。
我看到的最近一天统计如下：
| Provider | 有效输入价 /M | 缓存命中率 |
|---|---|---|
| Google Vertex | $0.0787 | 62.0% |
| Azure | $0.0819 | 44.4% |
| Claude Platform on AWS | $0.1109 | 62.9% |
| Anthropic | $0.1909 | 33.8% |
| Amazon Bedrock | $0.2570 | 34.4% |
这些数字是 OpenRouter 按上游统计的实际有效价格和缓存情况，会随时间变化，也不能直接当成各家的固定报价。
这次我的请求主要走 Claude Platform on AWS。
在这张统计表里，它的缓存命中率是62.9%，比 Anthropic 直连上游的33.8%高不少。不过，这是平台过去一天的整体统计，并不代表我这个会话的缓存命中率。
实际开发成本受到好几个因素影响，包括输入输出量、缓存复用情况、上游路由，以及 Agent 有没有反复读取和处理相同的内容。
看来以后选择模型，光看价格表还不够。
Haiku 5.5 到底适不适合真正开发项目？
这次测试让我对 Haiku 5.5 的成本有了更直观的认识。
它刚发布时，我首先关注的是每百万 Token 的价格。毕竟每百万输入0.1美元、输出0.5美元，放在 Claude 家族里相当便宜。
但真正用 Claude Code 跑起来以后，情况复杂得多。
游戏开发时，19分钟、32次请求、0.342美元，就能得到一款可以玩的小游戏。
处理实际项目时，一小时产生了163次请求，上下文经常超过10万 Tokens，最终账单是1.5869美元。
这两个结果都比我原先预期的便宜。
但必须说清楚，今天提供的是调用数据和实际开发过程的观察。这些记录可以确认模型持续进行了大量工具调用，也能说明它的上下文和费用情况。至于具体代码质量、改动是否正确、有没有引入新的 Bug，还需要结合最终代码和测试结果判断。
我也不会因为 Haiku 能在19分钟内做出小游戏，就认为它可以胜任所有大型软件项目。
真正维护项目，麻烦的事情多着呢。尤其是已经上线运行的系统，修改一处代码，可能影响好几个功能。Agent 能不能理解原来的架构，能不能控制修改范围，出了问题能不能自己找出来，这些才需要长时间观察。
Anthropic 把 Haiku 5.5 定位在高吞吐、低成本、低延迟的任务上，尤其包括分类、信息提取和编程子任务。官方同时给了它100万 Token 上下文和最高128K Token 的单次输出能力。
从今天的使用情况看，至少在开发成本方面，它确实给了我一个不错的答案。
最后说说我的打算
以后我应该会继续用 Haiku 5.5 处理一些实际开发任务。
价格足够便宜，长上下文也够用，配合 Claude Code，整个执行过程目前还算顺利。
至于它和 Sonnet、Opus 到底有多大差距，我暂时没有打算花钱去做大规模对照。
如果 Haiku 能够把日常工作做好，我就没有必要每次都去调用更贵的模型。
当然，后面遇到复杂问题，也可能发现它的能力不够。这些都留到实际使用中慢慢验证。
聚模合实验室后续还会继续做游戏实测。游戏可以直接看到成品，普通读者也容易判断效果。
我自己则准备多记录一些真实项目的使用数据，尤其是长上下文、缓存、请求次数和实际费用。
两种场景放在一起看，应该能对模型的能力和成本有更完整的认识。
至少今天这一个小时，让我重新注意到了以前经常忽略的一个指标：
缓存命中率。
同样是十几万 Tokens 的上下文，缓存用得好不好，最后的账单可能差得很远。
这笔账，以后还得继续算。
—— 聚模合 AI 实测实验室