What must you change in a DeepSeek API request to enable context caching?

## The answer is "nothing", and that is the point Interviewers ask this because candidates who have used other vendors reach for a parameter that does not exist here. On DeepSeek there is no request-side switch for context caching. It is enabled by default for every account, on both the `deepseek-chat` and `deepseek-reasoner` models, and the request body you send is exactly the one you would send if caching did not exist. The only way to know a hit occurred is to look at the response afterwards: `usage.prompt_cache_hit_tokens` reports how much of the input came out of the cache. This matters practically. If your job is to "turn on caching to cut the DeepSeek bill", there is nothing to turn on — the discount is either already reaching you or it is not, and the diagnosis lives in the usage numbers, not in the request. ## The cost model: free storage, discounted hits DeepSeek's context cache carries no storage fee. There is no per-hour charge for keeping a prefix resident and no separate write charge for putting it there. The entire commercial effect is on the input line: tokens that match cached content are billed at a cache-hit input rate that recent price sheets put far below the normal input rate, and everything else is billed normally. Output is unaffected. That free-storage property is unusual enough to be worth stating out loud in an interview, because it changes the calculus. When storage is free and there is no write premium, there is no downside case to worry about — no scenario where a low hit rate makes caching cost you more than not caching. The worst outcome is that you simply pay the ordinary input price. ## The limits that make hits fail Three facts explain nearly every "why did I get zero hits" question. **A 64-token storage unit.** DeepSeek stores cache content in units of 64 tokens; content below that size is not cached. Small prompts — a one-line classification instruction, a short user turn — will simply never register a hit, and that is expected rather than broken. **Automatic eviction.** Cached content that goes unused is cleared automatically after a period of disuse, on the order of hours to days rather than minutes. Nothing in the API lets you pin an entry, extend a lifetime, or pre-warm one deliberately. A workload with long idle gaps between calls of the same shape should expect the first call after each gap to miss. **Per-account scope.** Cache content belongs to your account. Another customer sending an identical system prompt does not warm yours, and yours does not leak to them. This is a common interview probe dressed up as a security question, and the correct answer is that entries are not shared across accounts. ## What you actually control Since there is no parameter, the only influence you have is the shape of the requests you send: how much stable content sits at the front of the prompt, and how consistently that content is byte-identical from call to call. The general design principles for structuring a prompt so a cache can match it are provider-independent and worth learning once, separately. What is DeepSeek-specific — and what this question is really testing — is that those principles are the *only* lever, because the API exposes no other. ## Model coverage and how to verify Both production model IDs benefit. On `deepseek-reasoner` the discount still applies to the input side only; the model's chain-of-thought output is billed as output regardless, so a reasoner workload with a fully cached prompt can still be dominated by generation cost. Verification is a two-call experiment anyone can run in a minute: send the same long prompt twice and compare `prompt_cache_hit_tokens` across the two responses. The first call typically reports zero, the second reports most of the prompt. If the second call also reports zero, the cause is one of the three limits above or a prompt that changed between calls — not a missing configuration flag. ## Interview traps The strongest wrong answers sound plausible: inventing a `cache_control` block on the first message, an `enable_cache` boolean, or a request header; claiming an hourly storage fee; or asserting that cache hits are free rather than cheap. Another trap is claiming caching must be requested per model. None of these exist on DeepSeek. Say "nothing to enable, read the usage object to confirm, storage is free" and you have covered the whole surface.