Codex token 计费 4 个隐藏加价点：同一段代码两个模型计费差 30%，3 步算清真实账单

同一段文字，扔给两个模型，一个切出 766 个 token，另一个切出 1170 个。单价都是 5 美元/百万 token，前者却比后者便宜 34.5%。这不是估算，是 OpenAI Codex 负责人 Tibo 上周亲自贴出来的对比数据。

我看了这条推文的最初反应是：那我之前所有「按单价选模型」的决策，是不是都建立在错误的地基上？

顺着这条线把 Codex 的计费规则翻了个底朝天，发现坑比想象的深：token 没有统一计量标准、缓存输入只按 1/10 计价、输出 token 单价是输入的 6 倍、上下文超过 272K 整单翻倍。这篇文章把这套规则拆开讲清楚，最后给你一个 3 步算账的方法，照着算一遍，就知道自己每个月多花了多少钱。

为什么同一段文字，会数出两个数

token 是模型处理文本的最小单位，可以粗略理解成「半个词」。但注意：token 的数量不是客观事实，而是每个厂商自己训练的分词器切出来的结果。

分词器的逻辑很简单：从训练语料里统计哪些组合出现频率高，出现频繁的组合（比如 the、and、is）整个吞下，一个词占一个位置；生僻的长词（比如 unbelievable）没有独立位置，只能拆成 un、believ、able 三块，一个词占三个位置。

所以「这段话会被切成多少个 token」这个问题的本质是：这段话里的东西，在这家的训练语料里常不常见。语料不同，分词器不同，切出来的数就不同。

英文散文是差异最小的内容类型。代码、JSON、长串数字这些内容，各家分词器的切分差异只会更大------而程序员用 Codex 干的恰恰全是这些活。

更麻烦的是，同一家公司内部都不能通用。Anthropic 官方文档白纸黑字写着：token 计数是估算值，Claude 4.7 之后换用新分词器，同样文本的 token 数比早期模型大约多 30%。官方建议：想知道自己的工作负载差多少，把同一个请求按两个模型各数一遍，比对返回的 input_tokens，别拿旧模型的数字估算新模型的成本。

连自家两代模型都不能复用，跨厂商直接对比「每百万 token 单价」，从根上就不成立。

Codex 计费：从按消息，到按 token

先明确一个背景：2026 年 4 月 2 日起，OpenAI 把 Codex 的计费从「按消息扣点数」改成了「按 token 用量计价」。

这个改动本身是好事------按消息计费时，一条消息烧了多少 token 完全是个黑盒，你只知道「又扣了一次」，不知道扣了多少。改成按 token 后，费用 = 输入 token × 输入费率 + 缓存输入 token × 缓存费率 + 输出 token × 输出费率，每一笔都算得清。

但改完之后，账单的敏感度反而更高了。以前一条消息的扣费是平台估算的平均值，现在每一轮对话的实际 token 数都被精确计价，同样的使用习惯，账单浮动可以很大。

4 个隐藏加价点

同样标价 5 美元/百万 token 的两个模型，账单差 30%，钱差在四个地方。

加价点 1：分词效率

这是 Tibo 那条推文的核心：GPT-5.6 Sol 把一段文字切成 766 个 token，Claude Opus 5 切成 1170 个，输入单价都是 5 美元/百万 token，结果前者的输入费用直接少 34.5%。

单价完全一样，块数少了三成，钱也跟着少了三成。你没法控制这件事------它由模型的分词器决定，跟你用什么提示词无关。所以在「每百万 token 单价相同」的模型之间做选择时，真正要比的是「同样一段代码，谁切出来的 token 更少」。

加价点 2：缓存输入只收 1/10

Codex 这类 agent 的工作模式是：把整个仓库的上下文带进会话，每一轮都在这个上下文上继续。这些重复携带的历史，就是「缓存输入」。

GPT-5.6 Sol 的缓存输入价格是 0.5 美元/百万 token，只有标准输入价的 1/10。对长会话来说，大部分 token 都落在缓存输入档位上，这一项直接决定账单的量级。

聪明的用法是：把会话尽量做长、做连续，让仓库上下文只加载一次，之后每一轮都吃缓存价。反过来，频繁开新会话、反复重新加载整个仓库，每一次都按全价输入计费，账单直接翻着跟头涨。

加价点 3：输出 token 单价是输入的 6 倍

看费率表要盯着输出列看。GPT-5.6 Sol 输入 5 美元、输出 30 美元；Claude Opus 5 输入 5 美元、输出 25 美元起。输出单价是输入的 5-6 倍。

完整的解决方案就在后半部分，包含可直接复用的代码模板【关注后可见】

真实智能体工作流里，模型要写代码、改文件、跑测试、给结论，输出量巨大。前面分词省下的 34.5%，很可能在输出这一项上被吐回去。评估成本时，先看自己的任务输出多不多，再决定单价敏感度放在哪一列。

加价点 4：272K 超长上下文，整单翻倍

这是最容易被忽略的一条，也是 Tibo 帖子里最值得划重点的规则。GPT-5.6 Sol 的规则是：当一次请求的输入超过 272K tokens 时，整次请求的输入按 2 倍计价，输出按 1.5 倍计价。

注意措辞：不是「超出部分加价」，是「整次请求」换挡。同一个代码请求，上下文 27 万 token 是一个价，28 万 token 直接翻倍。长上下文从来不是免费的------窗口越长，注意力和显存开销涨得越快，厂商把这部分成本转移到了单价里。

对爱开超大上下文的用户来说，这条规则比任何提示词优化都重要。把上下文压在 272K 以内，比省 10% 的 token 量划算得多。

3 步算清真实账单

与其信各种「AI 工具月花费」的传闻，不如自己算一遍。三步就能算出你每个任务的真实成本。

第 1 步：用分词器数出真实 token 数

别用厂商页面上标的「每百万 token 单价」直接比价，先数数同一段代码在两个模型眼里到底是多少 token。用 tiktoken 可以数 OpenAI 系模型的 token：

import tiktoken

# 用目标模型的编码器数 token
enc = tiktoken.encoding_for_model("gpt-5.6-sol")
code = open("your_repo/your_file.py").read()
print(f"GPT-5.6 Sol 视角: {len(enc.encode(code))} tokens")

Anthropic 系的模型可以用官方 SDK 直接拿 token 计数：

from anthropic import Anthropic

client = Anthropic()
resp = client.messages.create(
    model="claude-opus-5",
    max_tokens=100,
    messages=[{"role": "user", "content": code}],
)
print(f"Claude 视角 input_tokens: {resp.usage.input_tokens}")

同一个请求按两个模型各数一遍，比对返回的 input_tokens，你才知道「5 美元/百万」这个单价背后，实际差了多少。

第 2 步：套计费公式

拿到三类 token 数之后，套官方公式：

cost = (
    input_tokens / 1_000_000 * input_rate
    + cached_tokens / 1_000_000 * cached_rate
    + output_tokens / 1_000_000 * output_rate
)

用 GPT-5.6 Sol 的实际费率代入（输入 5 美元、缓存 0.5 美元、输出 30 美元）：

def estimate_cost(input_tokens, cached_tokens, output_tokens, model="sol"):
    rates = {
        "sol": (5.0, 0.5, 30.0),      # 输入 / 缓存 / 输出，美元每百万
        "opus5": (5.0, 0.5, 25.0),
    }
    i, c, o = rates[model]
    return (
        input_tokens / 1e6 * i
        + cached_tokens / 1e6 * c
        + output_tokens / 1e6 * o
    )

# 一次典型的重构任务：读 20 万 token 仓库，输出 8000 token 代码
print(estimate_cost(200_000, 150_000, 8_000))  # 输出按美元计

跑一遍就会发现：输出占比越高的任务，模型之间的真实成本差距越小；输入占比越高、缓存命中越好的任务，分词效率和缓存价格越关键。

第 3 步：检查两个隐藏开关

算完基础账单，还要检查两个开关，它们能瞬间改变结果。

一是长上下文阈值。如果一次请求的输入接近或超过 272K，先确认是否真的需要这么大的上下文------压回阈值以内，成本直接减半。

二是自动压缩阈值。Codex 可以在配置里设自动压缩的触发点，把历史压缩得越早，每轮请求携带的上下文越短，越不容易撞上加价门槛。

# ~/.codex/config.toml ------ Tibo 分享的百万窗口配置（谨慎使用，见下文风险）
model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000

这个配置把上下文预算拉到 100 万 token，自动压缩推迟到 90 万触发。存盘、重启客户端、开新会话才生效。不想改默认配置的话，可以用 CLI 临时覆盖：

codex -m gpt-5.6-sol \
  -c model_context_window=1000000 \
  -c model_auto_compact_token_limit=900000

但这里有个必须说的风险：GitHub 上 openai/codex 仓库的 issue #31860 有用户实测，在特定客户端版本 + ChatGPT Pro 账户下，gpt-5.6-sol 标注的窗口实际只有 372K（按 95% 折算可用 353.4K），官方模型页标称 1.05M------买的是百万窗口，用起来可能只有三分之一。改配置前先确认自己的客户端版本对窗口的实际支持情况。

另外，把压缩阈值推到 90 万意味着：长会话会背着越来越长的历史，每一轮请求都要重新过一遍这段历史，非常容易撞上 272K 整单翻倍的门槛。窗口越大、压缩越晚，越危险。Tibo 自己也说，默认值是他们仔细调过的，别盲目拉满。

真实成本的核心指标

Tibo 那场争论里最容易被忽略的一句：真正重要的是每次成功结果的成本（price per successful outcome），而不是每百万 token 的单价。

一个模型单价贵 30%，但如果它一次就能把任务改对，不需要你反复纠正、重跑测试，总成本可能反而更低。反过来，单价便宜但频繁失败、来回返工的模型，账单会在输出 token 上爆炸。

算账的时候，把「一次成功结果的成本」当成最终指标：

单次成功成本 = 该任务实际消耗的所有 token 费用 ÷ 成功次数

同一个任务跑 3 次才成功，和 1 次就成功，成本差 3 倍，而这 3 倍和单价没有任何关系。

避坑清单

最后把这套规则浓缩成一张检查单，下次选模型、调配置之前过一遍：

1. 别用 API 价格对比表直接比价------token 口径不一致，单价对比失真
2. 评估成本用同一请求跑两个模型，比对实际 input_tokens，而不是比宣传单价
3. 智能体场景重点核算输出 token 成本------输出单价高 5-6 倍，权重最大
4. 长上下文任务先查加价阈值（如 GPT-5.6 Sol 的 272K 整单翻倍），压回阈值以内
5. 会话做长做连续，让仓库上下文吃缓存价（1/10），别频繁开新会话全价重载
6. 改 Codex 窗口配置前先验证客户端版本，实际可用窗口可能远小于标称值
7. 用「单次成功成本」衡量一切，别被单价牵着走

Codex 改成按 token 计费之后，账是可以算清的，但前提是知道规则藏在哪。分词效率、缓存、输出单价、长上下文阈值------这四个加价点，就是账单差 30% 的全部秘密。下次看到「每百万 token 只要 X 美元」的对比图，先问一句：这段代码，在它眼里是多少 token？

延伸阅读：Qwen3.8-Max 接入踩坑实录：3 个隐蔽坑让成本翻 3 倍------模型名迁移、隐式缓存、榜单口径

Grok 4.6 API 接入踩坑实录：价格砍半是真的，但 5 个坑让我多花了 3 倍钱

Stripe 70 亿美元收购 OpenRouter：1 个 API 调 400+ 模型，实测 3 种接入方式

📌 系列文章

• GPT-5.6 降价 80% 后踩坑实录：Fast 模式 2 倍价、priority 自动迁移，5 个坑让账单翻倍
• DeepSeek API宣布整体涨价：涨幅较大具体方案未定，刚永久降价4个月就变脸，开发者现在该做什么
• DeepSeek 涨价落地：V4-Pro 高峰 12 元/百万 Token，我用开源 Headroom 把 Token 成本砍掉 92%------3 种接入方式实测
• DeepSeek 涨价 3 倍后换谁？5 款国产模型 API 成本实测：K3 贵 17 倍、GLM 贵 5 倍，只有它没涨

看完有收获？点个关注 👆 我会持续分享更多AI编程实战教程。