模型降价九成，为何实际却是七成半

摘要：10 月 7 日 Claude Haiku 5.5 降价九成，很多人改了个模型名就上线。一周后账单只降七成半，代码还先报了五个错。这篇把三层账拆开算：计费单位、定价阶梯、参数契约，各变了一次。

十月的第一周，你大概做过这件事：把配置里的 claude-haiku-4-5 换成 claude-haiku-5-5，跑通测试，上线。

价目表上写着降九成。你心里有个预期，月底账单出来，数字对不上。

先别急着怀疑自己算错了。

那九成去哪了？

答案是它从来不是九成。九成是单价的降幅，而账单等于单价乘 token 数再乘落在哪一档。三个乘数里，厂商只宣传第一个。

公告写的是单价

先把官方数字摆清楚。Haiku 5.5 的输入输出单价，按提示长度分两档：十万 token 以内每百万 token 收 0.10 美元和 0.50 美元；超过十万，跳到 0.50 和 2.50 美元。

对照 Haiku 4.5 的一口价 1 美元和 5 美元，短档是整整十分之一，长档是二分之一。

缓存另有算法，读缓存 0.01 和 0.05 美元，五分钟写缓存 0.125 和 0.625 美元。批处理半价。

只看这张表，降九成没毛病。

问题是价目表的单位是"每百万 token"，而你的账单单位是"这次请求要花多少 token"。这两个单位之间隔着一个东西，叫分词器。

同一段文字，多算了三成

Haiku 5.5 换了新的分词器，官方给的换算比例是 1.3 倍——同一段文字，在 4.5 上算 1000 个 token，在 5.5 上要算 1300 个。

这一条决定了你能拿到多少折扣。官方脚注自己也写了：十万以内大约便宜九成，十万以上大约便宜五成，把分词器的膨胀算进去，加权平均接近七成半。

为什么厂商要换分词器？

官方没解释原因，只说"更新了"。这个态度可以理解——分词器换代通常是跟着上下文窗口扩容一起做的长期工程决定，新词表要在更长的文本上保持压缩效率。但它对存量代码的副作用是直接的：你原来调好的 max_tokens、算好的预算、写死的截断逻辑，全部要重新量一遍。

按官方公布的单价和 1.3 倍的比例折算，同一条请求的实际成本大致是这样：

短请求降到一成三，长请求降到六成半，加权之后大约两成五。图里这些数是按公开单价和官方给的 tokenizer 比例折算出来的，不是实测；你自己的业务落在哪，得拿真实请求跑一遍才知道。

十万 token 那道坎

第二层是定价结构变了。Haiku 4.5 是一口价，无论发多长都按 1 美元和 5 美元算；Haiku 5.5 把它切成两级，十万 token 是那条线。

十万 token 是个什么概念？把一份几百页的技术文档整本塞进去，大概就是这个量级。

这意味着一件事：短请求你吃到的是十分之一，长请求只剩二分之一，再乘上 1.3 倍的分词器膨胀，实际只降了三成半。

而长 prompt 恰恰是很多人最近在做的方向——把整个仓库、整份合同、整套客服记录一次性塞进去。上下文窗口从 20 万扩到 100 万，本来就是为了鼓励你这么干。

于是出现一个反直觉的组合：窗口变大了，你能塞的变多了，但越过十万之后单价跳五倍。窗口的扩容和计费的分级，是同一件事的两面。

真要做长上下文，动这笔账的顺序应该是先分块、再上检索、最后才考虑缓存。顺带说一句，这一代的缓存读只要 0.01 美元，比 4.5 的 0.10 美元便宜九成，长对话反复引用同一份材料的场景，省的钱比降单价还多。

代码会先报错

第三层最直接。官方发布说明写得很直白：为 Haiku 4.5 写的代码，在 Haiku 5.5 上会坏掉。

不是"可能有细微差异"，是坏掉。返回 400，不是警告。

迁移说明列了五处：

旧写法	新模型下的结果	改法
thinking: {type: "enabled", budget_tokens: N}	400	改成 type: "adaptive"，深浅由 effort 控制
temperature / top_p / top_k 非默认值	400	删掉，靠提示词引导
结尾放 assistant 预填	400	格式要求改用结构化输出或工具
computer_20250124 工具集	400	换成 computer_toolset_20260801
改了 system 或早期消息后回传 thinking 块	400	会话只能追加，不能改写

这几条的共同点，是厂商把"每次请求临时调参"的权力收回去了，改由模型级配置统一管。对横跨多个服务、共用一个模型 ID 的团队来说，这确实是简化；对一个靠扫温度、手工掐 thinking 预算来压成本的服务来说，等于把调用约定整个重写。

顺带一提，他们还给了条捷径：在 Claude Code 里跑一句 /claude-api migrate this project to claude-haiku-5-5，让它自己去改。省事，但改完还是得自己复核，因为它不知道你的业务里哪句 max_tokens 是故意写小的。

还有两处不报错的

真正容易在半夜出事的，往往不是上面那五个。

回复的第一个内容块可能是 thinking，不再是正文。 以前拿 content[0].text 当答案的代码，现在会拿到一段推理过程。得按 type 去挑。

thinking 的 token 计入 max_tokens。 以前按 4.5 调好的小额度，现在可能刚够模型想完，正文一个字都没输出就停了。

这两处都不报错，只是结果变了。上面五处跑一次集成测试就能发现，这两处要等到线上用户投诉"回答是空的"才会浮出来。

还有个配套变化值得一并处理：adaptive thinking 默认是开的，effort 默认中等。也就是说，你不能再靠"关掉思考"来把模型变便宜，思考本身就是这个产品的一部分，你能调的只是它多用力。低档位适合分类和抽取，高档位留给调试和推理，这成了部署时的常规选择，而不是准备两个模型。

迁不迁，先量四件事

那干脆不迁行不行？先看清代价的另一面。

Haiku 5.5 的上下文从 20 万扩到 100 万，最大输出从 6.4 万提到 12.8 万，官方承诺 2027 年 10 月 7 日之前不退役——两年的下限，对那种要长期挂着的流水线不算短。

能力上它也不是原地踏步。在独立榜 Artificial Analysis 的智能指数上拿到 43 分，在 182 个条目里排到第二位，把不少厂商的旗舰压在下面；电脑操作的 OSWorld 2.1 离线子集从上一代的 15.7% 涨到 72.4%，终端任务的 Terminal-Bench 4.0 从 0 分变成 39.2%。

官方还放过一个 demo，任务是用家用杂物设计一个装鸡蛋的架子，要求从 32 米扔下来不碎。Opus 5.5 单干，3 分 37 秒，试了 25 种方案，花 0.47 美元；让 Opus 带十个 Haiku 5.5 子 Agent，58 秒，试了 86 种，花 0.14 美元。

这个 demo 比任何价格表都更能说明问题：小模型省钱的正确姿势不是拿它替大模型，是拿它当大模型的手脚。

所以要不要迁，我建议先量四件事，缺一件就先别动。

同一批真实请求，在两个模型上各跑一遍，比 token 数，不要比单价。这一步花不了几分钟，能省掉后面所有的猜测。

数一下你的请求有多少会越过十万 token。如果一个都没有，恭喜，你吃满折扣；如果有不少，先做分块和检索，再谈迁移。

搜一遍代码里的 temperature、top_p、budget_tokens、content[0]。前三个决定你能不能跑起来，最后一个决定你跑起来之后拿到的对不对。

最后跑一遍集成测试，把五个 400 都撞出来。这一圈只能验"起不起得来"；起得来之后还得回头改一次 max_tokens，因为思考的 token 现在算在里面，额度不够，模型想完就没地方写答案了。

写在最后

回到开头那笔对不上的账。

九成是单价，七成半是账单，这两者之间隔着一个分词器。厂商没有说谎，只是宣传的口径和你的成本口径不是同一个。

定价从一口价变成阶梯，是这一代最容易被忽略的变化。窗口变大和单价跳档，是同一件事的两面。

迁移会先给你五个 400，再给你两个不报错的坑。前者是麻烦，后者是事故。

唯一真正能省钱的地方，可能不在单价上，而在结构上——主模型规划、小模型跑腿，那个 0.47 美元到 0.14 美元的对比，比降九成有说服力得多。

下次再看到"降价多少"，先问三句：计费单位变了吗？价格阶梯变了吗？接口契约变了吗？

三个里只要有一个变了，价目表上的那个百分比，就不是你要算的那个数。

参考资料

1. Anthropic 发布说明与迁移说明（Claude Haiku 5.5，2026-10-07），模型 ID claude-haiku-5-5；转述见 CodeDTX 的迁移梳理 与 OrcaRouter 的发布解读
2. 价格与分档：Claude Haiku 5.5 API Pricing, Context, and Limits
3. 分词器与迁移要点：Moving Your Classifier to Claude Haiku 5.5
4. 完整指南与各平台模型 ID：Claude Haiku 5.5 完整指南

作者：唐悦玮 | 公众号同名
从后端出发，用 AI 拓展到全栈的工程师。