同一段文字,扔给两个模型,一个切成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
本文来自微信公众号“新智元”,作者:ASI启示录
