# DeepSeek API + KV cache: a $/1M-token breakdown for sliding-window agent harnesses (opencode / pi) ## 1. What DeepSeek charges today (live official price sheet, Aug 2026) As of now DeepSeek only lists two models, both with a **1M-token context window** and **384K max output**, and prices are split into **off-peak (half price)** and **peak** buckets. Peak hours are 01:00–04:00 and 06:00–10:00 UTC — note that's morning European time, so EU dev hours are peak. **Price per 1,000,000 tokens (official, current):** | Bucket | deepseek-v4-flash off-peak / peak | deepseek-v4-pro off-peak / peak | |---|---|---| | Input, **cache hit** | **$0.007 / $0.014** | **$0.022 / $0.044** | | Input, **cache miss** | **$0.22 / $0.44** | **$0.66 / $1.32** | | **Output** | **$0.66 / $1.32** | **$1.98 / $3.96** | Source: [DeepSeek Models & Pricing](https://api-docs.deepseek.com/quick_start/pricing) The ratios are the whole story: on flash, a cache-hit input token costs **~31× less than a cache-miss input token** and **~94× less than an output token**; output is **3× a cache miss**. Pro has the same shape (~30×, ~90×). ⚠️ Caveat: third-party price articles from June 2026 (e.g. [Puter's DeepSeek pricing guide](https://developer.puter.com/tutorials/deepseek-api-pricing/)) still show older launch numbers ($0.14/$0.28 flash) — the live official page above is what actually bills. ## 2. How the KV cache actually works on DeepSeek - **Automatic, on-disk context caching, enabled by default** — no `cache_control` parameters, no cache-write fee, no storage fee. You only ever pay the hit vs miss input rate ([Context Caching docs](https://api-docs.deepseek.com/guides/kv_cache)). - **A hit requires a FULL prefix match.** Because of DeepSeek's Sliding Window Attention (SWA) architecture, each cached prefix is stored as an *independent, complete unit*; a request only gets the cache-hit rate if it fully matches a persisted prefix unit. - Persistence happens at request boundaries (end of user input and end of model output), with common-prefix detection and fixed-token-interval carving. - It's **best-effort**: construction takes seconds, entries can be cleared within hours–days of disuse, and the API reports exactly what happened via `usage.prompt_cache_hit_tokens` and `usage.prompt_cache_miss_tokens`. - **Output is never cached** (it's non-deterministic) — output tokens always bill at full output rate. - **Thinking mode is ON by default** (both V4 models), and the hidden reasoning tokens **bill at the output rate** ([Thinking Mode docs](https://api-docs.deepseek.com/guides/thinking_mode); confirmed by [Puter's breakdown](https://developer.puter.com/tutorials/deepseek-api-pricing/)). In agent loops this can multiply your bill 2–10× unless you use non-thinking mode for mechanical steps. ## 3. What opencode / pi actually send per turn (why this matters) Both harnesses **re-send the entire conversation (system + tools + full history) on every model call** and only shrink it via compaction — which is the *ideal* pattern for DeepSeek's prefix cache. - **opencode (V2):** auto-compaction on by default. It triggers when `estimated tokens > context limit − max(requested output tokens, buffer)` with **buffer = 20,000**; on compaction it keeps the newest **15,000 tokens** (`keep.tokens`) beside a generated summary (≤ **4,096 output tokens**, tools disabled, tool output truncated to 2,000 chars, token estimate = JSON length ÷ 4). Compaction is lossy but earlier durable messages are kept ([opencode Compaction docs](https://opencode.ai/v2/docs/compaction)). - **pi:** auto-compaction triggers when `contextTokens > contextWindow − reserveTokens` (**reserveTokens default 16,384**), keeping the newest **20,000 tokens** beside the summary ([pi Compaction docs](https://pi.dev/docs/latest/compaction)). Notably, pi sends compaction/branch-summary prompts with **fresh routing IDs and disables prompt-cache writes** because they're one-off. Pi supports DeepSeek natively via `DEEPSEEK_API_KEY` ([pi Providers docs](https://pi.dev/docs/latest/providers)). (DeepSeek also ships its own official harness, "DeepSeek Harness", in developer preview: [quickstart](https://deepseek-harness.github.io/deepseek-harness/en/guide/quickstart).) ## 4. The $/1M sliding-window breakdown — three regimes Define per turn: **W** = stable history prefix, **D** = new input delta (your message + tool results), **O** = output tokens. Example session: **W = 60k, D = 4k, O = 2k**, deepseek-v4-flash, off-peak. **Regime A — growing window (opencode/pi default behavior, prefix unchanged):** Every turn after the first: `W` is a cache HIT, `D` is a miss, `O` is output. ``` per turn = 60k×$0.007 + 4k×$0.22 + 2k×$0.66 (per 1M) = $0.00042 + $0.00088 + $0.00132 = $0.00262 → ≈ $0.26 per 100 turns, ≈ $2.62 per 1,000 turns (flash) → ≈ $0.79 per 100 turns, ≈ $7.92 per 1,000 turns (pro) ``` With thinking at ~4× output overhead (O_eff = 8k): ≈ **$0.66 per 100 turns** (flash). **Regime B — true sliding window (drop oldest tokens every turn):** Here's the trap. DeepSeek only discounts *fully matching prefix units*. When your window start moves, the prefix **no longer fully matches** the persisted units → the entire window is billed at the **cache-miss rate**, every turn: ``` per turn = (60k+4k)×$0.22 + 2k×$0.66 (per 1M) = $0.01408 + $0.00132 = $0.01540 → ≈ $1.54 per 100 turns, ≈ $15.40 per 1,000 turns (flash) → ≈ $4.62 per 100 turns, ≈ $46.20 per 1,000 turns (pro) ``` **A literal sliding window costs ~5.9× more than a warm growing window** on both models — purely from throwing away cache hits. Sliding = cache-hostile on DeepSeek. **Regime C — compaction spike (rare with a 1M context):** When opencode/pi do compact (limit 1M − 20k buffer is a *lot* of turns), one turn is a full cache miss (new prefix) plus a summary-generation bill (output rate, ≤4k tokens in opencode; pi even skips cache-writes for it). E.g. ~30k compacted input + 4k summary on flash ≈ $0.0066 + $0.0026 ≈ **$0.009 one-time spike**, then it settles back into Regime A. ## 5. Operational takeaways 1. **Never manually trim/slide the window in an agent harness pointed at DeepSeek** — every truncation resets the prefix and converts ~31×-cheaper hit tokens into miss tokens. Append-only + let opencode/pi compact is the money-optimal pattern. 2. **Keep the prefix byte-identical**: static system prompt + tool schemas + history up front, variable content (new messages) at the end — that's what makes `prompt_cache_hit_tokens` dominate in Regime A. 3. **Watch thinking mode**: default-on and billed as output — for a 60k/4k/2k session it often doubles-to-5× the bill. Use non-thinking for routine agent steps. 4. **Avoid 01:00–04:00 and 06:00–10:00 UTC** if you can (2× price). 5. With 1M context + $0.007/1M cache hits, a long opencode/pi session on DeepSeek is dominated by **output tokens**, not context — so cap output length and prefer flash unless you genuinely need pro-grade reasoning. *All prices/mechanics cited from the live pages opened: [DeepSeek pricing](https://api-docs.deepseek.com/quick_start/pricing), [DeepSeek context caching](https://api-docs.deepseek.com/guides/kv_cache), [DeepSeek thinking mode](https://api-docs.deepseek.com/guides/thinking_mode), [opencode compaction](https://opencode.ai/v2/docs/compaction), [pi compaction](https://pi.dev/docs/latest/compaction), [pi providers](https://pi.dev/docs/latest/providers), [Puter pricing guide (for the thinking-tokens-billed-as-output confirmation; note its price table is stale)](https://developer.puter.com/tutorials/deepseek-api-pricing/).*