The spend reported to us for this line of work was ¥16.8, about $2.3 at roughly 7.2 RMB to the dollar. In a separate client-side reading for 28 October, the median request carried about 158k cache-read tokens. Neither reading answers the question people actually ask, which is what the agent cost per useful output.
This piece is about the gap between them, and why we are not going to close it with arithmetic.
Three numbers that look like the same number
There are three denominators in any agent cost story.
The invoice: money, in the currency you were charged, for a period of time. It is the number a finance person needs and the number every cost post quotes.
Wire volume: tokens the client sends and receives. Cache reads, fresh input, output, retries. It is the number an engineer can measure locally, per request, without asking anyone.
The unit cost: money per accepted output. It is the only one of the three that tells you whether a change to the agent was worth making.
You cannot convert one into another without three extra facts: the rate charged for each token class, which stages of work the invoice covers, and a quality gate that decides what counts as accepted. We have one of the three numbers cleanly, one partially, and the third not at all.
What the reported figure covers, and what it cannot
The figure is reported, not verified. It came to us from the person who paid it, and our repository holds no independent receipt or stage-level breakdown.
That is the first limit. The second is coverage. This program ran a pre-registered feedback experiment with 240 executions, a structure experiment with 180 executions and 180 judge calls, a calibration pass, smoke tests, and retries caused by transport errors. Nothing in our logs assigns a share of the spend to any of those stages, and we cannot verify which of them the figure covers.
So we do not use about $2.3 as the cost of either experiment, and we do not treat it as a verified total for both. It is a reported amount attached to a line of work.
What the client carries on every request
Our metering script reads the client session logs and reports, per request, how much of the prompt was already-seen context.
For 28 October it counted 795 requests with a median of 158k cache-read tokens per request and a 90th percentile of 421k. Cache reads summed to 151,017,550 tokens. Fresh input summed to 9,146,736. In this client log, re-read context is the largest input-token class: 16.5 times the fresh-input volume. That is a volume ratio, not evidence about which token class dominated the bill.
Two cautions before anyone quotes that number.
It is not fresh input, not total context, and not a bill. That number is one class of token, from one meter, on one machine.
An earlier saved note records 768 requests and a 159k median for the same date; the later rescan returned 795 and 158k. We cannot reconstruct the cause of that change from the saved evidence, so we treat the readings as diagnostics, not accounting figures.
What the two experiments record
P1 has 240 terminal executions. All 411 recorded completions include usage, but seven API-error cells have no completion or usage record, so usage coverage is not 240 out of 240 executions. Where usage exists, output totals were 99,654 tokens for the arm labelled DeepSeek V4.1 Flash 1017, 110,401 for DeepSeek V4 Pro, and 98,266 for Kimi K3.1 Pro. The API returned only deepseek-flash for the first of those, so the 1017 build is unverified.
That is a token total, not money. We never stored a rate or a currency on those runs. The token column is partial and the money column does not exist.
P2 recorded 180 terminal judge runs across the 90 ambiguous cells: 179 parsed successfully and one ended in a judge-parse error. One third of the executions lack execution-usage records. Judge usage exists, but the missing execution usage prevents a complete P2 token total.
There is a smaller distortion on top. Eight P1 cells ended with API or transport errors. Seven have no completion record, so their token use is unknown; the eighth had already written a valid feedback ledger before the final error. The three V4 Pro step errors had no completion, which is why that arm reads 17/20 in the primary count.
Two numbers that look alike
P2 records 159,215 execution output tokens for V4 Pro in aggregate. The client meter reports about 158k cache-read tokens per request for 28 October. The digits are similar and the quantities have nothing to do with each other: one is generated text, the other is re-read input. If you have seen both numbers in our notes, keep them apart.
The same discipline applies to the older figures. Our skill furnace program cost ¥10.6 in API fees. A separate Claude review cost $10.04. Neither is comparable to the reported $2.3 figure here: different programs, different models, different currencies, different coverage.
Cost per accepted output
If you want one number for design decisions, it is money per accepted output. The existing argument for it is in an earlier piece; this program is a case where the denominator is unusually well defined.
P2 has a quality gate: two judges for each of the 90 ambiguous cells, each scoring against a pre-registered rubric, for 180 terminal judge runs. That is the kind of gate an accepted-output count needs.
It also has a problem. In our last piece, we did not detect a full-versus-shell quality difference. If two configurations produce indistinguishable quality, cost per accepted output becomes the thing that separates them. We cannot compute it: the numerator is a reported figure with no stage split, and one third of the executions have no usage record.
The number we do not have
We are not going to reverse-engineer it.
Multiplying the token totals by our public rate card would produce a number with the shape of a cost and none of the substance: the wrong currency, the wrong rate class, and no stage attribution. We would rather say the number is missing.
What it would take is three small changes, and we are starting on them.
Price each stage in the run log, at the rate actually charged, not at the list rate we publish.
Keep execution usage and judge usage in the same record, so a token total can be checked against a completion count.
Keep a ledger that says which outputs passed, so the denominator is a query and not a memory.
What changed in our pipeline
We are adopting two rules after this program.
A cell without usage is marked incomplete, never zero. P2 taught us that the hard way: sixty executions carried no usage, and a zero would have looked like a free run.
Every cost claim carries its stage scope in the same line. A reported total says reported total. A one-day meter reading says one day and one machine.
Neither rule makes the analysis cheaper. They make it impossible to quote a number we cannot defend.
The reported figure tells you something about what the work cost to run. It does not tell you what the agent costs. For that you need the wire reading and the accepted-output denominator. We have one and a half of the three, and publishing the half we have would be the easy mistake.