Companion I · Ledger

The Ledger and Its Measurement Boundaries.

Eleven harnesses, one declared cutoff, and every rule you need before comparing two numbers.

cutoff 2026-09-12T02:40:59Z 7,404,583,808 recorded 5,695,506,675 deduplicated

By BG1SB  ·   ·  ~7 min read

This is the query volume for Seven Billion Tokens, Dissected. It exists because the narrative needs numbers it does not have to defend twice. Everything here is a snapshot: the census was taken at 2026-09-12T02:40:59Z, each harness carries its own measurement window, and the rules for what may and may not be compared are written down rather than assumed. If you only came to check one number, start at the table and then read Boundaries before you quote it.

Eleven harnesses at one cutoff

Recorded usage only. Estimated and unrecorded ledgers are listed separately and never added in.

HarnessTokens (recorded)Measurement windowSessionsNotes
claude-code2,527,597,5342026-08-08 .. 2026-09-0848Retention has already deleted earlier history; 818,520,401 after deduplicating by message.id (6,600 API responses)
pi1,926,003,1392026-07-22 .. 2026-09-1267Includes the session that performed this census
kimi-code1,254,875,2542026-07-18 .. 2026-09-06245Wire-file caliber; only usageScope == "turn"
codex547,796,6672026-05-27 .. 2026-08-30116Dormant. Independently cross-checked at 546,858,767 from a second store (0.17% apart)
mulerun537,961,6112026-05-20 .. 2026-09-06183
Hermes485,213,3482026-05-15 .. 2026-07-24292Previously published as "not recorded" — the tokens live in the sessions table
AgnesCode82,931,6752026-07-13 .. 2026-07-261,142Absent from the earlier census entirely
cursor27,079,705No working directory recorded, so it cannot be attributed to a repository
DeepSeek Harness10,931,0692026-08-162Absent from the earlier census entirely; compressed session logs
opencode4,190,8906
Qoder2,916Agent memory counter, not a session ledger
Total (recorded)7,404,583,808397,146,241 above the published census of 7,007,437,567
Total (deduplicated)5,695,506,675The only caliber that is comparable across time
Fact · Dual caliber

claude-code writes one usage record per chunk of the same API response, so a naive line sum overstates its consumption by roughly 2.7×. Deduplicating by message.id recovers the real API consumption. No other harness has this problem, which is why the two totals differ by exactly the claude-code correction and nothing else.

Fact · Recorded and estimated must not be merged

iFlow recorded 185 sessions and 37,202 turns but wrote zero into every usage field, so its volume can only be estimated from character counts — roughly 247,000,000 tokens, an estimate with a wide band. It stays outside both totals. The two ledgers are different kinds of number and must not be added together.

Inference · Why three harnesses were missing

The earlier census did not fail from carelessness; it failed from a rule that was too weak. It declared a harness "not recorded" after querying one table. Hermes keeps message text in one table with an all-zero token column and session totals in another table entirely. The correction is procedural: no harness may be labelled unrecorded until every table in its store has been listed and checked.

Why the ledger moves

Three independent mechanisms, all reproduced. None of them is noise.

Retention deletes history

At 2026-09-07T13:13:57Z, claude-code ran its own log cleanup. The same harness therefore measured 679,899,086 tokens fewer than it had a week earlier, despite a week of heavy work in between. A total built on a sliding window is not a cumulative asset; it is a reading taken from a window that someone else controls.

The observer is inside the sample

The census runs on the same machine it measures, and the session executing it writes to the logs being read. Twelve minutes apart, the identical script produced pi totals differing by 51,427,037 — the measuring session's own output. Any re-run will differ; the only defence is to declare a cutoff.

Bare dates are not midnight

git log --since=2026-09-05 parses as that day at the current time of day: git rev-parse --since=2026-09-05 resolves to a max-age of 1788576106 = 2026-09-05 10:41:46 +0800. Run it at 01:47 and at 10:41 and you get different commit counts. Always write the zone explicitly: --since='2026-09-05T00:00:00+08:00'.

Thesis · Snapshot discipline

A stable measurement and an unstable one are both information, but only the stable one deserves to be called a total. The working rule: every figure that leaves this page carries a cutoff timestamp and a written measurement window. Where a second measurement is possible, it is reported — codex's figure is the same to the digit across two independent derivations, and that agreement is itself evidence that the method is sound.

Commits, and the caliber trap

Commit counts are only comparable inside one counting rule.

RepositoryHEAD commitsLatest tagPhase
MRRC181V5.7.0Universal remote-control family
mrrc_ft710162v1.8.0Vertical slice + harness formation
mrrc_modern281v1.14.2Platform abstraction
ft8253v1.1.0Workflow track + contract reuse on day one
sunsdr (+ SunsdrMobile)67 + 9v1.0SDR track + iOS client
website111Expression & evidence system
Fact · Caliber warning

These are HEAD counts (git log --oneline | wc -l). Counting with --all produces materially different numbers for the same repositories — MRRC reaches 328 and the website repository 213 — because unmerged and side branches are included. Neither number is wrong; mixing them is. Every commit figure in this series uses the HEAD caliber, and the method-change error is about ±10% from coarse prefix classification.

What these numbers can and cannot support

Every figure in this series lives inside these limits. They are stated, not implied.

  1. Tokens cannot be attributed to a single commit. Every "commit × token" pairing is an aggregation at working-directory × time-window granularity.
  2. Every harness carries its own window. They start and end on different dates because the tools retain differently; comparing across windows is not the same as comparing across time.
  3. The total is not monotonic. It fell for one harness this week and rose for others. A decrease is reported as a decrease.
  4. The observer effect is unavoidable on this machine: the census includes the session performing it. A cutoff timestamp is the only mitigation.
  5. "Not recorded" requires evidence of absence. Before any harness is labelled unrecorded, every table in its store must be listed and checked. Three were mislabelled or missed under the weaker rule.
  6. Retention bias. claude-code retains only a window; iFlow, Hermes and Qoder record no usable session tokens in the places previously checked. All totals here are lower bounds of what was actually spent.
  7. Turns are not comparable across tools. Each counts a "turn" differently. Only tokens travel; per-commit and per-turn ratios stay inside one project. The MRRC W25 figure of 27.6 turns per commit is affected by an archive-caliber change and is treated as doubtful.
  8. Task classification is keyword-based on each session's first message with fewer than 65 samples per model — inference-grade, read for structure only. Sessions are attributed to the model with the highest token share, which hides secondary models in mixed sessions.
  9. Product numbers come from running the suites, not from changelogs. All three product repositories now use their own virtualenv (Python 3.13); running them under the system Python 3.9 fails at collection time on X | None annotations. That is an environment limit, not a product defect.
Inference

The census date for this volume is 2026-09-12. Any figure quoted without that date, the cutoff of 2026-09-12T02:40:59Z and its harness window has been quoted outside its support.

Field semantics, and how to check us

Each harness records usage differently. Summing the wrong field is the most common way to get a plausible wrong answer.

HarnessField(s) summedThe trap
claude-codeinput + output + cache_creation + cache_readThe four buckets are mutually exclusive and additive — but each chunk of one response is logged separately, so dedupe by message.id before believing the total
pitotalTokensinput does not include cacheRead; use the recorded total, not a sum of components
kimi-codeinputOther + output + inputCacheRead + inputCacheCreationOnly records with usageScope == "turn"; session scope would double count
codexlast cumulative total_token_usage per sessioncached_input_tokens is a subset of input_tokens — adding them overstates the total by roughly a third
mulerun / opencodesession token columnsTwo different stores with the same shape; the shared store has no session-level token columns at all
cursorper-bubble tokenCountThe values are cumulative snapshots — the last one per key wins. A subset tool shares the same keys and contributes nothing independently
Hermessession input + output + cache_read + cache_write + reasoningThe message table's token column is all zeros; the totals are on sessions
AgnesCodeusage ledger totalIts own accumulation column agrees exactly, which is a useful second opinion
DeepSeek Harnessper-step usage inside compressed session logsThe usage block is nested under the step chunk, not at the record's top level
Fact · Two independent cross-checks

codex's figure derived from session logs is 547,796,667; the same tool's separate store reports 546,858,767 — a 0.17% difference from a second, independently written source. AgnesCode's ledger sums to 82,931,675 and its own per-session accumulation column sums to exactly the same value. Two agreements of this kind do not prove the whole ledger, but they do establish that the extraction method is not systematically broken.

Thesis · What you can check yourself

Everything here is derived from files on the machine that produced it, so the census is reproducible by anyone with access to those logs — provided they fix a cutoff first. That is the point of writing the field semantics down: a number that cannot be re-derived is a claim, and a number that can is evidence. Return to the narrative in Seven Billion Tokens, Dissected, or continue to the almanac and the playbook.