DeepSeek's New Peak Pricing Hits Cache-Heavy Workloads with a 12× Increase
A 12× cost spike on cache hits rewrites the economics of prompt-caching strategies that many RAG and agent architectures depend on. Teams running DeepSeek in production have two days to re-audit their prompt design and call scheduling before the new rates lock in.
DeepSeek's V4-Flash and newly semi-launched V4-Pro models will switch to a two-tier pricing structure on August 17, 2026, with peak rates applying during Beijing working hours. The most dramatic change is a 12× increase for V4-Pro cache hits during peak times, jumping from 0.025 to 0.30 CNY per million tokens. Input cache misses see a modest 1.5× increase, but output costs rise by at least 2.25× across both models.
A typical 1M-input, 1M-output call on V4-Pro will cost 36 CNY during peak hours, four times the old price of 9 CNY. The pricing shift effectively ends Flash's reputation as a dirt-cheap option, with its peak cache-hit price rising from 0.02 to 0.10 CNY. RAG pipelines, agent orchestrations, and any workflow relying on long prefix caching will feel the cost pressure most acutely.
The update also leaves concurrency limits unstated, where Flash previously allowed 2,500 and Pro allowed 500. If those caps are tightened alongside the price hike, high-throughput applications face a double squeeze. The time-of-use model signals a broader industry move toward charging more during working hours, pushing batch processing toward overnight schedules.
DeepSeek is using cache-hit pricing as the sharpest lever to segment customers: high-value agent and RAG workloads pay a premium, while simple one-shot calls are nudged toward free-tier queuing.
The decision to leave concurrency caps unstated on the new pricing table creates uncertainty that may be intentional, letting DeepSeek throttle heavy users without committing to a public number.
Time-of-use API pricing, already standard in cloud infrastructure, is now reaching the model layer. Other providers will likely follow, making overnight batch windows a standard cost-optimization tactic.
The pricing change caught developers off guard, with expectations of a moderate increase shattered by the actual 12× jump. One pragmatic response is simply to reduce usage, especially for low-quality or unreadable code that gets run anyway.
I was thinking at most a 70% increase, didn't expect it to jump more than tenfold.