Six-Week Cost Audit of an AI Coding Agent: Cache Reads Account for 66%, and Savings from Migrating to Newer Models Were Overestimated by 5.5x

When a team is spending thousands of dollars a month on LLM APIs, "switch to a cheaper model" is often the most intuitive way to save money. But a re-pricing audit of real usage logs from an AI coding agent shows that this intuition can be badly off the mark—and that the real cost driver is hiding in a place most people overlook.

The audit covered a single person's coding agent run logs over 46 days (35 of them with active usage), totaling 61,955 requests. With no ready-made invoice to check against, the analyst re-priced every request using a vendor's publicly published, date-stamped price list (retrieved on 2026-10-16). All amounts are API-equivalent costs, not actual billed amounts. The final total was $7,882—the number itself is not the point. What matters are the three counterintuitive findings it exposed.

Finding 1: Two-thirds of the cost goes to "re-reading context"

The most surprising number: 66% of the cost comes from cache reads, and 99% of input-side tokens are cache hits. Meanwhile, the output that people carefully optimize their prompts to influence (output, including thinking) accounts for only 12%.

Cost category	Share
Cache reads (re-reading existing context each turn)	66%
1-hour cache writes	20%
Output (including reasoning)	12%
5-minute cache writes	2%
Fresh input	~0%

Spending is determined by "how long the context is × how many turns were run over it," not by how clever the prompt is. Even more extreme: a single project contributed 63% of the total cost. This means the real optimization lever is controlling context length and session hygiene, not endlessly polishing the prompt. The longer a user lets an agent keep working in the same very long session, the more cache-read costs pile up linearly.

What is prompt caching? Mainstream LLM APIs (such as Anthropic Claude, OpenAI, etc.) allow an already-processed input prefix to be cached server-side. If the next request starts with the same prefix, that portion can simply be "read" at a price far below normal input pricing rather than recomputed. Caches usually have a time-to-live (TTL), commonly 5 minutes and 1 hour. Writing to the cache itself costs extra: the write price for 1-hour caching is usually notably higher than for 5-minute caching, because it occupies server-side resources longer. For coding agents, the system prompt, tool definitions, conversation history, and content of files already read are all re-sent as a prefix on every turn. This is the fundamental reason "cache reads" dominate the cost—the longer the context and the more turns, the more cache-read billing accumulates.

Why is "session hygiene" a cost lever? A coding agent typically accumulates context within one continuous session: every tool call, every piece of code read, and every model output is appended to the history, and all of it is re-sent on the next turn. Because cache reads are billed by "context length × number of turns," a session that runs for hours and balloons to the hundred-thousand-token level will have a significantly higher per-turn cost than starting a clean session. Session hygiene refers to practices such as cleaning up irrelevant history at the right time, splitting tasks into new sessions, avoiding letting the agent spin idly over an extremely long context, and handing independent subtasks to subagents. These actions directly affect the volume of context being repeatedly billed, and are far more effective than deleting a few words from the system prompt.

Finding 2: Savings from "migrating to a newer model" were overestimated by 5.5x

Newer models usually have lower per-token prices. If all requests running on the older model were re-priced at the newer model's rate, it would superficially "save" $1,625 (20.6%).

But this number has a fatal flaw: most requests happened before the newer model was launched. Counting only requests sent after the newer model became available, actual savings are just $293 (3.7%). The two differ by 5.5x.

The logic seems simple, yet it is very easy to overlook: a price you could not possibly have chosen at the time cannot count as "savings." Many cost-optimization reports trip up exactly here—using after-the-fact prices to retroactively price historical usage and arriving at a beautiful but meaningless savings figure. This audit script specifically includes an "available-at-the-time" check to ensure every savings claim is grounded in what was genuinely available at the time.

How the "available-at-the-time" check works. A common mistake when doing cost retrospection is to price all past requests with today's price list and then claim, "If we had switched models earlier, we'd have saved this much." But when the historical requests occurred, the newer model may not yet have been released, or may not yet have been available in the user's region or toolchain, so the user simply could not have chosen it. The correct approach is: for each request, first check its timestamp to confirm whether the newer model was actually available at that time; only requests where it was available go into the "migratable" set, which is then repriced at the newer model's rates. This filter removes a large amount of "phantom savings," leaving only genuinely attainable gains. By adding this timestamp verification layer, the audit compresses a superficial 20.6% savings down to 3.7%.

Finding 3: The setup that looks more expensive is actually the right one

85% of cache-write tokens used the 1-hour prompt cache, whose write price is higher than 5-minute caching. Intuitively, switching to the cheaper 5-minute cache should save money.

The analyst ran the reverse test: assume all cache writes go through the 5-minute cache, so any session idle for more than 5 minutes would need to rewrite the context at the write price. The actual data shows that only 2.5% of cache-read tokens occurred after such idle gaps—but those requests carried enormous contexts. All told, the 5-minute cache would actually cost $1,781 more (+22.6%).

The conclusion: keep the 1-hour cache. The intuition that "the unit price is higher" does not hold up against the real distribution of session idle time.

Incidentally, migrating subagent work to a cheaper model saved only $62—the analyst considers that not worth the quality risk.

What this audit can and cannot do

The boundaries need to be clear: this is a re-pricing based on token counters, not realized savings. The audit did not evaluate output quality. In addition, subagent token streams were merged when measuring idle gaps, so those gaps appear shorter than they actually are. The aggregated CSV in the repository lets anyone verify the totals, and the script can reproduce these figures from your own usage logs.

In other words, it is a mirror reflecting "where the money would flow if billed at publicly listed rates," not a real invoice.

Run it on your own logs

The analysis script is open source (MIT license), fully deterministic, and makes no LLM or network calls:

https://github.com/zbl1998-sdjn/llm-spend-audit-toolkit

The tool supports four core capabilities: extracting per-request usage from coding agent logs (token counters only); pricing by category using date-stamped public price lists; testing savings from migrating to newer models with an "available-at-the-time" check; and testing counterfactual scenarios for 5-minute versus 1-hour caching.

For teams wanting to audit their own bills, the author offers four principles: export data only (no API keys, prompts, or production access required); deterministic analysis (the script runs on your numbers, rather than a model reading your data); reconcile first (recomputed spending must match the actual bill within ±3% before any savings are counted); and keep only conservative, deduplicated findings that were available at the time—report lower-bound values, with the formula attached to every number.

What is "deterministic" analysis? Deterministic here means the script is driven entirely by fixed rules and arithmetic: read token counts from logs, multiply by the price of the corresponding item in the price list, then sum. The same input always produces the same output. It does not depend on random sampling by a model, nor does it send log contents to any LLM or the cloud. By contrast, if an LLM were used to "read" logs and estimate costs, results would vary with model version, temperature, context window, and other factors, and there would be a risk of leaking sensitive code or conversations. The advantage of deterministic auditing is that it is reproducible, verifiable, and auditable: anyone can produce the same set of numbers from the same data. This is also a prerequisite for such tools to be accepted by finance or compliance processes.

Why this audit is worth paying attention to

LLM API cost management is moving from the crude phase of "pick a cheaper model" into a more refined phase of "understand the real structure of spending." Using a small sample (one person, six weeks, about $8,000), this audit clearly demonstrates three things: the dominant effect of caching mechanisms on cost, the statistical trap of after-the-fact price retrospection, and the gap between intuition and actual optimization.

For teams spending more than $3,000 a month on LLM APIs, this kind of deterministic audit offers a low-risk, verifiable starting point for cost visibility—provided you accept its boundaries: it measures where equivalent costs flow, not real savings.

Disclosure: The analysis script and the writing of this article were both completed with AI assistance (Claude Code).

One-line Summary

An LLM coding agent cost audit reveals that 66% of spending goes to cache reads, and model-migration savings are overestimated by 5.5x.

Paragraph Summary

A re-pricing audit of 46 days of run logs from a single-person AI coding agent shows that 61,955 requests had an API-equivalent cost of $7,882. The audit exposes three counterintuitive findings: first, 66% of the cost comes from cache reads while output accounts for only 12%, so the real lever is context length and session hygiene rather than prompt optimization; second, repricing all old-model requests at new-model rates would "save" $1,625, but counting only requests after the new version became available yields actual savings of just $293—a 5.5x gap; third, although the 1-hour prompt cache is more expensive to write, it actually saves 22.6% versus switching to a 5-minute cache, because large-context requests after long idle periods would be repeatedly rewritten. The audit stresses that this is deterministic re-pricing, not realized savings, and the script is open source.