账本与测量边界。
十一种 harness、一个明写的截止时刻，以及你在比较两个数字之前需要的全部规则。
这是《七十亿 token 的全程拆解》的查询分册。它单独存在，是为了让叙事不必把每个数字辩护两遍。这里的一切都是快照：普查取在 2026-09-12T02:40:59Z，每个 harness 带自己的测量窗口，「什么可以比、什么不可以比」的规则是写下来的，不是默认的。如果你只是来核对一个数字，先看表格，然后在引用之前读一遍「边界」。
同一截止时刻的十一种 harness
只列已记录用量。估算与未记录单列，永不并入合计。
| harness | tokens（已记录） | 测量窗口 | 会话 | 说明 |
|---|---|---|---|---|
| claude-code | 2,527,597,534 | 2026-08-08 .. 2026-09-08 | 48 | 较早的历史已被保留策略删除；按 message.id 去重后为 818,520,401（6,600 个 API 响应） |
| pi | 1,926,003,139 | 2026-07-22 .. 2026-09-12 | 67 | 包含执行本次普查的那个会话本身 |
| kimi-code | 1,254,875,254 | 2026-07-18 .. 2026-09-06 | 245 | wire 文件口径；只取 usageScope == "turn" |
| codex | 547,796,667 | 2026-05-27 .. 2026-08-30 | 116 | 已停用。第二个存储独立复核得 546,858,767（相差 0.17%） |
| mulerun | 537,961,611 | 2026-05-20 .. 2026-09-06 | 183 | |
| Hermes | 485,213,348 | 2026-05-15 .. 2026-07-24 | 292 | 此前被发表为「未记录」——它的 token 在 sessions 表里 |
| AgnesCode | 82,931,675 | 2026-07-13 .. 2026-07-26 | 1,142 | 完全不在早先那次普查里 |
| cursor | 27,079,705 | — | — | 不记录工作目录，无法归属到某个仓库 |
| DeepSeek Harness | 10,931,069 | 2026-08-16 | 2 | 完全不在早先那次普查里；会话日志为压缩格式 |
| opencode | 4,190,890 | — | 6 | |
| Qoder | 2,916 | — | — | agent memory 计数器，不是会话账本 |
| 合计（已记录） | 7,404,583,808 | 比已发表 census 的 7,007,437,567 多 397,146,241 | ||
| 合计（去重口径） | 5,695,506,675 | 唯一可跨时点比较的口径 |
claude-code 会为同一个 API 响应的每个分块各写一条 usage 记录，逐行求和会把它的消耗放大约 2.7 倍；按 message.id 去重才是真实的 API 消耗。其他 harness 没有这个问题——所以两个合计的差额恰好只等于 claude-code 这一项修正，不多不少。
iFlow 记录了 185 个会话、37,202 轮对话，但每个用量字段都是零，所以它的体量只能按字符数估算——大约 247,000,000 个 token，且区间很宽。它不进任何合计。这是两种不同性质的数字，不能相加。
早先那次普查不是粗心，是规则太弱：它在查过一张表之后就把某个 harness 判定为「未记录」。Hermes 把消息正文放在一张表里（其 token 列全为零），把会话合计放在另一张表里。修正办法是程序性的：任何 harness 在被标为「未记录」之前，必须先把它存储里的每一张表都列出来查过。
账本为什么会移动
三种互相独立的机制，全部已复现。它们都不是噪声。
保留策略会删掉历史
2026-09-07T13:13:57Z，claude-code 执行了自己的日志清理。于是同一个 harness 比一周前少计了 679,899,086 个 token——尽管中间这一周工作量很重。建立在滑动窗口上的总量不是累计资产，而是从「别人控制的窗口」里读出的一次读数。
观察者在样本之内
普查跑在它所测量的同一台机器上，而执行普查的这个会话正在往被读取的日志里写东西。相隔十二分钟，同一个脚本给出的 pi 合计相差 51,427,037——全部来自测量会话自己。任何重跑都会不一样；唯一的对策是声明截止时刻。
裸日期不是零点
git log --since=2026-09-05 会被解析成那一天的此刻：git rev-parse --since=2026-09-05 得到 1788576106 = 2026-09-05 10:41:46 +0800。在 01:47 和 10:41 各跑一次，提交数会不一样。永远把时区写全：--since='2026-09-05T00:00:00+08:00'。
稳定的读数和不稳定的读数都是信息，但只有稳定的那个配叫「总量」。工作规则是：离开这一页的每个数值都带截止时刻与明写的测量窗口。凡是能做第二次测量的，就把第二次也报出来——codex 的数字在两条独立推导下逐位相同，而这种一致本身就是方法可靠的证据。
提交数与口径陷阱
提交数只有同一种统计规则之内才可比。
| 仓库 | HEAD 提交 | 最新 tag | 阶段 |
|---|---|---|---|
| MRRC | 181 | V5.7.0 | 通用远控产品族 |
| mrrc_ft710 | 162 | v1.8.0 | 垂直切片 + harness 成型 |
| mrrc_modern | 281 | v1.14.2 | 平台抽象 |
| ft8 | 253 | v1.1.0 | 工作流轨 + 首日契约复用 |
| sunsdr（含 SunsdrMobile） | 67 + 9 | v1.0 | SDR 轨 + iOS 客户端 |
| website | 111 | — | 表达与证据系统 |
上表是 HEAD 口径（git log --oneline | wc -l）。用 --all 统计同一批仓库会得到显著不同的数字——MRRC 会变成 328、website 仓会变成 213——因为未合并分支与旁支也被算了进去。两个数字都不算错，混用才是错。本系列所有提交数统一采用 HEAD 口径；而按 message 前缀粗分带来的方法误差约为 ±10%。
这些数字能支撑什么、不能支撑什么
本系列每个数字都活在这些限制之内。它们是明写的，不是暗示的。
- token 不能归因到单次提交。所有「提交 × token」的对应都是「工作目录 × 时间窗口」级归集。
- 每个 harness 带自己的窗口。起止日期各不相同，因为各工具的保留策略不同；跨窗口比较不等于跨时间比较。
- 总量不是单调量。这一周某个 harness 在降、其他在升。下降就报下降。
- 观测者效应在这台机器上无法避免：普查包含执行普查的那个会话。截止时刻是唯一的缓解手段。
- 宣布「未记录」需要缺席证据。在把任何 harness 标为未记录之前，必须先列出并检查它存储里的每一张表。在更弱的规则下漏掉了三个。
- 留存偏差。claude-code 只保留一个窗口；iFlow、Hermes、Qoder 在此前查过的位置没有可用的会话 token。这里所有合计都是实际消耗的下界。
- 轮次不可跨工具比较。各工具对「一轮」的定义不同。只有 token 可以横向走；每提交、每轮的比例只能留在单个项目内。MRRC W25 的 27.6 轮/提交受归档口径变化影响，判定为存疑。
- 任务分类基于关键词（各模型样本数少于 65），属推断级，只看结构。会话按 token 占比最高的模型归一，混用会话会掩盖次要模型。
- 产品数字来自实跑测试，不是抄 changelog。三个产品仓库现在都用各自的虚拟环境（Python 3.13）；用系统 Python 3.9 跑会在收集期因
X | None注解失败。那是环境限制，不是产品缺陷。
本册的普查日期是 2026-09-12。任何引用缺少这个日期、缺少截止时刻 2026-09-12T02:40:59Z、或缺少其 harness 窗口的数字，都已经被引到了它的支撑范围之外。
字段语义，以及怎么查我们
每个 harness 记录用量的方式都不同。求错字段，是得到「看起来合理的错误答案」最常见的方式。
| harness | 求和的字段 | 陷阱 |
|---|---|---|
| claude-code | input + output + cache_creation + cache_read | 四个桶互斥可加——但同一个响应的每个分块各记一条，相信总量之前必须按 message.id 去重 |
| pi | totalTokens | input 不含 cacheRead；用已记录的总量，不要自己加分量 |
| kimi-code | inputOther + output + inputCacheRead + inputCacheCreation | 只取 usageScope == "turn"；用 session 口径会重复计入 |
| codex | 每会话最后一次累计的 total_token_usage | cached_input_tokens 是 input_tokens 的子集——相加会把总量高估约三分之一 |
| mulerun / opencode | 会话级 token 列 | 同一形状的两个存储；共享的那个存储根本没有会话级 token 列 |
| cursor | 每个 bubble 的 tokenCount | 值是累计快照——每个 key 取最后一次。子集工具共享同一批 key，独立贡献为零 |
| Hermes | 会话的 input + output + cache_read + cache_write + reasoning | 消息表的 token 列全为零；合计在 sessions 表上 |
| AgnesCode | usage ledger 的 total | 它自己的累计列精确一致，可作第二意见 |
| DeepSeek Harness | 压缩会话日志里每步的 usage | usage 块嵌在 step chunk 之下，不在记录顶层 |
codex 从会话日志推导出的数字是 547,796,667；同一工具另一个存储报的是 546,858,767——来自第二个独立写入来源，相差 0.17%。AgnesCode 的账本合计为 82,931,675，它自己的每会话累计列求出来完全同值。两处这样的吻合不能证明整本账，但足以说明提取方法没有系统性故障。
这里的一切都来自产生它的那台机器上的文件，所以任何能访问这些日志的人都能重现这次普查——前提是他先固定一个截止时刻。把字段语义写下来就是为了这件事：无法重新推导的数字是声明，能够重新推导的数字才是证据。回到叙事正文《七十亿 token 的全程拆解》，或继续看年鉴与实践手册。