同样的 TypeScript 代码，Claude 多收了 73% 的 Token 费用？别急着换模型

PlayCode 的分词器分析开篇就抛出一个值得留意的数字：一段 2,888 字符的 TypeScript 示例代码，在 OpenAI 的 o200k 分词器下生成 681 个 Token，而在 Claude 的新分词器下却生成了 1,178 个。也就是说，还没开始比各家每 Token 的单价，输入端就已经多算了 73% 的 Token。

我的感觉是，这篇文章点出了一个真实存在的盲点，到结尾才接近那个更有用的结论：真正该比的不是“每百万原生 Token 多少钱”，而是“跑完你手头的任务，实际花了多少钱”。分词器效率确实影响了读数，但输出长度、推理开销、缓存命中、重试、延迟，以及结果到底能不能用，才是最终账单的决定因素。

答案快照

问题	我的看法
发生了什么？	PlayCode 使用供应商提供的 Token 计数工具测试了 16 个固定内容样本，发现 Claude 的新分词器在其 TypeScript 示例上生成的 Token 比 GPT 的 o200k 多出 73%。
为何重要？	Token 是各家模型自己定义的，所以同样的“每百万 Token 价格”未必能买到等量的代码或文本。
谁受益？	跑编程智能体、塞长提示、工具 Schema、JSON 或反复喂仓库上下文的团队，能据此做出更合理的路由和预算决策。
有何陷阱？	单一的分词器示例无法衡量模型质量、啰嗦程度、思考 Token、缓存行为、重试次数或任务成功完成率。
我的论点	先测原生 Token 数，揪出隐藏的输入膨胀；再按“每次被接受结果的成本”选模型，别只看 Token 数或标价。

73% 的差距虽窄，却很有用

PlayCode 说他们测了 16 个字节完全相同的样本，覆盖英文文本、HTML、JavaScript、Python、TypeScript、Rust、JSON 工具调用数据、中文、符号，还有一个智能体系统提示。Claude 用的是 Anthropic 的 Token 计数接口，GPT 走 tiktoken 加实际用量校验，Gemini 和 Grok 则直接用供应商的计数器。这比拿字符数去猜 Token 靠谱多了。

TypeScript 的结果也不是放之四海皆准的。PlayCode 表格里，Claude 新分词器在代码样本上，Python 是 GPT 的 1.50 倍，TypeScript 高达 1.73 倍，英文文本则是 1.40 倍。我欣赏这种给出边界的写法——一个抓眼球的标题，不至于被当成自然法则。

Anthropic 自家的Token 计数文档也独立证实了同一家族内的这一现象。文档指出，较新的 Opus 系列模型、Fable 5、Mythos 系列模型和 Sonnet 5 换用了新分词器，同样的输入会多出约 30% 的 Token，具体幅度因内容而异。Anthropic 也直接建议开发者：换模型之前，先把提示重新数一遍。

原生 Token 根本不是一回事

最常见的误区，是把各家的 Token 当成统一的“克”来比。其实更像是按“箱”买材料——每家供应商的箱子大小都不一样。在同一家目录里看“每箱价格”没问题，可跨目录比的时候，不知道同一份活儿要多少箱，价格就没法直接比。

Artificial Analysis 把这件事说得很清楚：原生 Token 是模型自己的分词器切出来的，跨模型比性能的时候，他们用的是 OpenAI Token 当量当尺子。“每任务成本”这个指标，是把输入、缓存输入、输出的价格，乘以实际跑完一份工作消耗的 Token 数。比系统而不是比价格表的时候，这才是我想用的标准化口径。

对编程智能体来说，这点尤其要命。它们的输入不只是用户那句简短的请求，还往往拖着长长的系统指令、工具定义、仓库文件、生成的补丁、测试输出，以及越聊越长的对话历史。如果某个分词器把这些重复内容切得更碎，差距就会一轮一轮地滚上去。

但我不想把这件事推到最极端。Token 数不等于能力。一个吃输入 Token 更多的模型，可能轮次更少、补丁质量更高、需要的人工审查更少。分词器切得再省，也架不住推理啰嗦或者反复失败。输入端最便宜的表，不一定能跑出总成本最低的可交付功能。

缺失的变量是"任务有没有完成"

我找到的最有力的外部证据，已经超出了分词本身。微软研究院的一项研究在九项任务上跑了八个推理模型，结果在 21.8% 的模型配对比较里，标价更便宜的那个反而总花费更高。研究人员把大部分"价格反转"归因于思考 Token 的差异，而且即便是同一条查询重复跑，成本波动也不小。

这不意味着 PlayCode 测错了，反而是把它放到了正确的位置上。原生输入分词是一个放大系数，推理和可见输出是另外几个。缓存能给重复前缀打折，工具调用、测试失败、修复循环都在往上叠工作量。最后，结果还得通过验收，这钱才算没白花。

社区里关于“每任务成本”的讨论，也从另一个角度得出了同样的结论。最近r/LLMDevs 有个帖子，有人直接反驳说：按 Token 定价只是一个消耗速率，Benchmark 和用户最终还是要看输出有没有用。另一个被反复提到的点是，审查和恢复步骤能防止一个模型错误在智能体流程里连环翻车。我觉得这个批评有道理：重试确实花钱，但一个设计合理的验证器，恰恰是智能体把概率性的输出变成可交付结果的必经之路。

我会分两步测你的工作负载

第一步，拿一组有代表性的冻结输入，过一遍每家的计数接口。里面要有真实的系统提示、工具 Schema、常用源文件、JSON 响应，外加至少一个长对话状态。可缓存的部分和每次会变的部分要分开统计，别搅在一起算平均。这一步就是 PlayCode 发现的那个分词器倍率。

第二步，把同一个任务跑好几遍，记下完整的用量明细、耗时、工具调用次数、重试次数、测试结果和人工审查结论。分母要用"被接受的任务"，不是"试过的任务"。对编程场景来说，一个被接受的任务大概是：补丁过了测试、满足审查标准，而且没留下后续修复工单。

我还会看分布，而不是挑一次最漂亮的运行。微软研究院已经发现思考 Token 在重复查询下波动不小，智能体工作流的变量只会更多。中位数成本有参考价值，但高百分位成本才是守住预算的那条线。

我的结论

PlayCode 点出了这个类别错误。每个模型自己定义什么是 Token，“每百万原生 Token 多少钱”就没法直接比。它的 TypeScript 示例把这个抽象问题具象化了，Anthropic 的文档也证实，即便在同一个模型家族里，换分词器也能让 Token 数明显增加。

但我不会停在 73% 这个数字上。对编程智能体来说，真正该问的不是哪个分词器把仓库切得最碎，而是哪种模型加工作流的组合，能在成本、速度和可靠性之间交出最好的结果。先数代码，再数整笔账。