Only 21 of 533 requests told us what they cost
We sat between real coding agents and their providers for 533 requests. Four percent of them reported usage. Here is what the other 96 percent means for every cost dashboard you have been shown.
On 17 August we let Surfil sit between one developer's coding agents and their providers, and kept what came back. 533 requests, two sessions, one machine. Small. The point is not the size, it is that the numbers are read off real traffic rather than modelled.
The first finding was not about money. It was that 21 of those 533 responses carried a usage field at all. Under four percent. The provider tells you what a request cost when it feels like it: streaming, tool calls and early aborts frequently return nothing, and there is no way from the outside to know which of your requests those were.
Sit with that for a second, because it is the whole argument. Every cost dashboard in this category shows you a total. If fewer than one request in twenty reports its own usage, that total is mostly arithmetic performed on assumptions - a token count multiplied by a price list, on requests nobody measured. It will be confidently wrong in a direction nobody can audit, and it will never say so.
Our own answer is to count the measured ones and refuse to total the rest. The report page says 21 of 533 in the same size type as every other number on it. A smaller honest number is worth more than a large invented one, and it is the only kind you can hand to a finance team without a caveat you have to explain out loud.
The second finding was about the cache, and it went against us. Cache reuse measured 1.70x - each written cache token was read back not quite twice - while the bill carried 302,323 input-token-equivalents of write premium. Prompt caching bills you before it saves you. At 1.70x it was still ahead, but that is a ratio you have to measure per workload, not a feature you switch on and assume.
The third finding was the one that would have made a good headline and does not deserve to be one. Of 533 requests, 39 were screened and zero were blocked, because Guard was watching rather than enforcing. In that outbound traffic it saw two kinds of credential: an Anthropic key and a GitHub token. It can recognise five kinds; only those two were ever present. Two is not a crisis and we are not going to dress it as one. It is also not zero, on one developer's machine, in two sessions.
What this data cannot tell you is on the page with it, permanently and not behind an email form. It has no knowable time span: the device keeps a fixed size of history and evicts the oldest first, so these 533 requests cover whatever fitted, hours or months. No per-day rate can be derived from them and none is published. And it is one machine, one developer, two sessions, one way of working. It is a reading, not a population.
The reason to publish it anyway is that the alternative is what everyone else does. The category standard is a percentage with no run behind it, and the first number we published is the one where Cap removed nothing: zero redundant tokens out of 264,595 parsed across 413 requests. Nothing was there, so nothing was taken out, and nothing is claimed.
If you want the next edition of this to say more than one machine, that is what `surfil contribute` is for. It sends counts and no content - no source, no prompts, no addresses - and the aggregate refuses to generalise until enough machines have reported to mean anything. Right now it says so in those words, because right now it is one.