System-prompt caching alone cut repeat-call costs by half
Tool definitions cache separately, perfect for agent loops
Conversation history caching pays off after turn three
1-hour TTL beats the default 5 minutes for batch jobs
My Anthropic API bill dropped 70 percent last month and I did not change a single model. I changed where the cache breakpoints went. Here are the five patterns I now use on every Claude integration I ship.
Pattern 1: Cache The System Prompt First
The system prompt is the cheapest win and most people skip it. My agents run with a 4,000 token system prompt that explains the role, the output format, the safety rules, and a few examples. That prompt never changes inside a session. Before caching, I paid full input price for those 4,000 tokens on every single call. With an agent that loops 30 times to finish a task, that is 120,000 tokens of pure repetition.
The fix is one parameter. I add a cache_control block with type: "ephemeral" to the last content item in the system prompt array. The first call writes the cache and costs slightly more (cache writes carry a small premium). Every call after that reads the cache at roughly one tenth the input price.
Here is the rule I follow: the cached block has to be at least 1,024 tokens for Claude Sonnet, or it gets ignored silently. My 4,000 token prompt clears that easily. If your system prompt is short, this pattern does nothing, so do not bother adding the breakpoint to a 200 token instruction.
The order matters more than people expect. The cache works as a prefix. Everything before the breakpoint gets stored. Everything after it is read fresh. So I put the stable stuff (role, rules, examples) up top and the volatile stuff (user query, current date) down below the breakpoint. Reorder this wrong and your cache hit rate collapses because the prefix changes on every call.
One real number from my logs: a document-classification job that runs 2,000 times a day. The system prompt is 3,800 tokens. Caching it saved me around 6.8 million billed input tokens daily. That is the single largest line item I cut. If you only do one thing from this article, cache the system prompt. It took me four minutes to add and the savings showed up in the next billing window.
I covered the broader setup in . It goes through the message-management side in more detail. The short version: append-only history plus a moving breakpoint is the combination that works.
Pattern 4: Use The 1-Hour TTL For Batch And Bursty Work
The default cache lifetime is five minutes. Every cache read resets that clock, so an active conversation keeps the cache warm on its own. The problem is bursty or scheduled work. If your job pauses for seven minutes between batches, the cache expires and you pay the write premium again on the next batch.
Anthropic offers a one-hour TTL. You opt into it per cache block by setting the TTL on the cache_control object. The write costs a bit more than the five-minute write, but the cache survives gaps up to an hour with no reads at all.
I use the one-hour TTL on three kinds of work. First, scheduled batch jobs that run every few minutes against the same system prompt. The five-minute cache kept dying in the gaps; the one-hour cache stays alive across the whole batch window. Second, user sessions with long think-time, like a research tool where someone reads a 2,000 word answer for ten minutes before replying. The five-minute cache was always cold by their next message. Third, multi-stage pipelines where stage one finishes, a separate process does work for several minutes, then stage two reuses the same cached context.
The decision is simple arithmetic in your head. If your average gap between calls is under five minutes, the default is free and fine. If your gap is regularly between five minutes and an hour, the one-hour TTL almost always wins despite the higher write cost, because you avoid repeated full-price rebuilds. If your gap is over an hour, no caching strategy helps and you should accept the fresh cost.
One detail that bit me: the TTL applies to the specific breakpoint. So if I have a one-hour system prompt cache and a five-minute history cache, they expire independently. I had a job where the history cache died but the system cache lived, and the partial cache hit confused my cost dashboard until I aligned both to one hour.
For scheduling the social side of all this around batch windows, I run posts through goes through how I wire this logging into the rest of the stack.
If your image pipeline also hits an API, the same prefix logic applies; I use is where I keep the running notes.
This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)
SOCIAL SHARE CARD GENERATOR