You have AI working on the same project every day.
But each time you send:
Company policies.
Product descriptions.
Workflow details.
20 pages of background documents.
Tool definitions.
Plus today’s new questions.
It looks complete.
The problem is:
AI might be re-reading a large amount of unchanged information every single day.
With Claude Fable 5.1 significantly reducing Prompt Cache Read prices,
today’s lesson is just one thing:
Split your prompt into “fixed background” and “new additions for today.”
Don’t mix everything into one big prompt every time.
Clarification: This article mainly targets API/Agent workflows
If you just open the regular Claude App to:
Chat.
Write articles.
Ask questions.
You don’t need to manually manage:
“Prompt Cache”
settings.
Today’s discussion on Prompt Caching mainly applies to Claude API and developers building Agents, apps, or automated workflows.
In other words:
Your system calls Claude frequently,
with many repeated background materials.
That’s when caching is especially worth managing.
Why does Fable 5.1 make this suddenly more important?
The standard input price of Fable 5.1 is:
$10 per million tokens.
But for cache hits,
it’s now only:
$0.25 per million tokens.
That’s down from $1 per million tokens in Fable 5,
a
75% reduction.
Note:
This doesn’t mean:
If you use Fable 5.1,
all input costs drop by 75% automatically.
Only the portion of context
read repeatedly from cache
is charged at the lower cache read price.
So the first question isn’t:
“Should I turn on cache?”
It’s:
“Which parts of my prompt actually never change?”
Step 1: Identify your “fixed background”
Suppose you’re building a customer service Agent.
Each request needs to know:
The company’s brand tone.
Refund policies.
Product information.
Customer service restrictions.
Tool definitions.
Five sample response templates.
These elements likely:
Remain unchanged today.
Remain unchanged tomorrow.
Remain the same for the next customer interaction.
This is your
fixed background.
Put all these at the front of your prompt.
Don’t scatter them throughout with today’s new questions.
Step 2: Put “today’s new additions” at the end
Then add:
This customer’s questions.
New order data today.
New documents added today.
The actual task to complete this time.
For example:
Fixed background:
Brand rules.
Product specs.
Refund policies.
Tool descriptions.
Customer service samples.
Today’s new items:
“The customer reports the product arrived damaged; order details as follows…”
This structure means:
The front is a large, long-term stable section,
with only today’s new data at the end.
This is the structure where prompt caching really generates value.
Why does the order matter?
Anthropic’s prompt caching works as a
Prefix Cache.
A prefix is the beginning of the prompt.
The system checks the start of the prompt to see if that content has been processed before.
If your prompt is organized as:
Fixed rules.
Fixed documents.
Fixed examples.
Today’s new question.
And next time it’s:
Fixed rules.
Fixed documents.
Fixed examples.
Tomorrow’s new question.
That large front section can be reused from cache.
However, if each time you put:
Date.
User name.
Today’s order.
At the front,
even if the fixed data following it is the same,
that stable prefix you hoped for may not form properly.
Simple way to organize
Don’t think about code at first.
Write down on paper:
Fixed background:
Role descriptions.
Long-term rules.
Tool definitions.
Major reference materials.
Fixed examples.
Project background.
Today’s new additions:
New questions.
New data.
New documents.
Output requirements for this run.
Once this split is clear,
developers will know:
Which parts should be cached.
Step 3: Don’t tweak the fixed background little by little every time
This is very important.
Suppose your fixed background was originally:
Product document A.
Product document B.
Product document C.
Next time you just swap
B and C’s order.
To humans:
The data remains the same.
But to prefix caching,
the front sequence has changed.
Anthropic officially explains:
Cache entries are created based on prompt prefixes.
If the content before the cache breakpoint changes,
a different cache may be created on the next call.
So:
If you want reuse, keep the repeated part stable.
Don’t reorder your prompt each time just for neatness
Many people dynamically generate prompts when building agents.
For example, today:
Rules → Documents → Examples.
Tomorrow:
Examples → Rules → Documents.
Or even reorder documents alphabetically each time.
The content looks the same.
But this reduces cache reuse efficiency.
So add this workflow rule:
Keep fixed content in fixed order.
Put truly variable parts
at the end.
Step 4: How does the API know which part to cache?
Claude API now has two main ways.
The first, simpler:
Automatic Caching.
Enable Cache Control in the request,
the system automatically handles suitable cache prefixes.
The second:
Explicit Cache Breakpoint.
You explicitly tell the system:
“Everything before here is fixed content I want to reuse.”
If your prompt structure is clear,
e.g.,
The first 80,000 tokens are permanent project background,
only today’s question changes at the end,
Explicit breakpoints offer more precise caching.
One basic principle for beginners
Don’t dive into every cache parameter first.
Start by organizing your data structure right.
That is:
Put unchanging parts first.
Put changing parts last.
Once this structure stabilizes,
you can explore:
Automatic Cache.
Breakpoints.
5-minute TTL.
1-hour TTL.
Otherwise, even with caching enabled,
if prompts keep changing randomly,
the effect will be poor.
What content can be cached?
Anthropic officially supports caching many types of content, including:
Tool definitions.
System messages.
General text messages.
Images.
Documents.
Tool uses.
Tool results.
So prompt cache isn’t just:
“Cache a single system prompt line.”
In large agents,
the most valuable cached content may be:
Long tool definitions.
Project documents.
Extensive fixed backgrounds.
Cumulative conversation context.
Does that mean everything should be cached?
Not necessarily.
If data changes every time, like:
Today’s stock price.
Real-time inventory.
New customer messages.
Current orders.
Today’s news.
Trying to treat these as fixed context
won’t be meaningful.
The best candidates are:
Repeated.
Stable.
Large enough.
A short 20-word fixed prompt
may not offer real cost savings even if cached.
First cache use isn’t always cheaper
This is often misunderstood.
The initial cache creation requires the system to:
Read.
Process.
Then build the cache.
Cache writes have a cost.
Anthropic’s 5-minute cache write costs
are 1.25 times the normal input price.
So the first use
might not be cheaper.
Real savings come from:
Subsequent calls hitting the same cache.
It’s like signing up for a membership card.
If you only visit once,
it might not be worth it.
If you use it repeatedly,
that’s when value appears.
Default cache duration?
Anthropic Prompt Cache default TTL is:
5 minutes.
TTL (Time To Live) means:
How long the cache remains valid.
Each successful use refreshes this timer.
If your workflow has longer intervals,
Anthropic also offers:
1-hour cache.
But 1-hour cache writes cost more.
So longer duration doesn’t always mean better.
It depends on how often your Agent uses the same background again.
When is 5 minutes enough?
For example, an Agent doing:
Continuous code reviews.
Batch processing customer service cases.
Repeatedly referencing the same document.
Multi-step workflows with frequent model calls.
These tasks reuse the same context repeatedly within minutes.
Five minutes is reasonable.
When to consider 1 hour?
For example:
Research agents.
A side Agent running long tasks.
Users responding only every 20 to 30 minutes.
Processing batches of work periodically.
Each time requiring the same large context again.
This might justify 1-hour caching.
It’s not because:
“1 hour is more advanced.”
Step 5: Don’t guess if cache worked, check usage
After setup,
the crucial next step is:
Verification.
Claude API usage data provides:
Cache Creation Input Tokens.
And:
Cache Read Input Tokens.
If after the second call,
Cache Read Input Tokens appear,
it means content was truly read from cache.
If always zero,
don’t tell yourself:
“Cache must be working.”
Possible reasons include:
Prompt too short.
Prefix has changed.
Breakpoint is misplaced.
TTL expired.
Or other settings causing cache misses.
Cost optimization isn’t just about the total bill
Suppose today’s model bill is:
$100.
Tomorrow:
$80.
You still don’t know the real reason.
Could be:
Lower usage.
Shorter outputs.
Switched models.
More cache hits.
More failed jobs.
It’s better to track together:
Input tokens.
Cache read tokens.
Output tokens.
Completion rates.
Manual edits.
Cheap but frequently wrong is not truly cheap.
A simple practical example
Imagine your Agent needs:
80,000 tokens of fixed product data each time.
Today’s new question uses only:
2,000 tokens.
Previously, each time processed:
About 82,000 tokens.
If the fixed 80,000 tokens are successfully read from cache,
The actual input cost is mainly for:
The small new segment.
Note:
Actual billing also depends on:
Cache writes.
Output.
Model choice.
TTL.
And other settings.
This just explains:
Why splitting fixed background and new data allows cache to provide value.
Common mistake: Keeping outdated data forever for caching
Don’t go to the other extreme.
If:
Product rules change.
Company policies update.
Documents expire.
Tool definitions are revised.
You should update the fixed background.
Even if that causes creating new caches.
Don’t save a few tokens by continuing to make AI read:
Outdated, wrong rules.
Accuracy always beats cache hit rate.
So what should remain fixed is the “valid version”
Fixed background means:
Not that it can never change,
but:
It stays stable as long as the version remains unchanged.
For example:
Customer service rules v3.
As long as v3 is valid,
keep the order and content the same.
Once officially updated to v4,
establish a new fixed context.
This way you can:
Reuse cache efficiently,
and avoid locking in outdated data permanently.
One thing to do today
If you have a Claude API or Agent workflow,
don’t rush to change code yet.
Open your current prompt.
Label each section as:
Fixed.
Or:
New.
Then rearrange as:
Fixed rules.
Fixed tools.
Fixed background documents.
Fixed examples.
────────
Today’s new data.
Today’s new questions.
Output needed today.
Once you do this,
you’ve started shifting from:
“AI understands the whole world each time anew”
to:
“Background is known, today only new things are processed.”
This is where prompt caching truly shines.
Not because AI thinks less,
but because:
You stop paying for AI to reread the same background over and over.
Today, improve alongside AI.
Learn one AI tip a day.
Save a bit of time daily.
Improve your skills little by little every day.
SasaDaily grows with you.
