Insight · November 4, 2026
Stop paying to
read it twice.
Most teams send the same system prompt, tools, and context on every call and pay full price each time. Prompt caching stores the stable part so the model resumes instead of rereading.
01 · The idea
Pay once to read it, then reuse the reading.
Prompt caching stores the processed form of a prompt prefix so the model can reuse it on the next call instead of reading it again. You pay a small premium to write the cache once, then a fraction of the normal price on every hit. It turns repeated context from a recurring cost into a near fixed one.
The reason it exists is simple. Before a model answers, it has to process your entire prompt, and you are billed for every token of it. When the front of that prompt is identical call after call, the system instructions, the tools, the long brief, you are paying to read the same words every time. Caching keeps the work from the first read and serves it back at a steep discount.
02 · How it works
A prefix, a breakpoint, and a short lifetime.
Caching works on prefixes. Anthropic’s documentation describes the flow plainly. The system checks whether a prompt prefix, up to a point you mark, is already cached from a recent query. If it finds one, it resumes from the cached version. If not, it processes the full prompt and caches the prefix once the response starts. The cache covers the request in order, tools, then system, then messages, up to and including the block you tag.
You mark that point with a cache breakpoint. In the Claude API it is a cache_control field placed on a content block. Everything from the start of the prompt up to that block becomes the cached prefix. You can set up to four breakpoints, the docs state, so different parts of a prompt can be cached and updated on their own schedules.
A cache does not live long. The default lifetime is five minutes, and it is refreshed at no additional cost each time the cached content is used, so an active loop keeps its cache warm. Anthropic also offers a one hour duration at additional cost for work with longer gaps between calls. The clock runs from the start of the request that writes or reads the entry.
The one line to keep
“You are not caching the answer. You are caching the reading, the part the model does the same way every time.”
03 · What to cache
From the part that never changes to the part that always does.
01
Tool definitions
The schemas that describe what the model can call. They almost never change between requests, so they sit at the very front of the prompt and get cached first.
02
System instructions
The standing rules, the role, the voice, the format. Written once and sent on every call, which is exactly the shape of content caching was built for.
03
Shared knowledge
The documents, examples, or retrieved passages a model reads on every turn. A long brief or a book chapter is paid in full the first time, then a fraction of that on each reuse.
04
Conversation so far
In a long exchange the history keeps growing. Caching it up to the latest turn means the model rereads the whole thread for almost nothing.
05
The new message
The one part that changes every call. It sits last, after the cache, and it is the only piece billed at the full input price. This is the part you do not cache.
The order is the whole trick. Put the stable content at the front and the variable content at the end, then mark the line between them. Anthropic’s own four breakpoint example caches tools, reusable instructions, retrieved documents, and conversation history as separate segments, each on its own rhythm.
04 · What it is not
Not a bigger window, and not stored answers.
It is not a larger context window. The window is how much the model can read at once. Caching does not change that limit. It changes the cost and the speed of reading the same content inside the window more than once. The prompt is identical with caching on or off. Only the bill and the latency differ.
It is not a cache of answers either. A response cache returns a saved reply when the same question comes in. Prompt caching stores the model’s processed reading of the input, the internal state it builds while working through the prefix, and still generates a fresh response every time. Anthropic notes that this state is held in memory only and is not stored at rest, and that entries are isolated between organizations.
And it is not semantic matching. The prefix has to be identical, token for token, from the start. A single different character near the front means a miss. That is why what you cache and where you draw the line are deliberate choices, not something the model guesses for you.
05 · One result that shows the point
Chatting with a book got faster and far cheaper.
When Anthropic launched prompt caching, it gave a clear example. Chatting with a document held in a 100,000 token cached prompt, the cached version cut the time to first token from 11.5 seconds to 2.4 seconds, a drop of 79 percent, and reduced cost by up to 90 percent. The model still reads the whole book. It just does not pay to read it again on the second question.
The same announcement reported a many shot prompt of 10,000 tokens going from 1.6 seconds to 1.1 seconds, and a long conversation with a large system prompt cut by about 75 percent on latency. Across its documentation Anthropic states prompt caching can reduce costs by up to 90 percent and latency by up to 85 percent for long prompts. Notion is named as a customer using it inside its Notion AI features.
request 1 · write prefix (book, 100k tokens) -> cache_creation_input_tokens new question -> input_tokens (full price) request 2 · read prefix (book, 100k tokens) -> cache_read_input_tokens (0.1x) new question -> input_tokens (full price)
The usage fields the API returns · write once, read cheap after
06 · What breaks it
Change the front, and you pay to read it all again.
Because the cache is a prefix, position is everything. The docs are blunt about it. Changes at any breakpoint invalidate that segment and everything after it, while earlier cached segments stay valid. Edit a word in the system prompt and the whole cache behind it is gone. Put a timestamp or the user’s new message near the front and you never get a hit at all.
So the discipline is to keep anything that varies out of the cached region. The guidance is to place the breakpoint on the last block that stays identical across requests. If a later block changes every call, a timestamp, the incoming message, keep the breakpoint before it. In most cases a single breakpoint at the end of your static content is enough. Reach for more only when different parts change on different schedules.
Watch the usage fields to confirm it is working. The API returns cache_creation_input_tokens for what was written and cache_read_input_tokens for what was read back. If reads stay at zero across a loop, your prefix is not stable, and the cache is costing you the write premium for nothing.
07 · The operator view
A small premium up front, a large discount after.
The economics are easy to read from Anthropic’s pricing. Writing the cache with the five minute lifetime costs 1.25 times the base input price. The one hour lifetime costs 2 times. Reading from the cache costs 0.1 times the base input price for most models, a tenth of what you would otherwise pay to send that content again. You pay a little more once, then far less on every call after.
That math only works past a floor. Short prompts are not cached, and the minimum depends on the model, from 512 tokens on the newer Claude models up to 1,024, 2,048, or 4,096 on others. The break even point is low, though. If a stable prefix is read more than a couple of times inside its lifetime, the write premium is already paid back, and everything after is close to free.
So the operator rule is plain. Caching pays on repeated calls that share a large, fixed front, an agent loop running a long system prompt, a chat over a long document, a pipeline with the same tool definitions on every request. It does not pay on a single call, or when the front of your prompt changes every time. The cost is not hiding in the model. It is hiding in the context you resend, and caching is the lever that is sitting right there.
Closing
The cheapest token is the one you do not resend.
At Bttr. this sits inside product engineering, full-stack systems built for performance and longevity. Before you blame the model for your bill, look at what you send it on every call. Most of it never changed, and you do not have to keep paying to read it.
Written by · November 4, 2026
Donny Smith · ECD, Founder, Bttr.
Over the past 15 years, he has led creative teams and contributed to products used by millions of people worldwide, working with companies including Apple, Opendoor, JP Morgan, GE Aerospace, Pepsi, and Alterra Mountain Company.
LinkedInFacts current as of November 2026 · Anthropic · Prompt Caching, Claude Platform Docs · 2026 · Anthropic · Pricing, Claude Platform Docs · 2026 · Anthropic · Prompt Caching with Claude · 2024
Share this perspective
More insights
Adjacent perspectives.
Bttr. Field Brief
The brief Bttr. writes for senior buyers.
Monthly. One signal worth your time on Brand Operating Systems, AI search visibility, and the infrastructure buildout. No filler.