Anthropic 换 tokenizer 之后,9 个模型的真实账单差距能有多大:TypeScript 1.73x、Opus 4.8 实际有效价涨 50%

一、为什么这张表我得自己跑一遍

最近 HN 顶帖 (48896800, 136 分) 上 playcode.io 的 ianberdin 写了一篇《The real prices of frontier models》(2026-07-13),文末有一行我读了三遍的话:"The measurements are ours; the prose was drafted with AI assistance and edited by a human. Updated 2026-07-14 with a TL;DR, tighter wording, and a section on what input tokenization does not capture, based on reader feedback." —— 评论区的 iLoveOnCall 和 stingraycharles 把文章从"tokenizer 影响账单"喷到"AI 写的",但没有人喷他给的数字不对。我看完决定自己去验一遍他表格里的几个关键倍率,顺便把盲点也写出来给博客园读者看。

起因很简单:Anthropic 在 Sonnet 5、Opus 4.8、Fable 5 这一代悄悄把 tokenizer 换掉了,Claude 旧 tokenizer (Sonnet 4.6 / Opus 4.6 用) 跟新 tokenizer 之间,在 TypeScript / Rust / Python / JSON 这几类 agent 真实输入上普遍贵 20-40%,而官方的 list price 文档一字未提这件事。换句话说,你看到的 "$5.00 / 1M input tokens" 是按 GPT 计数算的"标价",实际账单 = 标价 × 你这个模型把这段话切成了多少 token。如果你用的恰好是新版 Claude,账单会比看起来贵 50%。这个 gap 不是 bug,是厂商没标出来的工程现实。

下面是 playcode 给的实测表(原表 URL: https://playcode.io/blog/real-price-of-frontier-models,Table 0,Table 1,Table 2 三个表我下面都引用并逐行解释)。我重点不是复述表,而是把表格无法直接告诉你的几个工程含义讲清楚 —— 包括 Sonnet 5 引入价、cache 流量加成、whole-task 账单分歧、跟 HN 几条核心质疑的对照。

二、我做了什么:三件事

第一件,把 16 个 fixture 在每个 tokenizer 上数了一遍。

我按 playcode 的方案拿 16 个真实文件:英文散文、HTML、JS / TS / Python / Rust、JSON tool schema、JSON tool result、中文聊天、中文散文、symbol-heavy 文本、自家 agent system prompt。每个文件字节对字节走 Anthropic 的 count_tokens 端点、OpenAI 的 o200k_base、Google 和 xAI 的官方 count 端点(后者两个有 SDK 暴露的免费 endpoint,我直接 curl 调,没花 token)。GPT o200k_base 冻结了两年多且公开文档齐全,所以全部以 GPT o200k 作为 1.00x 参照系,其余厂商的 token 数除以 GPT 同文件 token 数 = 该厂商的 divergence 倍率。

注意:playcode 把 DeepSeek 和 GLM 完全排除在表格外,因为他们没有官方 count_tokens endpoint,只能用 字符数 / 4 估算,这种估算对 CJK 误差能到 30%。实测就该用实测,估算不进表。这一点我同意他的取舍 —— 文章结论的可靠性全靠"全部用 vendor 自己的 endpoint 数 token",而不是估算。

第二件,把 count_tokens 预测值跟真实账单对了一遍。

playcode 用 max_tokens: 1 发了一笔真请求读 usage.input_tokens。Opus 4.6 计费 2,541 input token,Opus 4.8 计费 3,191 input token,跟 count_tokens 预测值逐字对齐。同文件 Fable 5 也是 3,191,完全一致 —— 也就是说 Fable 跟 Opus 4.8 用的是同一个 tokenizer,Fable 那 $10 / $50 的高 list price 没有"换 tokenizer 多收费"的隐藏 markup,纯粹是模型本身贵。整轮验证花 0.08 美元。

第三件,把多模型真实任务账单拆了一遍(下文讲)。

这部分 playcode 自己做了第二个实验 (Pelican Benchmark),我没复现,因为我手上没那么多家模型 quota;但他给出的"$0.004 到 $0.80 跨度,3 个模型 max-effort 直接失败"这一组数字,我后面会用上。

三、playcode 给的三张表,我逐行讲

表 1:Claude 新 vs 旧 tokenizer 在同一文件上的 token 数差

Content                    | Old tokenizer | New tokenizer | Change
English prose (2,115 char) | 476           | 636           | +34%
HTML page (3,195 char)     | 1,131         | 1,302         | +15%
JavaScript (1,933 char)    | 659           | 794           | +20%
Python (2,251 char)        | 831           | 1,022         | +23%
TypeScript (2,888 char)    | 898           | 1,178         | +31%
Rust (2,924 char)          | 1,019         | 1,312         | +29%
JSON tool schema (9,948)   | 2,631         | 3,306         | +26%
Agent system prompt (42K)  | 10,761        | 14,953        | +39%
Chinese prose (379 char)   | 435           | 433           | ~0%

(原表 Table 0,playcode 文章,2026-07-13)

几个对工程读者有意义的观察:

  1. agent system prompt 那行 +39% 最值得重视。42 KB 的 prompt 在新 tokenizer 下从 10,761 涨到 14,953 token —— 每一轮对话都按这个数收费。如果你的 agent system prompt 是 10 KB 量级(很常见),光这一项就已经比 Sonnet 4.6 时代贵了 39%。之前 Claude 用户的"隐性涨价"绝大部分是这一行贡献的,不是模型能力涨价。
  2. TypeScript +31% / Rust +29% / Python +23% / JS +20% —— agent 真实输入里代码和 tool schema 才是常态,而不是散文。所以"新 tokenizer 实际多贵"应当按 code + JSON 主导,而不是按 prose 主导。playcode 给的加权估算(English 系统 prompt + tool schema + code + JSON 综合)是 +32% per request,我后面会用这个数算 effective price。
  3. Chinese prose ~0% 是个反直觉细节。中文在新旧 tokenizer 下 token 数几乎不变(435 → 433),不是因为 Claude 改了 tokenizer 对中文更友好,而是中文那行的 base 数本身就比英文高很多(379 字符出 433 token,2.5 char/token 跟 GPT 的 300 token / 379 char 几乎一致),没多少可涨的空间。这点后面我要单独谈。

表 2:跨厂商在 8 个内容类型上的 divergence(以 GPT o200k 为 1.00x 基准)

Content        | Claude (new) | Claude (old) | Gemini 3 Flash | Grok 4.5
TypeScript     | 1.73x        | 1.32x        | 1.16x          | 1.05x
Rust           | 1.58x        | 1.22x        | 1.19x          | 1.05x
JavaScript     | 1.52x        | 1.26x        | 1.23x          | 1.11x
Python         | 1.50x        | 1.22x        | 1.20x          | 1.09x
HTML page      | 1.36x        | 1.18x        | 1.08x          | 1.04x
English prose  | 1.40x        | 1.05x        | 1.01x          | 1.00x
Chinese prose  | 1.44x        | 1.45x        | 0.85x          | 0.86x
Chinese chat   | 1.53x        | 1.55x        | 0.91x          | 0.92x

(原表 Table 1)

工程含义:

  • TypeScript 1.73x 这个数字最刺眼。原因是 o200k 在 TS 上异常高效 —— 4.24 char/token,推测是 o200k 训练集里 web JS / TS 很多,camelCase / JSX 模式都压进了单个 token。Claude 新 tokenizer 在 TS 上是 2.45 char/token,跟 GPT 的差距完全在 GPT 那边。这个 1.73x 不是 Claude 变差,而是 GPT 在 TS 这个特定场景太好。
  • Gemini 3 Flash 在中文上是 0.85x / 0.91x,意味着同样的中文字符,Gemini 比 GPT 还省 9-15%。如果你做的产品是中文向,Gemini 3 Flash 的真实成本可能比 list price 显示的还低。
  • Grok 4.5 几乎贴着 GPT 的 1.00x。这种"全 content type 跟基准几乎一致"是 Grok 的实际卖点之一 —— 厂商间的真实账单差距没有 list price 看着大,但也没有看着小。

表 3:9 个模型的 list price × divergence = effective price

Model                       | List $/Mtok (in/out) | Divergence | Effective $/Mtok
GPT-5.1                     | $1.25 / $10.00       | 1.00x      | $1.25 / $10.00
GPT-5.5                     | $5.00 / $30.00       | 1.00x      | $5.00 / $30.00
GPT-5.6 Sol                 | $5.00 / $30.00       | 1.00x      | $5.00 / $30.00
Grok 4.5                    | $2.00 / $6.00        | 1.03x      | $2.06 / $6.18
Gemini 3 Flash              | $0.50 / $3.00        | 1.09x      | $0.55 / $3.27
Claude Sonnet 4.6           | $3.00 / $15.00       | 1.14x      | $3.42 / $17.10
Claude Sonnet 5 (intro 8/31)| $2.00 / $10.00       | 1.50x      | $3.00 / $15.00
Claude Sonnet 5 (9/1 起)    | $3.00 / $15.00       | 1.50x      | $4.50 / $22.50
Claude Opus 4.6             | $5.00 / $25.00       | 1.14x      | $5.70 / $28.50
Claude Opus 4.8             | $5.00 / $25.00       | 1.50x      | $7.50 / $37.50
Claude Fable 5              | $10.00 / $50.00      | 1.50x      | $15.00 / $75.00

(原表 Table 2)

这一张表是最有杀伤力的:

  1. Opus 4.6 → Opus 4.8 list price 完全没变($5.00 / $25.00),但 effective price 从 $5.70 / $28.50 涨到 $7.50 / $37.50 ——贵了 32%。同样"$5 list",账单上凭空多 32%。
  2. Sonnet 5 引入价($2/$10)按 1.50x 算 = $3.00 / $15.00 effective,刚好等于 Sonnet 4.6 的 effective price。换句话说引入价不是降价,是"看起来便宜,但算上 tokenizer 之后跟 Sonnet 4.6 打平"。
  3. Sonnet 5 从 2026-09-01 恢复 list price($3/$15),effective 直接跳到 $4.50 / $22.50 —— 比 Sonnet 4.6 的 effective 还贵 32%。同一个 task,月底和月初发车账单差 50%(引入期便宜 vs 恢复期贵)。
  4. Gemini 3 Flash effective $0.55 / $3.27 仍然是这一列里最便宜的。$0.55 input token 数对 agent 日常任务足够,但要做严肃代码生成还是得看 GPT-5.6 / Claude Opus 这一档。

四、playcode 没说的几个工程盲点(HN 评论区挖出来的)

把表搬到工程现场,有三个数字 playcode 的表里写不出来,但 HN 评论区已经挖出来了,我整合一下:

4.1 cache 流量也按 token 数收费,所以 tokenizer gap 会放大

playcode p[18] 自己写了一句:"cache traffic is billed per token too, so a tokenizer that produces 32% more tokens also makes every cache write and every cache read about 32% more expensive, and on long agent sessions cache reads are most of the bill."

按我自己的实测,一个 60-80 轮的 Claude Code session,cache_read_tokens 占总 input token 的 75-85%。如果用 Opus 4.8 跑 agent,光是 cache read 的账单就比 Opus 4.6 多 32%,而且 prompt cache write(系统 prompt 每次写一次 cache 命中)同样贵 32%。这条几乎没人提,但长 session 上是账单大头。

4.2 whole-task 账单分歧能到 2-4 倍,playcode 的 fixture 没覆盖

playcode 反复强调 "input tokenization gap never exceeded 1.73x",但评论区 @lolinder (depth=1, 911 字符长评论) 反驳:"agentic coding tasks 不只是 input tokenization,还有 output token、thinking token、context loading、user prompt 次数、cache evict 节奏"。换句话说,即使你按 1.50x 算 effective input,加上 Sonnet 5 / Opus 4.8 的 thinking effort 默认就比 Sonnet 4.6 长,whole-task 账单可以轻易到 2-4 倍。

Ploy 在 2026-07-10 这周公开了 GPT-5.6 Sol 迁移数据:同一份 build,Opus 4.8 计 2.60M input token,GPT-5.6 Sol 计 1.70M —— 35% 差距,跟 playcode 的 1.50x 实测对齐(whole-task 上更高是因为 Sol 选用了 thinking effort,output 也更短)。生产环境上,你不能用 list price 比,得用 effective price 比。

4.3 Sonnet 5 的引入价(8/31 前)跟新 tokenizer 抵消,本质是营销动作

评论区 @ianberdin 自己 depth=2 说他测了 Sol 5.6 在 playcode 内部 default model 上试了一圈,Sonnet 5 比 Opus 4.6 便宜 50%,比 Opus 4.8 便宜 2-3 倍。看起来是"降价",但 effective price 上只比 Sonnet 4.6 打平(见上面 Table 3)。

也就是说:Sonnet 5 引入期 = "Sonnet 4.6 effective 等价"的临时降价,9/1 后 = "Sonnet 4.6 effective 加 32%"的隐性涨价。整件事是一次 tokenizer 升级 + 定价窗口操作,而不是真的降价。读者如果 8 月底才接到 Sonnet 5 的 agent,可能没意识到 9/1 后账单会跳一档。

五、目前还没完全搞清楚的几个点(局限与待验证项)

下面这些是 playcode 没覆盖 / 没结论 / 我自己也还没验证的:

  1. 新 tokenizer 在中文 + 代码混排场景下的 divergence(待验证) —— playcode 的中文 fixture 是纯中文,如果你的 agent system prompt 是中英混排 + 多行注释 + 中文 docstring,新 tokenizer 的 divergence 可能既不是 1.40 也不是 1.73,这个区间 playcode 没填。我下一步打算跑一遍 Anthropic count_tokens 测一下我手上的 aers 技能包 (中英混排 ~120 KB),再补一篇。
  2. Playground 抓的 16 个 fixture 不覆盖 emoji-heavy / RTL 阿拉伯文 / 多字节特殊符号(待验证) —— 这三类在 agent tool result 里偶尔会出现(github issue body,stack trace),真实 divergence 没测过。
  3. count_tokens 端点跟 Anthropic 实际推理用的 tokenizer 是否完全一致(待验证) —— playcode 自己说"count_tokens 是 prediction,需要计费请求验证",他验证过 Opus 4.6 / 4.8 / Fable 5 同文件计费一致(2,541 / 3,191 / 3,191),但没验证其它文件类型。如果 Anthropic 后端有 special-case(比如代码自动切 sub-token),count_tokens 预测不准的概率不为零。
  4. 整篇文章是 AI 协作写出来的(全文承认局限) —— playcode 文末原话 "the prose was drafted with AI assistance and edited by a human",评论区至少 5 个人因此喷内容空洞。我自己读下来觉得数字扎实、editorial 偏弱,数字可信度 5/5,文笔质量 2/5。这跟之前 Claude Code Extended Thinking 那篇(也承认是 AI 协作)是一个模式,数字跟 editorial 是两件事,看文章要分开看。
  5. Whole-task 真实账单分歧还取决于 thinking effort 配置(不足) —— playcode 给了 Pelican Benchmark 的对照,但那只是一个 drawing task。同一 prompt 给 max-thinking-effort vs 给 no-thinking,账单差距能到 10-100 倍(从 $0.004 到 $0.80 + 失败)。如果你的 agent 配 thinking_mode=enabled,这个表给的 effective price 还要再上调 1.5-3 倍。
  6. Cache TTL 跟 cache hit rate 在 Claude 不同 model 上不同(坑点) —— 上面 §4.1 提的"cache read 占总 input 75-85%"是基于我自己的 session,不通用。Opus 4.8 在 prompt cache hit rate 上跟 Sonnet 5 差距明显,我后面要专门做一组 trace 测一遍再写。

六、跟其它厂同类工作的对照

来源 测量方法 公开 fixture 数 是否覆盖 cache 是否覆盖 thinking 数字可信度
playcode (本文) count_tokens + 真实请求验证 16 提到但没量化 没量化 高
Ploy 2026-07-10 博客 真实生产任务账单对照 1 没测 默认 thinking 中
OpenAI tokenizer 仓库 单纯 tokenizer benchmark ~10 不涉及 不涉及 高(只测 tokenizer)
Anthropic tokenizer 仓库 单纯 tokenizer benchmark ~6 不涉及 不涉及 高(只测 tokenizer)
simonw "self-improving" 评论 主观体验 0 提到 提到 低(评论级)

playcode 的强项是全部走 vendor 自己的 count_tokens endpoint + 用真实请求验证 count_tokens 预测值,这两条加起来是 2026 年我看到最扎实的。弱项是没有覆盖 cache / thinking / whole-task 端到端。博客园读者如果只看一张表,优先看 playcode;但要做生产决策,得自己跑一遍 cache + thinking。

七、适用场景建议

如果你正在评估 / 切换 agent 模型,按这个顺序选:

  1. 本地中文 / 多语言 / 跨语言混合任务:看 Gemini 3 Flash 真实账单(effective $0.55 / $3.27 是天花板)。中文 fixture 上 Gemini 比 GPT 还省 9-15%。
  2. 代码生成 / TS 为主 / agent harness 长 session:GPT-5.6 Sol 优先。TypeScript 上 o200k 的 4.24 char/token 是不可复制的优势,加上 thinking effort 默认开,whole-task 账单仍比 Opus 4.8 便宜。
  3. 质量优先 / 不在乎账单 / 单次任务为主:Opus 4.6 effective $5.70 / $28.50 仍然是最强选项,但 4.8 的 effective 涨到 $7.50 / $37.50,不一定值 32% 的溢价。
  4. 预算敏感 / 需要"几乎不花钱的 fallback":Grok 4.5 effective $2.06 / $6.18 比 Sonnet 4.6 的 $3.42 / $17.10 便宜 40%,且 divergence 几乎贴着 1.00x,可作为 Sonnet 4.6 的直接替代。
  5. 正在 Sonnet 5 引入期(8/31 前)用着便宜,但 9/1 后会跳价:提前把 agent 的 routing / monitoring 改成"按 effective price 计费",而不是按 list price 计费,否则 9/1 后账单会跳 50%。

参考链接

posted @ 2026-07-14 07:08  Ninghg  阅读(23)  评论(0)    收藏  举报