williamliu.ai
EN中文
← 返回文章

AI 改版的 62.6 亿 token 去了哪里

6 篇系列的第 6 篇：完成并上线改版后，Codex 和 Claude Code 共使用 62.6 亿 token，按 API 价格折算为 $3,691。其中 97% 是缓存上下文重读。本文按类型、阶段、角色和绕路拆解用量，说明我如何险些少算 20 亿，以及最后 4 天增加了什么。

10 分钟读完
  • token 经济学
  • 编码智能体
  • Claude Code
  • Codex

《用智能体重建 williamliu.ai》6 篇系列的第 6 篇。请从总览开始阅读。

要点

  • 🔁 总计 62.6 亿 token，其中 97% 是缓存上下文重读；每 34 个 token 里，只有约 1 个是新的。
  • 💵 按 API 公开价格折算为 $3,691：Codex $2,473，Claude Code $1,218。两者我都使用订阅。
  • 🧠 最大的单项消耗仍然来自协调：仅 Codex 根智能体就使用 13.9 亿 token，占 Codex 总量的 30%。
  • 🛡️ 审查运行占 Codex 运行的 63%，却只使用其 22% 的 token；构建使用 48%，根智能体的协调使用 30%。
  • 🚀 完成并上线增加了 11.2 亿 token，占最终总量的 18%。
  • 🧾 我的第一次统计漏掉了 20 亿 Codex token：恢复运行后，用量计数器会从头开始。

几乎所有 token 都花在智能体重新读取自身上下文，而重读最多的，是负责协调其他所有智能体的那个智能体。 我统计了从构建到 9 月 16 日上线期间的 683 次 Codex 与 Claude Code 智能体运行，数据来自我机器上的日志：每次 Codex 运行的每个请求，以及每条 Claude 消息的用量各计 1 次。有 2 次短暂的 Codex 运行完全没有记录用量，因此所有总数都是下限。

62.6 亿 token 按阶段划分：Codex 构建 33 亿（53%）；网站与设计对齐 10.2 亿（16%）；部署路径及相关基础设施 8.2 亿（13%）；上线扩展 11.2 亿（18%）。
fig 01 62.6 亿 token 按阶段划分：Codex 构建 33 亿（53%）；网站与设计对齐 10.2 亿（16%）；部署路径及相关基础设施 8.2 亿（13%）；上线扩展 11.2 亿（18%）。

🔁 97% 的 token 都是重读

智能体重读了 60.7 亿个已经见过的上下文 token，写出 1,910 万个新 token，两者比例约为 318∶1。 智能体每执行一步，都会把整段对话重新发送给模型。提供商会以大幅折扣从缓存中提供重复部分，因此缓存 token 很便宜，却并非免费，而且仍然占用上下文窗口。

总量可以拆成以下 3 类：

62.6 亿 token 按类型划分：60.7 亿缓存重读（97.0%）、1.67 亿新输入 token（2.7%），以及模型写出的 1,910 万输出 token（0.3%）。
fig 02 62.6 亿 token 按类型划分：60.7 亿缓存重读（97.0%）、1.67 亿新输入 token（2.7%），以及模型写出的 1,910 万输出 token（0.3%）。
  • 缓存重读：60.7 亿（97%）。 Codex 44.4 亿，Claude 16.3 亿。
  • 新输入：1.67 亿（3%）。 指未由缓存提供的输入：新文件、工具输出和指令，以及缓存已过期的内容。
  • 写出：1,910 万（0.3%）。 包括代码、审查、计划和消息。Codex 写出的 1,618 万 token 中，约 666 万是隐藏推理。

每 34 个 token 里，只有约 1 个是新的。这个事实影响本文其他所有判断：更值得优化的是重复读取的上下文，而不是输出。但这些日志并不能说明，哪种会话策略能真正减少它。

🧠 协调者使用了 Codex 30% 的 token

整个项目中，最大的单项消耗仍是 Codex 根智能体：它为协调构建使用了 13.9 亿 token。 它规划里程碑、协调一棵由 332 个智能体组成的树、阅读它们的报告、集成工作并回复我。每一步都会重新发送它的对话，而对话只会越来越长。按整个项目的 token 计算，Codex 工作分为构建（48%）、根智能体的协调（30%）和审查（22%）。

整个项目所用 Codex token 按角色划分，并列出每次运行的 token：实现、修复和研究 14.9 亿（每次 850 万）；目标根智能体 13.9 亿；Claude Code 启动的实现运行 6.95 亿（每次 1,160 万）；发现者、质疑者和裁决者 7.9 亿（每次 230 万）；Claude Code 启动的审查运行 2.25 亿（每次 480 万）。
fig 03 整个项目所用 Codex token 按角色划分，并列出每次运行的 token：实现、修复和研究 14.9 亿（每次 850 万）；目标根智能体 13.9 亿；Claude Code 启动的实现运行 6.95 亿（每次 1,160 万）；发现者、质疑者和裁决者 7.9 亿（每次 230 万）；Claude Code 启动的审查运行 2.25 亿（每次 480 万）。
  • 构建：48%。 实现、修复和研究运行使用 14.9 亿 token；Claude Code 启动的实现运行另用了 6.95 亿。
  • 协调：30%。 根智能体使用 13.9 亿。
  • 审查：22%。 发现者（Finder）、质疑者（Adversary）和裁决者（Referee）使用 7.9 亿 token；Claude Code 启动的审查和审计运行另用了 2.25 亿。

每次运行的数据仍然说明同一件事。实现、修复和研究运行平均使用 850 万 token；Claude Code 启动的实现运行平均使用 1,160 万；指定角色的审查者平均使用 230 万；Claude Code 启动的审查和审计运行平均使用 480 万。长期运行的协调者和冷启动的工作智能体都会为重读付出代价，只是代价落在不同地方。

🧱 略多于一半用于构建，上线又占 18%

构建占最终总量的 53%，与设计对齐占 16%，部署路径和相关基础设施占 13%，完成并上线占 18%。

  • 构建：33 亿（53%）。 即 Codex 目标会话：规格文档（spec）、计划、16 个里程碑和 333 个智能体。
  • 对齐：10.2 亿（16%）。 包括将改版放到预发布环境（staging）、设计审计和 12 轮修复：Codex 6.6 亿，Claude 3.6 亿。
  • 部署路径与基础设施：8.2 亿（13%）。 包括内存调试、干净检出（clean checkout）部署、部署计时，以及一个后来延期的网站媒体存储改造计划：Codex 2 亿，Claude 6.2 亿。
  • 上线扩展：11.2 亿（18%）。 包括完成博客支持、修正预发布页面、核查本系列、规划下一步搜索工作，以及上线改版。

原来的 3 个阶段没有变化，变化的是分母。从 9 月 12 日草稿到正式上线，增加的正是这 11.2 亿 token。第 5 篇讲述了部署路径出了什么问题。

💵 按 API 价格折算为 $3,691

按公开 API 费率，整个项目的折算成本为 $3,691：Codex $2,473，Claude Code $1,218。两者我都使用订阅，因此这只是价格比较。 Codex 按每个请求所用模型的 OpenAI 标准费率计算；Claude Code 按 Anthropic 费率计算，缓存读取和写入采用各自费率。

按领域和工具划分的 API 折算成本：严格口径的改版 $2,303（Codex $2,048，Claude Code $256）；上线前的部署路径及相关基础设施 $561（Codex $114，Claude Code $447）；上线扩展 $827（Codex $311，Claude Code $516）。
fig 04 按领域和工具划分的 API 折算成本：严格口径的改版 $2,303（Codex $2,048，Claude Code $256）；上线前的部署路径及相关基础设施 $561（Codex $114，Claude Code $447）；上线扩展 $827（Codex $311，Claude Code $516）。
  • 严格口径的改版：$2,303。 Codex $2,048，其中大部分来自 GPT-5.6 Sol；Claude Code $256。
  • 上线前的部署路径及相关基础设施：$561。 Codex $114，Claude Code $447。Claude 部分包括：1 天的内存调试和延期的媒体存储计划为 $277；最终成功的干净检出部署修复为 $138；其他部署会话及部署变更安全审查为 $31。
  • 上线扩展：$827。 Codex 增加 $311，Claude Code 增加 $516。
  • Codex 按模型划分： GPT-5.6 Sol $1,823，GPT-6 Astra $367，另外 5 个较便宜的模型共计 $283。
  • Codex 按角色划分： 根智能体 $807；实现、修复和研究 $1,010，其中包括 Claude Code 启动的实现运行；审查 $656，其中包括 Claude Code 启动的审查和审计运行。

各分项经过四舍五入，因此可能与总数相差 $1。

🚀 最后 4 天花了多少

9 月 13 日至 16 日，智能体使用了 8.48 亿 token，按 API 价格折算为 $641：9 月 13 日 $347，14 日 $187，15 日 $35，上线当天 $72。 这 4 天的工作包括内嵌视频功能及其 15 轮 Codex 审查、真实博客页面偏离设计后的修复、Writing 改名为 Blog、AEO/SEO 审计与计划审查，以及最后的合并、检查和上线。扩展账本还包括 9 月 12 日较晚、未进入快照的事实核查；完整的 11.2 亿 token 和 $827 扩展以汇总账本为准。

Claude 的占比上升，是因为它始终坐在编排者的位置：编写任务说明、集成并审查 Codex 工作，以及推进计划审查和上线。在扩展的 API 折算成本中，Claude Code 增加 $516，Codex 增加 $311。这让 Claude 从最初 $2,864 中的 $702，上升到最终 $3,691 中的 $1,218。

🧾 我如何险些少算 20 亿 token

我的第一次统计显示 Codex 使用 21.7 亿 token；实际数字是 41.6 亿，因为暂停的 Codex 运行恢复后，用量计数器会从头开始。 每份 Codex 日志都会记录一个累计总数。显而易见的统计方法是读取最后一个总数。但我暂停并恢复构建时，计数器重新开始。514 次运行中有 76 次发生计数器重启；根智能体重启 3 次，因而隐藏了其 13.9 亿 token 中的 12.3 亿。

用两种方法统计 Codex token：读取每次运行的最终计数器得到 21.7 亿；汇总每个请求得到 41.6 亿；在计数器重启的 76 次运行中，两者相差约 20 亿 token。
fig 05 用两种方法统计 Codex token：读取每次运行的最终计数器得到 21.7 亿；汇总每个请求得到 41.6 亿；在计数器重启的 76 次运行中，两者相差约 20 亿 token。

这个系列的草稿用错误数字经历了 4 轮独立事实核查，因为核查者采用了相同方法。直到我逐项按 Codex 请求定价，总和对不上，问题才暴露。现在，两种统计方法——逐请求汇总用量，以及把每次重启前的峰值与最终总数相加——都得到同一个结果：4,157,346,610 token。如果你要统计自己的智能体，请逐请求汇总用量，并用第二种方法交叉核对。

🗑️ 哪些成本算浪费

有 3 次绕路产出的工作后来被回退或延期：一个始终与设计不符的播放器、一个时机不对的计划，以及超过价值拐点的审查轮次。

  • 自定义音频播放器：至少 1.14 亿 Codex token，按 API 价格折算约 $28。 我喜欢设计里的播放器，但做出来的那个和它相差很远。按名称计算，有 15 个智能体参与：第 4 至 12 个发现者、第 6 至 9 个修复者，以及最后 1 个质疑者和 1 个裁决者，共 8,600 万 token；把它移除的那次运行又用了 2,800 万。更早的轮次不在这个统计里，审查花掉的那些天也不在。
  • 延期的媒体计划：属于按 API 价格折算为 $277 的那一天的一部分。 研究、规格文档和计划都经过数轮 Codex 审查，目标是一次网站媒体存储改造；后来我为优先修复部署而推迟了它。
  • 超过价值拐点的审查。 修改规则前，中等问题也必须修复或明确豁免，里程碑才能推进。修改后，只有严重和高优先级问题会阻断，其余按优先级进入 backlog。我无法把这部分 token 单独分离出来，这本身也是教训：按严重级别标记每一轮审查，才能算清。

这条严重级别规则，是《编码判断力成为新的护城河》（Encoded Judgment Becomes the New Moat）最小却有用的实例：一个阻断阈值离开我的头脑，改变了之后每一轮审查。

看似开销的工作并不全是浪费。同一套审查循环发现，一个测试辅助工具会在打开调试日志时打印真实凭据。数轮审计把网站偏差从 20 处降到最后一处并修复。这些钱我愿意再花一次。

📏 我每发 1 条消息，平均对应约 3,900 万 token

项目记录的平均值是：我发出的 162 条消息，每条对应 3,860 万 token。这是整个项目的平均数，不代表任何一条消息的单独成本；但它显示，短短几个词可以启动多少智能体工作。 自主运行、审查和部署都发生在我的消息之间。Claude Code 为每轮修复写下的精准任务说明——设计参考、确切问题、范围内文件和应运行的测试——正是这些少量文字最能发挥作用的地方。

单位用量：每条人工消息 3,860 万 token，每次提交 6,730 万，每次智能体运行 920 万。
fig 06 单位用量：每条人工消息 3,860 万 token，每次提交 6,730 万，每次智能体运行 920 万。

🧭 下次我会改什么

监控协调者、更早停止审查、最先验证部署路径，并用两种方法统计 token。

  • 监控协调者的上下文。 一个长期运行的根智能体使用了 Codex 30% 的 token。应该让它无需在自己的对话里携带每一份报告，也能移交工作。
  • 先验证部署与上线路径。 上线前的部署路径折算为 $561；完成并上线又增加 $827。
  • 第一天就写下严重级别规则。 只让严重和高优先级问题阻断，是仍能抓住关键问题的最低成本审查策略。
  • 尽早查看组件，并与设计对照。 这个播放器的 14 轮审查大多只检查功能，只有最后一轮拿它和设计对比过。
  • 逐请求统计 token，并交叉核对。 一个会重启的累计总数，会悄无声息地把数字减半。
  • 过程中就按阶段和目的标记 token。 这次是事后重建全部账目。下次日志应该直接写明每次运行属于哪个里程碑、哪次绕路。

系列到这里结束。改版现在就是线上网站，面向读者的导览介绍了具体变化。

你的智能体有多少 token 用在协调而非实际工作？你会怎样知道？

本文写作方式：由 Claude Code 根据我本人的会话日志起草，另一个 Codex 智能体对照同一批日志核对事实，最后由我修改定稿。封面插图由 AI 生成；图表依据文中数字绘制。