Monday, May 25, 2026 · 9:41 AM
ok dumb question: Claude prompt caching is just “don’t resend the same giant prompt,” right?
close. the dangerous word is same.
prompt caching reuses an exact prefix of your request. same beginning, cheaper next time.
prefix meaning tools, system prompt, old messages, that whole front chunk?
yep. the order is tools → system → messages.
think prefix fast lane. Claude has already checked the first group, so the next request can move that group through cheaper.
wait, so if i put a timestamp near the front, the fast lane explodes?
basically yes.
anything that changes every call belongs after the cached prefix: timestamps, request ids, fresh user question, random JSON order, retrieved snippets.
ok so stable giant stuff first, chaos later
where does the cache marker go?
at the end of the stable prefix.
if your prompt is “big docs + timestamp + user question,” put the breakpoint after the docs, not after the question.
because then request 2 has a different question and misses
right. you cached the wrong shape.
Claude can look back for prior cache entries, but it only finds entries that were actually written at breakpoints.
so it won’t magically discover the stable docs hiding behind my timestamp
nope. that’s the trap.
lookback is up to 20 blocks per breakpoint, and you get up to 4 breakpoints.
automatic caching uses one of those?
if you combine automatic with explicit breakpoints, yes.
writes cost extra, reads are cheap.
5-minute writes are 1.25× base input, 1-hour writes are 2×, cache reads are 0.1×.
so first call has a cover charge, later calls get the discount
exactly.
default TTL is 5 minutes, and hits refresh it for no extra cost.
when do i pay for 1 hour?
when the prefix is expensive and the reuse gap is usually longer than 5 minutes: repo context, big docs, shared tool schemas, agent instructions.
how do i know it worked instead of just feeling spiritually cached?
check usage fields.
cache_creation_input_tokens means written. cache_read_input_tokens means read. input_tokens is the fresh uncached tail.
total input is all three added together?
yes. don’t stare at input_tokens alone and think the model only processed 50 tokens.
what else makes people think caching is broken?
tiny prompts may silently miss the minimum. model/platform minimums vary, so check usage instead of guessing.
also exact matching is strict. tool changes, system changes, images, speed settings, citations, tool_choice, even unstable tool-use JSON can affect hits.
does caching make Claude stale? like old answer reused?
no. output generation is the same. caching changes cost and latency for repeated input, not the answer policy.
max_tokens: 0 can warm the cache before real traffic, with limitations. useful for latency-sensitive online requests, not a magic batch trick.
workspace-level isolation, ZDR eligible, memory-only cache representations/hashes. still treat prompts like production data.
so my implementation rule: stable prefix first, breakpoint before the changing tail, verify with usage fields
yep. if your timestamp is inside the cached prefix, you built an expensive fast lane with a new entrance every time.
Read Mon, May 25 · 10:03 AM