TEARDOWN Nº 5 / FIELD NOTES

Four months of a coding agent, measured

PUBLISHED 2026-08-14 · BY Llorenç Ballester — Chief Burn Officer

Every other teardown on this site is arithmetic over published prices. This one is a measurement. A team let us take their complete coding-agent history — 18,700 messages between 2026-04-07 and 2026-08-12 — and the interesting number was not the bill. It was that 35 out of every 36 tokens the agent processed had already been sent before.

What we measured

One team handed over their full local history from a terminal coding agent — every message, with its token breakdown. We aggregated it by day and model and kept only counters: no prompts, no file paths, no project names. What follows is that aggregate.

The ratio that decides the bill

2.28B tokens were served from cache against 65.9M sent fresh. That is not a rounding detail, it is the workload: an agent re-reads the same project context on every step of every task, and the only reason four months of it is affordable at all is that almost none of that re-reading is billed at full price.

The efficiency figure is the one we did not expect: every cache write was read back about 4,642 times. Providers describe caching as paying off after one or two reads. At four thousand, the write premium has stopped being a consideration at all.

What the same work costs, by model

We are deliberately not publishing what this team actually paid — a good part of their traffic ran on subsidised gateway models, so their invoice says more about their routing than about the work. The useful question is what this volume of work would cost on each model we track, with the caching behaviour they actually had, and without it.

Prices from the board, last confirmed 2026-08-14, recomputed on every deploy. Estimates at list prices, not invoices. A model with no published cached-input rate shows no multiple: we do not credit a discount that isn't published — see the methodology.

Two things stand out. Among the models that publish a cached-input rate, the spread is roughly 188x for identical work — the same argument as teardown #2, now with measured volumes instead of an assumed session. And the cache multiple is not uniform: most models sit near 7.2x, but DeepSeek V4 Flash reaches 18.8x because its cached reads cost about 1% of input rather than the ~10% everyone else charges. That is the same finding that made us rebuild our pricing data two days ago, showing up in a real bill.

The bottom of that table deserves its own sentence, because it is an absence of data rather than an expensive model. Gemini Omni Flash publishes no cached-input rate, so we bill the whole 2.35B of context at list — $3,582, the highest figure here. It may well cache perfectly well in practice. We cannot price what isn't published, and inventing a discount to make the table look tidier is exactly the thing this site exists to complain about. For a workload this cache-dependent, a provider that documents its caching rate is worth more than one that shaves a few cents off the sticker.

The half of the output nobody reads

4.1M of the 7.2M generated tokens — 57% — were reasoning. Billed at output rates, which are the highest rates on any price sheet, and discarded before a human sees them. On Claude Sonnet 5 that line alone is $41 of the $660 total.

We are not going to tell you to turn reasoning off — it is presumably why the agent works. The point is narrower: it is the majority of your generated tokens, most billing dashboards fold it into “output” without breaking it out, and you cannot manage a cost you cannot see. If your provider reports it separately, look at it.

What this changed in our own tools

Running this file through our own free audit is how we found out the audit was broken. It reported grade A, no signals on four months of heavy agent usage, because it measured context per request using only the uncached input — 3,524 tokens per message instead of the real 125,420. The better your cache, the blinder it got: precisely backwards. It now counts cache reads as the context they are, reads the reasoning column, and has regression tests built from this exact shape of data. If you audited an agent workload here before 2026-08-14 and it came back clean, run it again.

Method and limits

This is n=1. One team, one agent tool, one codebase, four months. It is not a survey and not an average, and we would rather publish one honest measurement than a fabricated benchmark. What we think generalises is the shape — a cache-to-fresh ratio in the tens, and reasoning as the majority of generated tokens — because both follow from how agents work rather than from this team's choices. The dollar figures are ours, computed from the board at list prices and recalculated on every deploy; the token counts are theirs, measured. We publish volumes and ratios only: their actual invoice and their model choices are their business, not our content.

If you run a coding agent and want to see your own numbers, the exporter we used is in the repo and the audit is free and runs entirely in your browser. We would like more than one data point — that is the honest reason this page exists.

Frequently asked questions