Claude Opus 4.7 是一个很典型的例子。Anthropic 文档明确写道,Opus 4.7 的新 tokenizer 在处理文本时,可能比此前模型使用约 1x 至 1.35x 的 tokens,也就是最高约多 35%,并且增幅会随内容变化;同一输入通过 /v1/messages/count_tokens 比较 Opus 4.7 和 Opus 4.6,会得到不同的 token 数。
更准确的说法是:如果同一份 prompt 在新 tokenizer 下被拆成更多 input tokens,而 input-token 单价不变,那么 input 部分的成本通常会上升。
但这不等于每个 prompt 都会多 35% tokens。Anthropic 给出的范围是约 1x–1.35x,并明确说明会因内容而异,所以不能简单理解为“所有请求一律贵 35%”。
也不能把 token 增幅直接换算成整张账单增幅。Anthropic 的 pricing 文件把 Base Input Tokens、Cache Writes、Cache Hits、Output Tokens 分开列价;OpenAI 和 Gemini 也分别提供 API pricing 文件。 也就是说,input tokens 变多会影响 input 成本,但总成本还要看 output tokens、缓存命中或写入、模型价格,以及一次请求的具体结构。
Token 不是字数,也不是简单的字符数。
OpenAI 的 tiktoken 教程展示了:要知道一段文字会被拆成多少 tokens,需要使用对应的 encoding 来计算;Gemini 文档也说明,Gemini API 的输入和输出都会被 tokenized,包括文本、图像等输入。
因此,用“字数 × 某个比例”来估算成本,只能做粗略预算。真正可靠的是看目标模型实际返回的 token count。Claude Opus 4.7 和 Opus 4.6 对同一输入会在 count_tokens 中返回不同结果,正说明 tokenizer 改动可以改变同一内容的计数结果。
| 常见说法 | 更准确的理解 |
|---|---|
| Opus 4.7 会让所有 prompt 一律贵 35% | 过度简化。官方说法是约 1x–1.35x tokens,且因内容而异。 |
| 同一段文字可能被算成更多 tokens | 准确。Anthropic 明确说明 Opus 4.7 的新 tokenizer 可能使用更多 tokens,并且会与 Opus 4.6 的 token count 不同。 |
| Tokenizer 改动只影响上下文长度,不影响成本 | 不完整。API pricing 会按 input、output、cache 等 token 用量项目计费,token count 变化可能影响成本计算。 |
| 最好用官方 counter 实测 | 准确。OpenAI 有 input token counting 与 tiktoken 指引,Gemini 有 count_tokens 文档,Anthropic 文档也指向 /v1/messages/count_tokens。 |
如果只看 input tokens,并假设 input-token 单价不变,可以用一个简化公式:
额外 input 成本 ≈(新 tokenizer input tokens − 旧 tokenizer input tokens)× input-token 单价
但这只估算 input 部分。实际账单还可能包括 output tokens、cache writes、cache hits 或其他产品计费项;Anthropic pricing 文件已经把这些项目分开,OpenAI 和 Gemini 也有各自的 pricing 文件可对照。
生产环境里真正送进模型的内容,往往不只是用户的一句话,还可能包括 system 指令、长上下文、工具返回数据、文件、图像或其他输入。Gemini 文档说明所有 input 和 output 都会被 tokenized;OpenAI 的 token counting guide 也展示了包含文本与图片的 input token counting。
OpenAI 提供 responses.input_tokens.count 文档,也有 tiktoken 计算指引;Gemini 提供 count_tokens;Anthropic 在 Opus 4.7 文档中提到 /v1/messages/count_tokens,并说明 Opus 4.7 会与 Opus 4.6 返回不同 token 数。
不要只拿一条短 prompt 下结论。Anthropic 对 Opus 4.7 的描述是 token 增幅会因内容而异,所以应当抽取高流量、长上下文、最贵或最常见的 payload 类型来比较。
先比较新旧模型的 input token count,再用对应模型的官方 pricing 换算 input 成本差额;之后再把 output、cache 等项目纳入总成本模型。Anthropic、OpenAI、Gemini 都有官方 pricing 文件可核对。
如果 token 差额很小,可能只需要更新预算和监控;如果高流量 payload 明显变贵,就可以考虑压缩 prompt、缩短 context、改进缓存策略,或重新估算单次请求成本。重点不是看到“35%”就紧张,而是用官方 counter 和官方 pricing 把影响量化。
新 tokenizer 的确可能让同一份 prompt 使用更多 tokens。Claude Opus 4.7 的官方文档已经确认,处理文本时可能比此前模型使用约 1x–1.35x tokens,最高约多 35%,但增幅会因内容而异。
真正该问的不是标题里的“35%”,而是:你的真实 payload 在新模型下多了多少 input tokens?output 行为有没有变化?cache 项目如何收费?对应供应商的 pricing 是否仍按同样方式适用?
升级前先跑官方 token counter,再套入官方 pricing,才是判断 prompt 是否会变贵的可靠方法。