How to Stop Burning Claude Tokens: The 80/20 of Prompt Caching

For one insurance agency, the discovery that changed the monthly AI bill happened on a slow Tuesday afternoon when a producer opened the usage dashboard out of curiosity and found that a large portion of their tokens were not being billed at the full rate. Nobody had configured anything. Nobody had read the documentation. The savings had been running quietly in the background for months, and the team had been unknowingly breaking them just as quietly.

Madhuranjan Kumar walks through exactly how prompt caching works, what breaks it, and what the usage report looks like after four months of correcting the two habits responsible.

How an Insurance Agency Cut Its AI Compute Bill by 90 Percent Without Changing Tools

This agency runs ten producers. Each one uses an AI assistant throughout the day to draft policy summaries, answer coverage questions, and write client follow-up emails. None of that work changes week to week in the context it requires. The carrier list stays the same. The coverage rules stay the same. The compliance language and the standard email templates stay the same. Every message the assistant writes pulls from the same stable foundation of reference material.

At roughly 200 AI-assisted messages per day, each loading that stable context at full token cost, the uncached bill was running around $44 per day. Over a working month of 22 days, that is $968 per month. The agency had budgeted for it and accepted it as the standard cost of the tool.

What they did not know was that prompt caching had been running automatically the entire time. A cached token costs 10 percent of a normal input token. The portions of each conversation that stayed the same from message to message were already being flagged for reuse. The problem was that the team's habits were breaking the cache before it could pay off, resetting it to the expensive baseline more often than anyone realized.

Once the team understood the mechanics and corrected two specific habits, the daily cost dropped to around $4.40. Same 200 messages. Same stable context. Same quality of output. The only difference was that the context was no longer being resent at full price on every message. Over 22 working days, the monthly bill dropped from $968 to roughly $97. The saving was $871 per month. Over four months, $3,484 recovered without changing a single tool, model, or workflow.

The Moment the Team Realized the Cache Was Already Running

A producer pulled the usage dashboard during a slow afternoon and started reading the columns. Alongside the familiar "input tokens" figure was a second column labeled "cache reads." The number was large, and it was attached to a cost that was a tenth of what input tokens cost. The question at that week's team meeting was simple: what is this, and why is the full input token cost also still running in parallel?

The answer came from reading the documentation. Prompt caching is a feature that runs automatically inside Claude and Claude Code. It identifies parts of a conversation that are stable, meaning they have not changed from the previous message, and reuses them from a stored version instead of reprocessing them from scratch. A cached token bills at 10 percent of a normal input token. No configuration is required. It activates by itself from the first session.

What the team had also been doing, without realizing it, was breaking the cache regularly. The savings visible in the cache reads column represented the minimum benefit they captured with zero effort. The habits that were resetting the cache back to full cost were invisible until the mechanics were understood well enough to recognize them in the workflow.

The first step was understanding the three layers. The second was identifying the two ways the cache breaks. Both took about an hour to work through, and both changed the economics permanently.

Three Layers of Context and Which One Saves the Most Money

Prompt caching in Claude operates across three layers, and each represents a different category of context.

The system layer holds the base instructions and tool definitions, the foundational instructions that establish what the assistant is and how it should behave. For this agency, that was a brief paragraph establishing the tool as insurance-focused, professional, and accurate.

The project layer holds the team's reference documents: the carrier list, the coverage rule summaries, the compliance language document, and the standard email template library. These are the files that every producer draws from every day. They change infrequently, perhaps once per quarter when a carrier updates their guidelines. This layer produces the largest savings for a document-heavy business, because it holds the most stable text read on the highest number of messages.

The conversation layer holds the message history. This recaches with every turn, which is exactly how it should work. New messages add new context that the model needs to process fresh. That cost is appropriate and unavoidable.

For the agency, the project layer was where the meaningful saving lived. The carrier and compliance document set was being read on every message. Cached, that context billed at a fraction of its uncached cost. On 200 messages per day, the difference compounded to the gap between the $44 and the $4.40 daily bills. Moving the stable reference material into the project layer and leaving it there was the single largest driver of the reduction.

A useful mental model for the project layer is a filing cabinet. Every document that goes into the cabinet stays there and is available cheaply for every future request. Documents that get pasted into the conversation instead of filed in the cabinet have to be re-read at full price every time a new message arrives. For the agency, the carrier and compliance reference set belonged in the cabinet. Moving it there was the equivalent of setting up the filing system correctly on day one rather than carrying the same heavy folder into every meeting.

The TTL Is the Detail That Most Teams Discover Too Late

A cached block of context does not stay cached forever. It has a time-to-live, a window after which the stored version expires and the next message must pay full price to reload it. On a Claude subscription, that window is one hour. On per-token API usage, or when using subagents on any plan, the window drops to five minutes.

The five-minute window catches most API users off guard, because it is easy to trip without noticing. For this agency on a subscription, the relevant window was the one-hour TTL. A producer who left a client quote session open while taking a lunch break and returned fifty-five minutes later was fine. A producer who came back sixty-five minutes later sent the next message into an expired cache. The entire context reloaded at full cost, exactly as though the conversation was starting from scratch.

Quantifying this is what made the correction feel urgent. If three or four producers hit the TTL once per day on average, each time resetting a substantial stable context from cached to full-price, that was three or four expensive reloads per day that should have been cheap cache reads. Small individually, but meaningful accumulated over a month and significant over four months.

The fix was one team rule: if you are stepping away from a session for more than forty-five minutes, close it and start a fresh one when you return. Starting fresh means the new session caches efficiently from the first message. Resuming an expired session means paying full price to rebuild the cache before it pays off again.

Teams using subagents face a tighter version of this problem. On any plan, subagents get a five-minute TTL rather than the one-hour subscription window. A workflow that chains several subagent steps together, where each step takes longer than five minutes to execute, can silently recache between steps, paying full price to reload context the previous step had already cached. Understanding where the five-minute boundary falls in any multi-step workflow is the first thing to check before scaling a subagent pipeline, because a pipeline that looks efficient at ten steps can be paying for eleven cache resets along the way.

The producer who noticed the cache reads column ran a rough calculation before bringing it to the team: if the agency doubled its AI-assisted message volume over the next year, the uncached bill would also double, to roughly $1,900 per month. The cached bill at the corrected hit rate would stay around $200. That is a $1,700 per month gap at the higher volume, which is larger in absolute terms than the current saving. Understanding caching now means the economics stay favorable as usage grows, rather than becoming a budget problem at exactly the moment when the tool is delivering the most value.

The Two Habits That Broke the Cache Before Anyone Noticed

The first habit was model switching. Claude's caching works through prefix matching: the cached content is tied to the specific model that generated it. When a producer switched models mid-session, even switching to a different capable model for a different kind of task within the same long conversation, the prefix changed. The cache reset. Everything that had been stored cheaply now had to be reloaded at full cost on the next message.

The agency had developed a pattern of using a faster model for quick formatting tasks and a more capable one for nuanced coverage analysis, toggling between them inside a single session. Every switch was silently resetting the cache. The habit felt like a smart use of different tools for different jobs. The usage report showed it was a recurring invisible reset of the savings.

The second habit was leaving sessions open through the TTL. The one-hour expiry sounds generous, but a producer deep in a complex client case who stepped out for a meeting and came back seventy or eighty minutes later was regularly tripping it. The session looked active on screen. The cache window had already closed. The next message paid full price for context that had been cached twenty minutes earlier.

Both habits were invisible without understanding the mechanics. Both were easy to change once the mechanics were clear. The fix for model switching was treating each model as a separate workflow: if you need both, use two sessions rather than toggling inside one. The fix for TTL expiry was the forty-five-minute rule. Neither required new tools, new accounts, or any configuration change. Both required one team meeting and a printed reminder posted near each monitor.

Four Months Later: What the Usage Report Actually Showed

Four months after correcting the two habits and loading the carrier and compliance documents into the project layer where they would cache most efficiently, the team ran a comparison against the original baseline.

The daily spend was holding consistently at roughly $4.40 on days with 200 messages, against the $44 baseline from before the corrections. The saving was not a single good month caused by reduced volume. It was consistent across every billing period after the habit changes went into effect. The cache hit rate, visible in the dashboard as a distinct column, was substantially higher and stable month over month.

Over four months of working days, approximately 88 days, the cumulative saving was roughly $3,484. That is the equivalent of almost three and a half months of the old uncached monthly bill recovered and returned to the operating budget. No tools changed. No plan was upgraded. No workflow was modified. No output quality changed in any measurable direction.

The producer who first noticed the cache reads column keeps the usage dashboard visible during the workday now, not because active management is required, but because watching the cache hit rate stay high is a daily confirmation that the habits are holding. When the rate dips, it almost always means someone switched models mid-session or let a long conversation expire. The dashboard surfaces that the same day, so the correction happens before the pattern becomes expensive again. That monitoring habit, a few seconds of glancing at one column each morning, is the entire ongoing maintenance cost of a $3,484 four-month saving.