DeepSeek prompt caching: cheap base price, same prefix rules
DeepSeek has the lowest base input price of the providers modelled here, which changes the absolute dollars but not the mechanism: an unstable prefix still re-bills in full.
The numbers
| Value | |
|---|---|
| Base input price | $0.28 / MTok |
| Cache read | 0.1× base → $0.03 / MTok |
| Cache write | 1× base → $0.28 / MTok |
| Minimum cacheable prefix | 1,024 tokens |
| Breakeven | 0.00 reads per cached write |
Cache writes are free here (1× base), so there is no write premium to recoup — a cache hit is pure saving from the first read. The failure mode on this provider is not breakeven, it is a prefix that never stabilises, so the cache never engages at all.
What breaks the cache
Caching is an exact-prefix match. The first changed byte invalidates everything after it, and no provider raises an error. In 236 production system prompts:
- 76 (32.2%) rendered a date or time inside the cached prefix
- 68 (28.8%) were below the minimum cacheable length
- 36 (15.3%) carried a prefix far larger than it needed to be
- 27 (11.4%) kept mutable working memory inside the prefix
The fix
Order the request so the cached span is byte-identical on every call:
static system instructions ← cached tool definitions ← cached, breakpoint here --- cache breakpoint --- volatile context, dates, IDs ← after the breakpoint user message ← never cached
Content after the breakpoint costs only its own write. The same content before it invalidates everything downstream. Same bytes, different order, completely different bill.
Check your own prompt
Paste a system prompt or a raw API request. Get a score, the offending lines, and a modelled monthly cost. Runs in your browser — no API keys, no account, nothing leaves the page.
Run the audit →Or gate it in CI: npx prefix-audit prompts/ --provider deepseek