Prompt Caching in practice: from €280 to €47 per month

Redaktion · · 4 Min. Lesezeit

At one of our customers — a mid-sized insurance platform — a Claude Sonnet-based assistant for internal claims handlers had been running since February. The bot answers product and tariff questions, based on a ~25,000-token prompt: system instructions, glossary, tariff rules, example answers. With every request the entire block is sent again, plus the handler’s specific question and possibly some customer master data. In total 1,200–1,800 requests per day.

The February bill: €283.40. In March, with slightly more usage: €312.10. Not dramatic, but noticeable for an internal tool — and worse, it scales linearly with usage.

What we changed

In April we switched on prompt caching. Concretely: we marked the ~25,000-token block at the start of the prompt as cache_control: ephemeral. The first call of a day builds the cache (paying the full input price plus a 25 % caching surcharge); all subsequent calls within the 5-minute TTL use the cache and pay only 10 % of the regular input price for that block.

The only code change was an additional field in the API call — no architectural rebuild, no new service, no extra cache layer on our side.

The numbers

| | February (no cache) | April (with cache) | Delta | |---|---|---|---| | Requests | ~42,000 | ~44,000 | +5 % | | Input tokens (regular) | 1,050 M | 88 M | -92 % | | Input tokens (cache write) | 0 | 12 M | — | | Input tokens (cache read) | 0 | 950 M | — | | Output tokens | 21 M | 23 M | +10 % | | Total bill | €283 | €47 | -83 % |

Output tokens rose slightly (more requests), but the main cost driver — input — dropped by 92 %. The 88 M regular input tokens correspond to requests that arrived outside the 5-minute TTL — mostly mornings and after longer breaks.

What we learned

Cache TTL is the most important lever. Anthropic offers a 5-minute TTL by default and a 1-hour TTL at a surcharge. With our load profile (continuous use during the day) the 5 minutes are enough — but for sporadic usage, the 1-hour variant would be cheaper despite the surcharge.

Cache position is not trivial. The cached block has to sit at the start of the prompt. We initially put master data before the 25k block — that broke the cache on every new request. Master data belongs at the end, before the actual question.

Set up monitoring beforehand. Anthropic logs cache hit rates in the console. After day 2 ours sat at 87 %. Had it stayed below 50 %, caching would not have paid off — the write surcharge quickly turns it into a loss.

When it doesn’t pay off

We also tested caching with a second customer: an app with highly variable, user-specific prompts and no stable prefix. Cache hit rate there: 12 %. Effect on the bill: +7 % (because of the write surcharge).

Practical rule of thumb: pays off when the stable prompt portion has at least 1,024 tokens (Anthropic’s minimum), the cache hit rate is expected to be above 60 %, and the same prefix is shared by many consecutive requests.

Bottom line

Prompt caching is by far the most effective pricing lever we know — when the load profile fits. 83 % savings without architectural change is rare. We recommend every team with a stable system prompt of ≥ 5,000 tokens to evaluate it properly once.

The other levers — tier mix, batch API — typically yield 30–60 % savings and require more effort. Caching is the low-hanging fruit. More on all three levers in the lexicon article.

Entdecke mehr