账本与测量边界。
十一种 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 账册上依然成立：这里的一切都来自产生它的那台机器上的文件，任何能访问这些日志的人都能重现这次普查——前提是先固定一个截止时刻。把字段语义写下来，就是为了这件事：无法重新推导的数字只是声明，能够重新推导的数字才是证据。回到主文《七十亿 token 的全程拆解》，或继续看年鉴与实践手册。