We meter every Fusion run in tokens, per role. Each candidate lane, each judge seat, the integrator, and the QA passes carry their own counter, and tokens are the primary usage unit across every engine in the run. Credits or dollar cost enter the record only when an engine exposes them or we can derive them cleanly. When a subscription CLI reports a flat dollar figure, we record it as an equivalent-cost estimate, not billing truth.
This is not bookkeeping trivia. A tournament that ranks rival agents is only honest if every agent is measured in the same unit. And the usage record rides on the Receipt, so what a run consumed is part of the evidence you merge, not an operational detail we keep to ourselves.
Why tokens and not dollars
Dollars feel like the natural unit for cost. They are also the least comparable one. Every vendor prices tokens differently, discounts differently, and reports differently. One engine bills through an API meter, another runs on a subscription that surfaces a synthetic dollar figure, a third exposes nothing but raw token counts. If we normalized everything to dollars, we would be comparing three accounting policies, not three engines.
Tokens are the unit the engines themselves share. Every model reads and writes tokens, and every engine can report them. So tokens are primary. Credits and cost are secondary annotations: we record them when the engine exposes them or when they are cleanly derivable, and we skip them when they would be a guess. You cannot rank engines on cost if each one is measured in its own currency.
One counter per role
A Fusion run is not one agent doing one job. Rival candidates build in parallel lanes, a blind jury verifies criterion by criterion, an integrator assembles the final, and QA passes check the result. Each role gets its own meter.
| Role | What we meter |
|---|---|
| Candidate lane | Tokens per competing agent |
| Judge seat | Tokens per verdict, per seat |
| Integrator | Tokens to assemble the final |
| QA passes | Tokens per pass |
Per-role metering answers questions a single total cannot: whether verification costs more than building, whether one candidate burned far more tokens than its rival to reach the same verdict, whether the jury is cheap relative to the work it protects.
Estimates are labeled as estimates
Some subscription CLIs report a flat dollar figure for a session. We keep the number, but we file it as what it is: an equivalent-cost estimate, not billing truth. Nobody was billed that figure. Treating it as real spend would quietly corrupt every cross-vendor comparison downstream.
The Receipt carries the bill
The usage record ships inside the Receipt, next to the verdicts and the evidence. When you merge a final, you can see what every role consumed to produce it. A verification harness that hides its own consumption is asking you to take its economics on faith, and the whole point of a Receipt is that nothing rides on faith.
It also makes the rest of the model auditable. We have written about why failed runs are free; the usage record is how you can check what a run actually consumed, pass or fail.
What comparable units unlock
Per-role token counts, accumulated across runs, are the raw material for something bigger: an honest ranking of engines over time. After a run, the blinds come off and identities map back to real engines and models; the win ledger pairs those outcomes with what each engine consumed to get there. Wins per token is a sharper question than wins alone, and it is only askable because every engine was counted in the same unit from the start. That is where we are heading: cost-aware rosters, where the harness picks lanes not just on who wins, but on who wins efficiently.