都标5美元，账单差三成！OpenAI高管：token从来没法直接比价

同一段文字，扔给两个模型，一个切成766个token，另一个切成1170个。

甩出这组数字的，是OpenAI Codex负责人Tibo。

他的原话是：一个OpenAI的token，并不等于另一个模型的token。更低的单token价格，并不一定意味着更低的账单。

所有人都在用「每百万token多少美元」比价，好像token是个像克、像千瓦时那样的标准单位，但它不是。

为了让人更容易看懂，他还讲了个披萨的故事。

两张一模一样的披萨。

第一家切8块，每块2美元。第二家切16块，每块1.25美元。第二家招牌上写着更便宜，可整张吃下来要20美元，第一家只要16美元。

他补了一句：你的胃并不关心你刚才吃了几块。

每片更便宜，整张反而更贵。切法不同，单价就失去了可比性。

token是模型计费的最小单位，你可以把它理解成是模型切文字的「刀法」。

同一段话，刀法不一样，切出来的块数就不一样。切出多少块，按多少块收钱。块数越多，账单就越贵。

这次对照覆盖英文、技术文本、多语言和数字内容。

GPT-5.6 Sol的分词器用掉766个token，Claude Opus 5的估算结果是1170个。

同样一段文字，GPT-5.6 Sol的刀法少切出34.5%。

而两家的输入价，都是每百万token5美元。

单价一模一样，块数少了三成，输入费用也跟着少了三成。

麻烦也在这儿。

如果连「一个token有多大」这件事两家都对不齐，那所有人天天转来转去的那张API价格对比表，到底还算不算数？

同一段文字

为何数出两个数？

这是因为token这个单位，压根就没有统一的计量单位。

每家厂商自己训练分词器，自己决定把文本切成多大的碎片。

常见词，分词器整个吞下，生僻词，一个词会被拆成三四块。

拿英文举例最直观。the、and、is这种词天天出现，分词器给它们各留了一个专属编号，一个词就是一个token。

换成unbelievable这种长词，得拆成un、believ、able几块，一个词就占了三个token。

道理很简单：分词器是从训练语料里统计出来的，什么组合出现得频繁，什么组合就单独占一个位置。剩下的，只能用碎块拼。

所以「一段话有多少个token」，本质上是在问「这段话里的东西，在这家的语料里常不常见」。

而英文散文，恰恰是所有内容里差异最小的那一类。代码、JSON、长串数字，两家切出来的结果只会差得更远。

连自家的新旧模型

计数都不能通用

这并非某一家的问题。

Anthropic自家文档写得很明确：token计数是估算值，实际创建消息时用掉的输入token数量可能有小幅出入。

还给出了一个具体的数字。

Claude 4.7及之后的模型换了新分词器，同样的输入文本，产生的token数量比早期模型大约多30%，具体增幅取决于内容和工作负载形态。

Anthropic官方文档：Claude 4.7及之后的模型换用新分词器，同样的文本token数大约多出三成，别复用旧模型量出来的计数。

同一家公司，同一段文字，换代之后多出三成。

所以官方给出的建议是，想知道自己的工作负载差多少，就把同一个请求按两个模型各数一遍，比对返回的input_tokens。

别拿早期模型上量出来的数字估算成本。

自家两代模型之间，计数都不能复用。跨厂商拿「每百万token单价」直接对比，就更谈不上标准化了。

同样5美元

账单差在四处

相同的单价，同样的输入，账单到底差在哪儿？

第一处，刚才说的分词效率。同样一段文本，切出的token数不同，乘上同样的单价，付出去的钱自然不同。

第二处，缓存。

GPT-5.6 Sol的缓存输入价是0.50美元每百万token，只有标准输入价的十分之一。重复前缀多的工作负载，这一项就能把整个账单结构改写。

第三处，输出。

GPT-5.6 Sol输出30美元/百万token，Claude Opus 5是25美元起。

而在真实的智能体工作流里，输出token的权重往往比输入更狠。

也就是说，前面那省下的34.5%，很可能在这里被吐回去。

第四处，最容易被忽略，它就写在OpenAI自己的模型页上。GPT-5.6 Sol的输入超过272K token时，整次请求的输入按2倍计价，输出按1.5倍计价。

GPT-5.6 Sol官方模型页：输入5美元、缓存输入0.50美元、输出30美元，下面那行小字写着超过272K的加价规则。

不是超出的那部分加价，是整次请求适用更高倍率。

同一段代码，你在27万token的上下文里问它，和在28万token的上下文里问它，单价就换了一档。

这条限制来自官方自己的定价页，上下文越长，注意力和显存的开销涨得越快，长窗口从来不是免费的。

百万窗口开了

钱是慢慢流出去的

Tibo随后贴了第二条，教大家怎么在Codex里手动把上下文窗口开满。

打开~/.codex/config.toml，在所有section标题之前加三行：

model = "gpt-5.6-sol"

model_context_window = 1000000

model_auto_compact_token_limit = 900000

第一行选模型，第二行把上下文预算拉到100万token，第三行让自动压缩在90万token附近触发，留出一点余量。

存盘，重启客户端，开一个新会话，配置才生效。

不想动默认值的，也可以只在单次CLI会话里临时覆盖：

codex -m gpt-5.6-sol

-c model_context_window=1000000

-c model_auto_compact_token_limit=900000

这两个键在Codex官方配置参考里都能查到，作用和他写的一致。

model_context_window，当前模型可用的上下文窗口token数。

model_auto_compact_token_limit，触发自动历史压缩的阈值。

但文档只定义键的含义，并没有把「100万/90万」这组数值列成通用推荐值。

Tibo自己在帖子末尾也补了一句：默认值是他们仔细调过的。

那为什么这么多人想手动改？

GitHub上有一份用户实测报告说明了原因。

openai/codex仓库里的这份实测报告：Codex目录把窗口卡在372K，有效353.4K，而模型规格写的是1.05M

在特定版本的Codex客户端和ChatGPT Pro账户下，模型目录里给gpt-5.6-sol标注的窗口是372K，按95%折算，实际可用353.4K。而官方模型页标称的是1.05M。

买的是百万窗口，用起来只剩三分之一。

这份报告有明确的版本和账户限定，不能当成所有用户的现状，Tibo的配置帖发布时间还更晚。

还要澄清一件事：把配置改到100万，不会立刻产生100万token的费用。计费的从来是实际处理量。

可是压缩阈值一路推到90万，意味着一场长会话会背着越来越长的历史往前走，每一轮请求都要把这段历史重新过一遍。

窗口越大、压缩越晚，请求就越可能撞上刚才那个272K的门槛。

短对话里，分词器那点差异是小数点后面的事。会话拉到几十万token，历史记录反复带着走，再乘上一档更高的倍率，差异的小数点就变成了整数位。

钱不是一下子花掉的，是一轮一轮涨上去的。

下一个单位

是「每次成功」

Tibo那条帖子里还有一句话，被数字盖过去了：真正重要的是每次成功结果的成本（price per successful outcome）。

他还给了办法。基准测试可以当起点，但真要知道贵不贵，得拿自己的活儿去跑一遍。

这句话把比价的锚点换了。从「每百万token多少钱」，换到「跑完同一个任务总共花了多少钱」。

想知道两家在你手上到底谁更便宜，自己测一遍就行。

拿同一段原始文本、同样的语言配比、同样的工具定义，分别调用两家官方的计数接口拿到真实token数，再算上缓存命中、输出长度、推理长度和长上下文倍率，最后比谁把这件事干完花得更少。

分词效率只是这条链上的第一环。一个分词更省的模型，如果推理啰嗦、返工次数多，账单照样能反超回去。

以后该问的不是一百万token多少钱，是修好这个bug要多少钱。

参考资料：

https://x.com/thsottiaux/status/2089082893804896524?s=20

https://x.com/thsottiaux/status/2088866513008873560?s=20 https://github.com/openai/codex/issues/31860

编辑：元宇