The AI spend nobody bills you for

A flat subscription reports no tokens, because there is nothing to bill. The numbers are on the laptop anyway — and counting them naively overstates the answer several times over.

Karthik Balasundaram, 2 September 2026. About 9 minutes.

On 1 September, Databricks published an account of finding roughly half a million dollars a year of wasted AI tokens inside their own engineering org. The fix took about an hour. The part worth reading twice is what had to be true before the hour could start.

An hour to fix. The rest was already running.

Seven small bugs in their internal tool servers were failing quietly. The agents calling those tools did not stop when a call failed — they retried. One error took an average of twelve turns to recover from, and across all seven bugs there were 1,409 errors in a single twenty-four hour window, burning tokens the whole way. Databricks put the token waste at $499K a year, and around $1.2M a year once the engineering time spent waiting is counted.

Finding all seven, quantifying them and fixing them took about an hour. Their write-up is worth reading in full: How we eliminated $1 million a year of wasted AI agent spend in one hour.

The hour is the headline. The prerequisite is the story. They could do it in an hour because a gateway was already emitting a trace for every tool call, with token counts attached, before anybody suspected a problem. Nobody had to build the instrumentation to find the bug. The measurement was running, so the question could be asked.

That is the part most teams do not have. And one group has none of it at all.

On a subscription, there is nothing to bill

Take five developers, each on a personal Claude Pro or Max subscription. Ask what the team spent on AI last month and the honest answer is the subscription price, which tells you nothing about the work. There is no dashboard, no per-seat number, no record of which model ran what.

This is not an oversight. It falls directly out of how a subscription works. A subscription meters your usage against a limit; an API bills your tokens against a price. When there is nothing to bill there is nothing to report, so nothing is reported. Every other line in your engineering budget arrives with an invoice attached. This one does not.

The transcripts are already on the machine

Claude Code writes a full transcript locally as it works. Every turn, the model that served it, and the token counts for that turn — input, output, cache reads, cache writes. It is on the developer’s own disk, it has been there the whole time, and nothing has to be switched on to produce it.

Which makes the interesting question not where is the data but what does it actually say. Because a naive reading of it is badly wrong, in three specific ways, and each one pushes the answer in the same direction.

Three ways to count it wrong

Streaming writes the same turn more than once

A streamed response is appended to the transcript repeatedly as it arrives. Sum the lines and you count much of the same turn several times over — in practice the total comes out around three times the real figure. The fix is to key on the turn and take it once, not to add up the file.

Summing the lines

Every partial write of a streamed turn is counted as though it were a separate turn.

What actually happened

One turn, counted once, with its final token counts. Roughly a third of the naive total.

Cache reads are not ordinary input

Prompt caching is priced quite differently from fresh input. A cache read bills at about a tenth of the base input price. A cache write costs more than fresh input, not less — 1.25× on the five-minute cache and 2× on the one-hour one.

On agentic coding work the cache share is not a rounding error. The same context is re-read on turn after turn, so cache reads are routinely more than ninety per cent of all tokens moved. Price those at the fresh-input rate and the answer is several times too high, entirely on its own.

Every token at input price

A cache read counted at ten times what it costs, on the tokens that make up the overwhelming majority of the total.

Priced as the API prices it

Reads at a tenth, writes at 1.25× or 2×, fresh input and output at their own rates.

On a subscription, the figure is not a bill

Once the tokens are counted properly they can be priced, and this is where it is easy to say something untrue. If the work ran on a subscription, the number that comes out is not what anyone was charged. Nobody was charged it. It is what that same work would have cost at API list prices — a cost-equivalent, and it should be labelled that way every single time it is shown.

A cost-equivalent is not a bill, not a saving, and not money recovered. Presented as any of those it is simply wrong, and the first finance person to look at it will say so. What it is good for is a decision: whether the plan you are on is the right one, and what you would be paying if you moved.

What eleven weeks of it looked like

I counted my own, using the rules above. 17,300 Claude Code turns between 1 June and 18 August 2026 — eleven weeks of ordinary work, one person.

Of 1,981 million tokens, 95.6 per cent were cache reads. The same work cost $1,842 at API list prices and $200 on a Max subscription. — Measured from local Claude Code transcripts, 1 June to 18 August 2026. One heavy user, not a benchmark — the point is the shape, and that the shape was sitting there unread.

The subscription cost $200. The gap between those two numbers is not a saving and I have not banked anything — it is the answer to “is this plan worth it”, which for eleven weeks I had no way to answer. The data was on my laptop the entire time. I had simply never looked.

One person, eleven weeks, heavy daily use. Your ratio will be different, and if your work is less agentic your cache share will be much lower and the arithmetic will move. Treat this as a worked example of the method, not as a figure to quote back.

What we built to read it

BizWa Shield’s usage reporting reads what is already on the machine and rolls it up across a team. Per developer and per model, it reports:

Turns, and tokens split into fresh input, output, cache reads and cache writes.
Cost-equivalent by model — what that work would have cost at API list prices, labelled as such.
Cache share, because it is the number that decides whether any of the others are believable.
Repeated questions: turns that asked the same thing again inside thirty minutes.

What it does not do: we read Claude Code transcripts, not tool traces. Shield cannot tell you that an MCP tool is failing, and it will not find you the seven bugs Databricks found. The repeated-question count catches the same money leaking without identifying the cause. That is a smaller claim than the one this article opens with, and it is the true one.

The decision this is actually for

Two questions get asked in every engineering org running AI tooling at the moment, usually by someone who is not an engineer. What is this costing us? And should we move to API keys and centralise it?

Both are unanswerable without the number, and the number is not going to arrive from your provider, because on a subscription there is nothing for them to send. It is on the machines, and it takes reading. You cannot cut a cost you cannot see — and you should not migrate a team onto API billing without knowing what the same work would have cost there, either.