- In short
- Modeling cache economics means weighing cache write overhead against call frequency and prefix size rather than enabling caching by default. Whether caching a prefix pays off depends on how often it is reused and how large it is, and must be modeled, not assumed. A cache time-to-live that is too short forces repeated writes for a prefix reused often enough to have paid off with a longer TTL, and low-frequency, small-prefix requests are exactly where write overhead can exceed savings.
Caching has a cost, so it is a decision
Correct ordering makes a cache hit, but hitting is not the same as paying off. The Claude Certified Architect - Professional (CCAR-P) exam pushes to the evaluate level here: you have to decide whether caching a given prefix is worth it at all. Caching write overhead is not free. Writing a prefix to the cache costs something, and that cost is only recovered if the prefix is reused enough to amortise it. Whether caching pays off therefore depends on two variables, call frequency and prefix size, and the exam wants those modeled rather than assumed. This builds on the mechanics of prompt caching prefix matching and the ordering discipline of content ordering for cache hit rate; those make the cache hit, this decides whether making it hit is worthwhile.
- Cache economics and TTL tradeoffs
- The discipline of deciding whether to cache a prefix by modeling its write overhead against call frequency and prefix size, rather than enabling caching by default. A large, frequently reused prefix amortises the write overhead; a small, rarely reused prefix may not. The cache time-to-live should be set from the observed reuse interval, because a TTL too short forces repeated writes for a prefix that a longer TTL would have kept warm.
The write overhead has to be earned back
The core economic fact is that caching a prefix incurs a write cost, and that cost is recovered only through subsequent cache hits. Two variables govern whether it is recovered. Call frequency: the more often the prefix is reused before it expires, the more hits share the one write, and the more easily the overhead is amortised. Prefix size: the larger the cached prefix, the more each hit saves, so a big prefix pays back its write faster. Put them together and the good cases are obvious, a large prefix reused frequently is a clear win, and so are the bad ones. A small prefix used rarely may never see enough hits to recover its write overhead, which is exactly where caching is the wrong optimization to reach for by default. The point is that this is a calculation, not a reflex; you model frequency and size before enabling caching, not after the bill surprises you.
TTL follows observed reuse
The cache time-to-live is the second lever, and it should be set from the observed reuse interval for that specific prefix, not from a guess. TTL is how long a cached prefix stays warm before it expires and must be rewritten. Set it too short and a prefix that is actually reused often enough to justify caching expires between uses, forcing a fresh write each time and paying the write overhead repeatedly for a prefix a longer TTL would have kept available. Set it based on how often the prefix is really reused, and each write is amortised across the hits that occur within its lifetime. Guessing the TTL, in either direction, either wastes writes on premature expiry or holds a prefix warm longer than its reuse justifies. The disciplined move is to measure the reuse interval and set the TTL to match it, the same measure-don't-guess ethic that runs through eval-gated model swaps.
What the exam trips candidates on
The two traps are the two ways teams skip the modeling. The first is enabling caching on every prompt asset by default without modeling whether call frequency justifies the write overhead. A scenario will cache everything reflexively; the credited reading models frequency and size and declines to cache where the overhead exceeds savings. The second is setting a cache TTL based on a guess rather than on the observed reuse interval for that specific prefix. A scenario will pick an arbitrary TTL; the credited reading sets it from measured reuse.
Worked example
A platform team enables prompt caching on every prompt asset across all their services by default and sets a uniform short TTL for all of them. Some low-traffic services with small fixed prompts see costs rise slightly after the change. Evaluate the two decisions.
Both decisions skipped the modeling the economics require, and the low-traffic services are where that shows.
Enabling caching on every asset by default is the first trap. Caching a prefix costs a write, recovered only through enough subsequent hits. On the low-traffic services with small fixed prompts, both variables work against recovery: call frequency is low, so few hits share each write, and the prefix is small, so each hit saves little. That is precisely the combination where write overhead can exceed savings, which explains why those services saw costs rise slightly rather than fall. The correct approach models frequency and prefix size per asset and caches only where the model shows the overhead is recovered; the high-traffic, large-prefix services likely benefit, while the small, low-traffic ones should not have caching enabled by default at all.
The uniform short TTL is the second trap. A TTL should come from the observed reuse interval of each specific prefix, and a single guessed value cannot fit prefixes with very different reuse patterns. Where a prefix is actually reused just outside the short TTL window, it expires between uses and is rewritten every time, paying the write overhead repeatedly for a prefix a longer TTL would have kept warm. Setting each TTL from measured reuse, longer for prefixes reused at longer intervals, amortises the writes correctly.
The overall evaluation: caching is a modeled decision per asset, not a global switch, and TTL is a measured value per prefix, not a uniform guess. The slight cost rise on the small, low-traffic services is the predictable result of skipping both.
Common misreadings to avoid
Misconception
Caching is free savings, so enable it on every prompt asset by default.
What's actually true
Misconception
A single short TTL is a safe default for all cached prefixes.
What's actually true
How this shows up on the exam
Evaluate-level questions present a caching rollout and ask whether it was worth it or how to set TTL. The reliable answer models write overhead against call frequency and prefix size, declines to cache low-frequency small-prefix requests, and sets TTL from the observed reuse interval rather than a guess.
This knowledge point completes the caching arc from prompt caching prefix matching and content ordering for cache hit rate, and it shares the measure-don't-guess discipline of eval-gated model swaps. Together with Skills as a governed integration mechanism, it rounds out the reuse-mechanism decisions in this task statement.
A team enables prompt caching on every asset by default and sets one short TTL for all of them. Low-traffic services with small fixed prompts then see costs rise slightly. What is the best evaluation?
People also ask
Is prompt caching always worth enabling?
What determines whether caching pays off?
How do you set a cache TTL?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.