The rates that matter
Per million tokens on current Anthropic models (verify on the provider pricing page):
claude-sonnet-4-6 input $3.00 cache write $3.75 cache read $0.30
claude-opus-4-8 input $5.00 cache write $6.25 cache read $0.50
claude-haiku-4-5 input $1.00 cache write $1.25 cache read $0.10OpenAI’s caching is automatic with no separate write charge, reads simply bill at the discounted cached input rate. Gemini similarly discounts cached input on current models. The full current table, including every cached rate, is live at useweckr.com/pricing.json and explained in the LLM pricing JSON feed.
The break even math
For a cached block of C tokens written W times and read R times on Anthropic, against sending it fresh every time:
without caching: (W + R) * C * input_rate
with caching: W * C * 1.25 * input_rate + R * C * 0.10 * input_rate
break even: one read per write already wins.
heavy reuse: savings approach 90% on the cached portion.Worked example on Sonnet: a 5,000 token system prompt over 1,000 calls. Fresh every time: 5M input tokens, $15. Cached with a stable prefix (one write, 999 reads): $0.019 for the write plus $1.50 for the reads, about $1.52. That is 90 percent off the dominant cost of the feature. Now the trap: the same prompt with a timestamp interpolated at the top becomes 1,000 writes and zero reads, $18.75, which is 25 percent worse than not caching.
The stable prefix rule, and the drift that breaks it
- Order the prompt cache first: system prompt, tool definitions, few shot examples, all byte stable, then user specific context, then the message. Anything dynamic above the cache marker invalidates everything below it.
- Watch for silent breakage. A teammate adds the current date to the system prompt, an A/B test varies one example, and every call quietly becomes a write. Nothing errors; your bill just rises 25 percent on the cached portion. This is a close cousin of the version drift in LLM cost per prompt version.
- Mind cache lifetime. Entries expire after minutes of disuse, so low traffic features may pay writes repeatedly. Caching favors hot paths.
- Collect the throughput dividend. Cache reads generally do not count against input tokens per minute, which relieves exactly the meter that pinches long prompt apps, per Anthropic rate limits.
Verify it, per feature, from usage data
Usage objects report cached reads, cache writes, and fresh input separately, so cache performance is measurable per call. Log those fields with your feature tag and the questions answer themselves: what is the hit rate per feature, what did caching save this month, and did last week’s prompt edit break the prefix. Weckr logs cache token counts on every call and prices them at the correct cached rates in its server side cost recompute, so the savings, or the silent breakage, show up in your per feature cost instead of surprising you at the invoice.
FAQ
How much does prompt caching save?
On Anthropic, cache reads bill at roughly a tenth of the normal input rate, so a stable 5,000 token system prompt read from cache costs about as much as 500 fresh tokens. On OpenAI, caching is automatic and reads are discounted heavily on current models. The catch on Anthropic is the write premium: creating a cache entry costs about 1.25 times the input rate, so caching only pays when the cached content is actually reused.
When does prompt caching lose money?
When you pay the write premium without harvesting reads. On Anthropic, content cached once and reused zero times costs 25 percent more than not caching at all. Prompts that change slightly on every call, dynamic timestamps or per request context mixed into the cached block, break the cache and turn every call into a fresh write. Stable prefix, dynamic suffix is the rule.
What is the break even point for Anthropic prompt caching?
Roughly: the write costs 1.25x input and each read saves about 0.9x input, so one reuse within the cache lifetime already puts you ahead, and heavy reuse approaches the full 90 percent discount on the cached portion. The formula is writes times 1.25 plus reads times 0.1, compared against total sends times 1.0 without caching.
Does prompt caching help with rate limits too?
On Anthropic, cache reads generally do not count against input tokens per minute on current models, so caching buys throughput headroom as well as cost savings. For long system prompts, that can matter as much as the money, especially on lower usage tiers where input token limits pinch first.
How do I verify caching is actually working and saving money?
Measure it, do not assume it. Usage objects report cached token counts separately from fresh input, so log cache reads, cache writes, and fresh input per call, then compare real cost per call before and after. A cache hit rate visible per feature catches the silent failure mode where a prompt edit quietly broke the prefix and everything became writes again.
Keep reading
Cache with your eyes open
Caching is the rare optimization that can also quietly cost you money, which makes it exactly the kind of thing to measure rather than trust. Weckr shows cached versus fresh tokens and real cost per feature from two lines of integration, free for 50,000 requests a month. See it on the live demo, or start with the AI cost and margin guide.