Haiku 5.5定价线：100K Token成本跳变|chunk|haiku|token|上下文|定价线|显式标识|调用

```html Haiku 5.5 定价线：100K Token 成本跳变

一段99,000个token的提示词，和一段101,000个token的提示词，在代码里长得几乎一模一样。但在Claude Haiku 5.5上，后者要贵出大约五倍。

差别就卡在10万这条线上。按Anthropic定价页的标价，10万token以内的提示词，输入每百万token 0.10美元、输出每百万token 0.50美元；一旦超过这条线，输入涨到0.50美元、输出涨到2.50美元。输出也跟着按高价算。

麻烦在于它不报错。Haiku 5.5有100万token的上下文窗口，超线的请求照样成功返回。账单，往往是第一个让你发现这件事的地方。

有人把RAG接口迁到Haiku 5.5，看中的就是基础价只有Haiku 4.5的十分之一。然后某个一行PR把topK从12调到20，或者文档团队把页面写长了，一部分流量就悄悄越过了线。

这条线到底多花多少钱

拿一次输出1,000 token的请求，按标价算：

99,000提示词token：99,000 × $0.10/M + 1,000 × $0.50/M = 0.0104美元
101,000提示词token：101,000 × $0.50/M + 1,000 × $2.50/M = 0.0530美元

提示词只多了2%，成本是5.1倍。按每天10万次请求的示意规模算，不计缓存和批量折扣，这就是大约1,040美元和5,300美元之间的差距。

长上下文定价里有两个细节，直接决定防护逻辑怎么写。第一，一次请求的提示词长度统计的是全部输入token，包括缓存读取和缓存写入。第二，超过阈值的请求即使有一部分提示词命中缓存，也照样按高价结算。

也就是说，9万token的缓存系统前缀加上1.5万token的新内容，合起来就是105,000 token的提示词，缓存读取本身的价格也从每百万0.01美元变成0.05美元。缓存没法帮你压回线下，只有更短的提示词可以。

阈值是按单次请求算的，“最高10万”意味着正好100,000 token仍留在基础档。防护逻辑把超过100,000的一律当作长档处理。

先数，再发

Anthropic的TypeScript SDK提供了token计数接口client.messages.countTokens，传入和Messages API相同的model、system、messages和tools，返回input_tokens。这个接口免费，有自己的速率限制（Start档每分钟5,000次请求），且不占用消息创建的额度。

但它是估算值，实际创建消息时用的输入token可能略有出入。所以防护的目标定在97,000，而不是贴着100,000。

还有一个容易踩的坑：Haiku 5.5用的是更新的分词器，同样的文本产生的token比Haiku 4.5多出大约30%。你在旧模型上量过的数字，现在不作数了，得重新数。

防护的核心思路很朴素：把请求的构建收在一处，保证你数的那份东西就是你发出去的那份东西。检索器本来就把chunk排好序，最好的在前。当全量超出预算时，保留这个排序里能装下的最长前缀。

token数只会随着加chunk单调增长，所以用二分查找定位这个前缀，大约log2(n)次计数就能搞定，不用每丢一个chunk就数一次。唯一修不了的情况是连一个文档都不带也超预算，这时直接抛错。

调用之后还要记日志：模型返回的用量、实际计费的提示词token、落在哪一档、丢掉了几个chunk、估算的美元成本。估算时每个提示词token都按未缓存价算，读缓存时会高估，写缓存时会略微低估，用来在图表上抓档位跳变足够，对账还是交给账单数据。

要盯的告警有两个：任何一条落在长档的日志，以及不断上升的丢弃数量——后者说明检索取回的内容已经超出预算能装下的量。

为什么不直接换模型

看起来更省事的办法是把长提示词发给别的模型。单看价格，这条路走不通。Haiku 5.5的长档0.50/2.50，仍然低于同一张价目表上Haiku 4.5的1/5和Sonnet 5.5的2/10。

就算把Haiku 4.5旧分词器那约23%的缩短算进去，一段101,000 token的Haiku 5.5提示词在那边大约是78,000 token，输入约0.078美元，对面是0.0505美元。该换模型的时候是请求需要更强的模型，如果问题只是长度，留着便宜的那个。

如果裁剪会伤到答案，比如摘要必须读完整份文档，还有三条路：把输入拆成线下的小块分别摘要再合并，请求变多但每次都在基础档；用Batch API，长档价格减半到0.25/1.25，前提是任务等得起；或者干脆接受长档，让日志如实写下来。

让CI在PR里拦住它

运行时的裁剪按请求兜住漂移，CI检查则在引发问题的那次PR里拦住它。做法是留一份最坏情况的fixture：你能接受的最长问题，加上最大chunk尺寸下的topK个chunk，全部取自真实语料，然后数一遍。