DeepSeek V4 pricing: the 30x cache lever your cost tool isn't showing you

内容管线 #1 ｜ 母题：热点/避坑（DeepSeek V4 定价）｜ 目标平台：dev.to（caresodev）→ 后续 X/HN 分发
SEO 关键词：deepseek v4 pricing, deepseek cache pricing, llm cost, deepseek tokenizer
CTA：SpendGuard 预登记（落地页部署后换链接；当前引 GitHub 仓库）

---

When DeepSeek shipped V4 pricing, one number got almost no attention. Input tokens with a cache hit cost $0.007 per million. Without a cache hit, the same input costs $0.22 per million. That's a 31x difference on the same tokens.

If you run agent loops, cron jobs, or anything with a repeating prompt against DeepSeek, this single mechanic decides whether your monthly bill is a rounding error or a surprise.

The actual V4 prices

Verified from the official pricing page (2026-08):

1M tokens, USD	deepseek-v4-flash	deepseek-v4-pro
Input, cache hit	$0.007	$0.022
Input, cache miss	$0.22	$0.66
Output	$0.66	$1.98

All prices double during peak hours. Output is the most expensive line item on every row.

What cache pricing means in practice

Every API call has a prefix. Same prefix, same order, and the provider can serve most of it from cache. Three patterns dominate real bills:

Agent loops. Every step resends the whole conversation. A 20-step session with a 10K-token history pays for that 10K prefix 20 times. Cache hit makes each resend cost $0.007/M instead of $0.22/M. No cache, and the same session costs 31x more for the input portion.

Cron and batch jobs. Deterministic prompts with a stable system prompt are the easiest cache wins in existence.

RAG with a fixed system prompt. The retrieved chunks change, but the instructions don't. A stable instruction prefix keeps the cache alive.

The catch: any change to the prefix kills the cache for the whole request. A timestamp injected into the system prompt, a reordered context block, even a trailing newline in the wrong place. Cache is fragile by design, and it's invisible unless you measure it.

Why generic cost tools get DeepSeek wrong

Two structural problems, both measurable.

Pricing tables updated by community PRs. LiteLLM and similar tools track prices from community submissions. When DeepSeek changes pricing, there's a window between the change and the merged PR where every estimate is wrong. V4's cache-hit tier is exactly the kind of change that breaks old estimates, and it's the tier that matters most.

Tokenizer mismatch. Most tools estimate tokens with OpenAI's tiktoken. DeepSeek ships its own tokenizer. I measured the same Chinese text with both: cl100k_base counts 2,496 tokens, o200k_base counts 1,949. That's a 20% spread on the same string. Estimate a bill with the wrong tokenizer and the numbers are fiction.

What actually cuts a DeepSeek bill

1. Keep prefixes stable. Same system prompt, same ordering, no timestamps. Cache hit rate is the single biggest lever on the bill.
2. Run batch jobs off-peak. Prices double in peak hours. Nightly processing at 3am is half price for the same work.
3. Cap retries. A retry storm multiplies the bill 3x and produces nothing.
4. Watch output. Output tokens are the most expensive row on the table. Long generations are the real spend.

Real numbers from my own usage

A simple Q&A (2K input + 1K output) costs $0.0011. A 100K-token context call costs $0.0253, or $0.0040 if the prefix caches (84% off). Individual requests are cheap. Bills explode from repetition: agent loops, cron, retries, context you keep resending. None of it shows up in a per-request view.

The gap

The popular observability tools show total spend. Almost none show cache hit rate as a first-class metric, and that's the number that actually determines DeepSeek cost. I'm building SpendGuard to fix exactly this: pricing checked against the official page instead of community PRs, cache hit rate visibility, off-peak scheduling suggestions, and cost reports that don't need a spreadsheet. Pre-registration opens soon, watch the repo to get notified.

Data verified against api-docs.deepseek.com pricing page, 2026-08-18. Prices change; check the official page before making decisions.