Prompt caching is a pricing mechanism some AI providers offer: content you send repeatedly (system prompts, tool definitions, project background) gets stored temporarily, so the next time the exact same content shows up, you're billed the cheaper "cache read" rate instead of the full "input" rate. But writing to the cache also costs money โ if your content prefix isn't stable enough or your hit rate is too low, the write cost can exceed what you save on reads, and your total bill goes up instead of down. That's exactly the counterintuitive finding from a systematic test of 5 context-management strategies by YouTube channel Atef Ataya.
This article breaks down: what caching actually saves, under what conditions it backfires into a cost, and โ beyond caching โ a more fundamental spending order worth considering first.
What does prompt caching actually cache?
Most LLM APIs split a single call into "input tokens" and "output tokens" priced separately, and caching further splits the input side into two states: cache write (cache creation) and cache read. The first time a piece of fixed content is sent, the system has to store it, and that cost is usually equal to or higher than the normal input price. After that, whenever the exact same content shows up again at the front of a request, the system hits the cache and bills the much lower "read" rate instead.
In other words, caching doesn't save you money on the content itself โ it saves you money on repetition. If a piece of content is different every single call, the cache can never hit, and you've paid a write fee for a discount you'll never collect.
Where should the cache go? Stable prefix vs. task data
The test emphasizes one ordering rule in particular: put content that never changes at the very front of the request โ system rules, tool definitions, fixed project or codebase descriptions โ and put data that changes every call after it. The logic is straightforward: caching works by checking whether the prefix matches character-for-character. The moment one character up front differs, everything after it can't be saved even if it's identical. Mixing volatile content in front of stable content is effectively sabotaging your own cache chain.
Conversely, if a project has few tool definitions and its background description gets rewritten with every task, the "stable prefix" the cache can grab onto is inherently short โ and the upside of turning caching on is limited from the start.
Why did cache reads drop while the bill went up?
This is the most counterintuitive part of the whole test. In the experiment where caching was manually added, "cached input" volume did drop by roughly 15% โ which sounds like it should save money โ but overall cost rose by about 7% anyway. The reason: the savings from fewer reads were eaten by the overhead cache reads themselves generate. When the hit rate isn't stable and the prefix keeps getting broken, the system has to keep re-writing the cache and firing off more read requests, and those scattered extra reads add up to more than what was originally saved.
That's also why caching isn't a feature that "just saves money once you turn it on" โ it's a pricing question that depends heavily on your usage pattern: a high, stable hit rate makes the write cost worth paying for the read discount; a low hit rate turns that same write cost into pure overhead.
How should you pick a cache TTL?
Most APIs that offer prompt caching let you choose how long to keep a cache alive โ and the longer you keep it, the higher a multiple you typically pay on the write cost, in exchange for a longer window during which you can keep hitting the discount. This is fundamentally a risk trade: if you're confident you'll be calling the same prefix repeatedly within a short window, a longer TTL pays off; but if your call frequency is low, or the prefix might change mid-way, the extra write cost you paid may never earn back enough hits to break even.
โ ๏ธ Worth flagging specifically: the video notes that Claude's API currently exposes cache usage through two separate fields โ "cache write tokens" and "cache read tokens" โ and offers two TTL tiers to choose from (the shorter tier at the standard cache price, the longer tier priced at a multiple). This describes how the original video characterizes the mechanism; the actual tier lengths and rate multiples should be verified against Anthropic's current official pricing page, rather than relied on from any single video.
The step that comes before caching: it's not loading smarter, it's not loading at all
The test compared 5 ways to cut context cost, and the one that ranked first โ biggest effect, most consistent โ wasn't any form of caching or clever retrieval. It was the plainest move available: before you touch the task, explicitly decide which files or data you actually need, and don't read anything else. This cut the volume of data sent to the model enough that overall cost came in roughly 30% below the do-nothing baseline, and it was the only strategy that saved money reliably in every single repeated test run.
The logic underneath is simple: caching and structured indexing make "loading" more efficient, but the model still gets billed for every token it loads; filtering and excluding irrelevant data first means part of the token count never gets sent at all โ that money is genuinely never spent. The cheapest token is the one that never made it into the request in the first place.
"Load only when needed" sounds most sensible โ so why did the test show it was the most expensive strategy?
Another common instinct is to start with the bare minimum context, go fetch whatever's needed on demand, and discard it once used โ it sounds like the most resource-frugal approach, but in this test it turned out to be the single most expensive strategy, costing nearly 45% more than the baseline.
The problem is billing mechanics: most LLM APIs bill per full request, and every request has to resend the entire accumulated conversation history so far. "Discard once used" only makes the model "forget" a file's content โ it doesn't make that file disappear from the bill. If a task needs to look at dozens of files one after another, that's dozens of round-trip requests, and every single round trip has to re-attach the entire conversation so far. A strategy designed to "trim" context ends up being the one that retransmits the most context, repeatedly. This is also the specific warning called out in the test: context-management optimization has to look at the total tokens sent across the whole task, not how clean any single request looks.
Why does stacking every cost-saving trick make things worse than doing nothing at all?
Combining all of the above context-management strategies at once is what a lot of playbooks default to recommending, but the test found the fully-stacked combination cost about 23% more than the do-nothing baseline โ worse than using any single strategy alone.
The reason: different strategies fight each other instead of adding up. Running two different kinds of structural analysis at the same time produces duplicate analysis overhead, for instance; and caching and "load only when needed" are built on directly contradictory usage assumptions (one assumes a stable, repeated prefix; the other assumes fragmented, ever-changing content). Turning both on at once just stacks extra setup cost without the savings to match. More isn't the same as cheaper โ every strategy has its own activation cost, and stacking more of them raises the bar you have to clear before any of it pays off.
When is turning on caching actually worth it? One decision order
Pulling all of this together, here's a rough priority order to weigh against your own usage pattern:
1. Filter first, cache second โ before touching the task, clearly define what this specific task actually needs, and exclude everything irrelevant from the request up front. This is the single biggest, most consistently effective step. 2. Second, give the model a lightweight structural map โ a compact directory or dependency outline lets the model locate what it needs without falling back on trial-and-error reads. 3. Caching goes after your architecture decisions, treated purely as a pricing question โ first confirm whether your usage pattern actually has a stable, repeatedly-called prefix; if it does, caching is worth turning on; if content changes often and call frequency is low, caching may just be an extra write fee. 4. Retrieve-on-demand goes last โ only worth considering when the candidate data pool is genuinely huge and what you actually need is a tiny fraction of it; otherwise, per-request billing and repeatedly re-attaching conversation history make it very easy for this to become the most expensive option.
The shared logic behind this order: solve "should this data even be sent" before you solve "can sending it be made cheaper." Caching solves the latter โ and if the former isn't handled first, there's only so much room left for caching to help.
FAQ
Q1: What is prompt caching, and how is it different from normal API call pricing?
Normal pricing splits a call into just "input" and "output" tokens. Once caching is enabled, the input side splits further into "cache write" and "cache read" states: the first time fixed content appears, you pay a write fee; when the exact same content reappears unchanged afterward, it's billed at the lower read rate.
Q2: If I turn on prompt caching, will my bill definitely get cheaper?
Not necessarily. If your content prefix isn't stable enough, or the number of repeat hits isn't high enough, the cache write cost you pay can exceed what the read discount saves โ the test itself found a case where cache read volume dropped but overall cost rose anyway.
Q3: My task content changes a lot โ is caching a good fit for me?
If your task data is different every time with no fixed, unchanging prefix, caching has almost nothing stable to latch onto, and its benefit in that setting is usually limited. Priority should go to filtering which data you actually need first, rather than rushing to turn caching on.
Q4: Should I pick a short or long TTL?
It depends on how frequently you'll be calling the same prefix again in the near future. A longer TTL usually means a higher multiple on the write cost, so it's only worth it if you expect dense, repeated hits in a short window; check the actual tiers and rate multiples against your provider's current official pricing page.
Q5: Besides caching, what other ways are there to cut an AI agent's token cost?
The test found that explicitly filtering "what does this specific task actually need" before you start is the biggest, most consistent win; second is giving the model a lightweight structural map so it spends less effort on trial-and-error reads. Both of these come before caching, because they reduce whether data gets sent at all โ caching can only optimize how cheap sending it is.
Q6: Was this article's test data run on Claude?
The original test used another model provider's (DeepSeek) publicly posted rates across five repeated runs, specifically to keep the comparison about relative cost ratios between different context strategies rather than any one provider's absolute dollar figures. The video separately explains how Claude's API caching mechanism generally works (cache write/read tokens and TTL tiers). The methodological conclusion โ that caching's value depends on hit rate and prefix stability, and that filtering-first beats caching-first โ isn't specific to any one provider, but for the concrete numbers on Claude's official pricing, check Anthropic's current announcement directly.
Source note
This article is based on the video *"I Tested Claude's Prompt Cache. It Cost Me More."* by the channel Atef Ataya, original link: https://www.youtube.com/watch?v=DyzDuiwISa8. The cost-change figures for each context-management strategy discussed here (caching, structural maps, dependency graphs, data filtering, on-demand retrieval, and so on) are drawn from the test methodology and conclusions described in that video. The test itself used another model provider's publicly posted rates as a unified comparison baseline, and the video is explicit that the point of the comparison is the cost ratio between strategies, not any single absolute dollar figure. Where this touches Claude API caching mechanics specifically (TTL tiers, rate multiples), readers should independently verify against Anthropic's current official pricing documentation for accurate, up-to-date figures.
Further reading
Someone Set $1,486 on Fire in AI Tokens to Find Out Where the Money Really Goes
Want a clearer handle on your AI token costs?
Whether you're deciding if prompt caching is worth turning on, or you just want to know how many tokens your agent workflows are actually burning through each month, AI Token King pulls the scattered usage and cost data across different model providers into one dashboard you can actually read and track.
