DeepSeek API Context Caching: Prefix Hits & Cost Control

Introduction

Search DeepSeek API context caching, and many people assume you must hand-write cache_control breakpoints like other vendors. You do not.

DeepSeek API context caching on disk is on by default: once a matching prefix is persisted, overlapping input on later requests bills as a cache hit — usually far cheaper than a miss. This site is an independent community; treat the official Context Caching guide as source of truth, and the pricing page for hit/miss rates and peak windows.

I. What Context Caching Is — vs “Cache Hit” on the Price Card

The “input · cache hit / miss” rows on the rate card are the billing outcome of this disk cache — not a separate product.

In short: you do not change the API surface; you change how you order messages. Only prefixes identical from token 0 can hit; a variable inserted mid-prefix breaks everything after it. Rates and off-peak: DeepSeek API price change. Entry point: DeepSeek API.

Published CNY per million tokens (verify on the official page):

Model	Cache hit · off-peak / peak	Cache miss · off-peak / peak
deepseek-v4-flash	0.05 / 0.10	1.5 / 3.0
deepseek-v4-pro	0.15 / 0.30	4.5 / 9.0

Hit rates remain the cheapest input tier; miss + output + peak thinking are the expensive parts.

II. Hit Rules: Full Prefix Units, Not Fuzzy Similarity

Official essentials:

1. Persist first, then hit. After a prefix is written to disk, later requests must fully match a cache prefix unit.
2. Persistence triggers include: end of user input / end of model output; common-prefix detection across requests; fixed token intervals on long text (so huge prefixes are not stuck forever).
3. Best effort. No 100% hit guarantee; build is seconds-scale; unused entries clear automatically (often hours to days).
4. Output still computes. Cache only helps the input prefix; answers still run inference — thinking mode still burns output tokens: DeepSeek thinking mode.

Classic patterns:

• Multi-turn chat: round two carries the full prior prefix → often hits what round one persisted.
• Long-doc Q&A: same report, different questions; keep stable system + document body first, question last → later rounds can hit the shared prefix.

III. How to Order Messages So Hits Stick

Practical checklist (no new parameters):

1. Stable content first: system, tool schemas, persona, repo notes, long document body.
2. Volatile content last: this-turn user question, timestamps, session ids, random few-shots.
3. Do not inject variables mid-prefix: e.g. writing “current time” into system every turn splits the hit.
4. Multi-tenant user_id: enables KVCache isolation (privacy); caches do not share across users — see DeepSeek API 429 rate limit.
5. Watch hit rate via usage:

usage = response.usage
hit = usage.prompt_cache_hit_tokens
miss = usage.prompt_cache_miss_tokens
rate = hit / (hit + miss) if (hit + miss) else 0
print(hit, miss, f"{rate:.0%}")

prompt_tokens = hit + miss. If hit rate stays near 0, check byte-stable prefixes first, then whether the prefix is too short / too new to have persisted.

IV. Stacking with Off-Peak, Flash/Pro, and Agents

Lever	Controls	Relation to cache
Context cache	Input-prefix unit price	On by default; message layout
Peak pricing	Peak vs off-peak on the same tier	Hit price at peak is still ~2× off-peak
Flash vs Pro	Model and concurrency tier	Flash hits are cheaper; higher throughput
Lower reasoning_effort	Output / chain-of-thought	Cache cannot save “thinking too long”

Agents / Codex burn many turns: keep system prompts and tool defs fixed; append only new observations each turn. Wiring: DeepSeek Codex setup.

V. FAQ

Do I need to enable caching separately?
No. It is on for all users, with no extra storage fee; billing follows actual hit / miss.

Can a repeated mid-prompt fragment hit?
No. You need a full prefix-unit match aligned from the start.

Does caching change answer quality?
Officially the same as without disk cache; randomness still comes from sampling (some knobs are ignored in thinking mode).

Is the old “¥0.1 / M hit” headline still valid?
That was early promo pricing. Use the current peak/off-peak table on the pricing page; the table above was checked against it when written.

Summary

Shortest DeepSeek API context caching path: on by default → stable prefix first → verify with prompt_cache_hit_tokens → then stack off-peak and Flash/Pro. Official docs own the mechanism; this page is a layout and metering checklist.

Further reading

• DeepSeek API
• DeepSeek API price change
• DeepSeek API 429 rate limit
• DeepSeek thinking mode
• DeepSeek Codex setup