都标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，历史记录反复带着走，再乘上一档更高的倍率，差异的小数点就变成了整数位。 钱不是一下子花掉的，是