Your AI Bill Scales With Readers, Not Records

TL;DR

I went into our Claude Enterprise audit convinced the problem was people using Opus and Fable for work that Sonnet could do. That accounted for less than a quarter of what I found.
The real pattern: 12 of 18 heavy users are paying to re-fetch data they already have, and it is completely uncorrelated with model tier. A downgrade programme would have missed most of it.
Enterprise admins can read the actual conversations. That is the difference between a spend dashboard and an explanation.
This is part 1. The audit tool is open source; run it on your own org.

The hypothesis I walked in with

Our Claude Enterprise bill had gotten large enough to warrant a look. Not alarming, but large enough that "we should understand this" turned into an actual project.

My assumption was the boring one, the one every finance partner reaches for: people are over-provisioning. Somebody set their default to Opus eighteen months ago, never touched it again, and is now burning premium tokens to summarise Slack threads. Find those people, move them to Sonnet, book the savings, close the ticket.

I audited the top 25 spenders, excluding engineers (their Opus usage is the job, not the problem). Eighteen users cleared the threshold, together accounting for a few hundred thousand dollars a year and a meaningful slice of the org bill.

The model-tier hypothesis was not wrong. It was just small.

What the conversations showed

Here is the thing most people do not realise: on the Enterprise plan, an admin can read the actual conversations. Not aggregate token counts, not a usage chart with a line going up. The transcripts. Every tool call, every retry, every loop.

That is a meaningful privacy surface and you should treat it as one; I am not suggesting you go browsing. But for a spend investigation it is the difference between "this person costs $851 a month" and "their skill reads the same plugin file 610 times in a single run."

Because that is what I found. The top finding was not model choice at all:

Signal	Users affected
Missing memoisation (duplicate retrievals over 50%)	12 of 18
Tool error rate above 3%	9 of 18
Huge context windows	9 of 18
Premium-heavy usage	7 of 18

The median duplicate retrieval rate across eighteen heavy users was 76 percent; seven people were above 84 percent, and one was at 98.

And crucially, it had nothing to do with which model they were on. Our worst offender, a marketing lead, sits at 98 percent duplicates on Sonnet. A product manager is at 70 percent while touching premium models 1 percent of the time. Meanwhile our highest premium share, an engineer at 99 percent, sits at 30 percent duplicates doing legitimate engineering work.

If I had run the model-downgrade programme I planned, I would have flagged that engineer (a false positive) and missed five of the heaviest duplicate offenders entirely. That is close to a third of the spend I audited, invisible to the metric I arrived with.

Why "too many tool calls" was also the wrong answer

So I updated my hypothesis: the problem is tool call volume. Cache the calls, cut the bill.

That was wrong too, in a more interesting way.

I found one user whose blog-writing skill had issued 11,398 web_fetch calls, of which 11,208 were identical. My first instinct was to treat this as a usage pattern to discourage. Reading the transcript made it obvious it was a defect: a loop that never stored what it had already fetched. Nobody was overusing anything. A skill was broken, and it had been broken quietly for weeks because nothing in the system notices a blog post that costs 1,531 tool calls.

The generic fix does not exist either. PreToolUse hooks cannot return a cached result, and 91 percent of the duplicates were built-in tools (web_fetch, Read, Bash, Grep) that no MCP-layer cache can intercept. There is no config change here. There is a handful of shared skills that loop without state, and fixing those is the whole game.

That is the shape of the finding, and I only got to it by reading the workflow rather than the counters. The counters said "too many calls." The transcripts said "this specific skill forgot what it already knew."

What actually is low-hanging

To be clear, the boring hypothesis was not empty. There is a cluster of seven users sitting at 83 to 96 percent Fable, doing summarisation and drafting work: Slack thread comprehension, call prep, account briefs. Nobody arrives at 94 percent Fable through individual prompt choices. That is a default someone set once and never revisited, worth roughly $24k a year, and the fix is a ten-minute conversation rather than a policy rollout.

There is a project with two 760KB CSVs being re-sent on every turn of 25 separate chats, worth about $5k a year to split out, with zero change to how anyone works.

There are six people who independently built email and Slack triage, on three different models, because nobody knew the others had already done it.

That last one is the real story of this audit, and it is not a cost story. The waste is not that people picked expensive models. It is that eighteen capable people are each solving the same problems alone, with no shared patterns, no visibility into each other's work, and no mechanism that notices when a skill starts looping. We optimised for giving everyone access. We never built the layer where they learn from each other.

What I actually found: there is no team memory

I went in looking for a Pareto curve. I expected one dominant cause, twenty percent of the behaviour driving eighty percent of the bill, and a clean intervention at the end of it.

That is not what came back. I found a Fable default nobody revisited, a skill looping on web_fetch, two CSVs re-sent on every turn, six people independently building email triage, a browser being driven to edit slides, and a tool error rate nobody was measuring. Six different problems with six different fixes.

It took me a while to see that they share a denominator. Every one of them is a symptom of the same missing thing: our team has no shared memory. Each user is a sealed context window that learns nothing from any other.

Here is the version of it that made the cost obvious. When a CSM, an AM, and an AE each read the same call transcript in their own separate cloud sessions, we pay for that transcript three times. Not three times cheaply; three times at full token price, three separate MCP round trips to the same system of record, three separate summarisations of identical content producing three near-identical answers. Multiply by every account the three of them share, and by every transcript, email thread and Slack channel attached to those accounts.

That is fine at eighteen heavy users. It is arithmetic that gets ugly fast as the team grows.

Important

The cost of a system of record scales with the number of people who read it, not with the number of things in it.

Which reframes the whole exercise. The question is not "who is using the expensive model," it is what belongs in shared infrastructure instead of in eighteen private context windows. Three things fall out of that:

Answer caching. If someone already asked what happened on that account this quarter, the second and third person should get the answer, not re-derive it.
Prompt caching, applied deliberately rather than incidentally, for the large stable context everyone loads in common.
Pre-summarising low information density content. Call recordings, email threads and Slack are enormous and mostly noise. Summarise them once, on a cheap model, on ingestion, and serve the summary. Today every user hits those systems of record directly through MCP tools and pays full freight for the raw material every time.

None of that is a spend control. It is a platform decision I did not know I needed to make when I started this, which is roughly the point of writing it down.

This is the first post, not the verdict

Every individual in this post has been anonymised. The numbers are real and unchanged; the people are described by role, and in a couple of places I have blurred details that would make someone identifiable internally.

I read 8 to 10 sessions deeply per user and scanned about 30, so duplicate rates are directional rather than exact, and the 50 percent threshold for flagging missing memoisation is a judgement call rather than a measured cliff. None of this measures value either: the user with a 15 percent tool error rate may be producing the best work in the company. Every saving number here is an estimate against measured spend. Nobody has made one of these changes and re-measured yet.

So treat this as the opening of an investigation, not its conclusion. I am going to keep digging, make some of these changes, measure what actually happens, and write up where I was wrong. There is more to come, including the parts where the numbers do not hold up.

Run it yourself

I built this as a repeatable audit skill rather than a one-off analysis, and it is open source at hginsights/claude-code-audit, alongside the rest of our tooling at github.com/hginsights. It reads local transcripts, is stdlib-only Python, and nothing leaves the machine. Point it at your own top spenders and you get the same table.

I expect you will find what I found: the model-tier story is real but small, and the thing actually costing you money is that nobody can see what anyone else is doing.

Next in this series, I go one level down into the skills themselves: what makes one loop, what a per-skill tool-call budget should look like, and whether a tool error rate above 3 percent is a platform problem or a user problem.