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

**Summary:** PlayCode 测出同一段 TypeScript 代码在 Claude 上比在 GPT 上多消耗 73% 的 Token。我的看法是：这个隐藏倍数确实值得关注，但模型选择仍应基于任务成功率而非单纯 Token 单价。

- Canonical: https://markhuang.ai/zh/news/token-price-is-not-the-bill
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-07-13
- Section: News
- Tags: AI, 大模型定价, 分词器, 编程智能体, 模型评估
- Source: [PlayCode Blog](https://playcode.io/blog/real-price-of-frontier-models)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一位卡通开发者对比两台机器，它们将相同的抽象代码带分割成数量迥异的 Token 方块](https://cdn.markhuang.ai/news/token-price-is-not-the-bill/hero.webp)

*同样的代码可能变成不同数量的计费单元，所以标价单只是起点，算不上公平的跨模型比较基准。*

[PlayCode 的分词器分析](https://playcode.io/blog/real-price-of-frontier-models)开篇就抛出一个值得留意的数字：一段 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 计数文档](https://platform.claude.com/docs/en/build-with-claude/token-counting)也独立证实了同一家族内的这一现象。文档指出，较新的 Opus 系列模型、Fable 5、Mythos 系列模型和 Sonnet 5 换用了新分词器，同样的输入会多出约 30% 的 Token，具体幅度因内容而异。Anthropic 也直接建议开发者：换模型之前，先把提示重新数一遍。

> **Info:**
>
> 模型更新时，即使标价单上的输入费率没变，你的仓库代码也可能被拆成更多输入单元。对重度依赖上下文的智能体来说，这种分词器变更就是一次经济层面的变化，哪怕价格表看起来一模一样。

![一位卡通开发者将相同的抽象代码卡送入三台 Token 分拣机，并比较收集到的不同数量的罐子](https://cdn.markhuang.ai/news/token-price-is-not-the-bill/measure-your-workload.webp)

*实用的测试很简单：用你自己的提示、Schema、代码和工具结果的代表性片段，去测试每一个候选模型。*

## 原生 Token 根本不是一回事

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

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

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

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

![一座卡通任务工厂将 Token 方块送入思考迷宫、缓存捷径、重试循环和质量检查点，最终产出完成的软件](https://cdn.markhuang.ai/news/token-price-is-not-the-bill/task-cost.webp)

*分词器效率只是成本路径中的一个环节。思考、缓存、重试和验收都位于提示和有用工作之间。*

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

我找到的最有力的外部证据，已经超出了分词本身。[微软研究院的一项研究](https://www.microsoft.com/en-us/research/publication/the-price-reversal-phenomenon-when-cheaper-reasoning-models-end-up-costing-more/)在九项任务上跑了八个推理模型，结果在 21.8% 的模型配对比较里，标价更便宜的那个反而总花费更高。研究人员把大部分"价格反转"归因于思考 Token 的差异，而且即便是同一条查询重复跑，成本波动也不小。

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

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

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

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

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

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

![一位卡通开发者检查两座机器人建造的桥梁，将一条较小的 Token 轨迹与未完工的桥梁对比，另一条较大的轨迹则对应一座坚固的完工桥梁](https://cdn.markhuang.ai/news/token-price-is-not-the-bill/finished-work.webp)

*只有当另一侧的工作同样可用时，较小的 Token 堆才能胜出。*

## 我的结论

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

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