DeepSeekis moving toward a dynamic pricing model where your costs double depending on the time of day. Specifically, they've designated 01:00 - 04:00 and 06:00 - 10:00 UTC as peak hours. If you're running heavy batch jobs or an automated AI workflow, you can effectively cut your bill in half just by scheduling your requests outside those windows.
Looking at the V4 Flash numbers, the "off-peak" rates are $0.007 for cache hits, $0.22 for misses, and $0.66 for output. During peak hours, those jump to $0.014, $0.44, and $1.32 respectively. If you're using V4 Pro, the stakes are higher: off-peak is $0.022 (hit) / $0.66 (miss) / $1.98 (out), while peak pushes that to $0.044 / $1.32 / $3.96.
What's more interesting—and perhaps more painful for long-term users—is how the current V4 Flash off-peak rates compare to the older pricing. We aren't just seeing a shift to time-based billing; the base costs have climbed significantly.
Cache hit:$0.0028 (old) vs $0.007 (new) — a 250% increase** Cache miss:$0.14 (old) vs $0.22 (new) — a 157% increase Output tokens:**$0.28 (old) vs $0.66 (new) — a 235% increase
From a benchmarking perspective, this makes the "cache hit" strategy even more critical for anyone doing prompt engineering at scale. If you can structure your context to maximize cache hits, you can mitigate some of these price hikes, but the raw cost of output is definitely trending upward.
For those of us managing LLM agent deployments, this adds a layer of complexity to cost projection. You can no longer just multiply token counts by a flat rate; you have to account for the UTC timestamp of the request. It feels like the industry is moving toward "utility-style" billing, similar to how electricity works, to manage server load during high-traffic bursts.
If you want to keep a record of these shifts, I'd suggest archiving the pricing page regularly, as these numbers seem to be fluid. Here is the current documentation for reference:
https://api-docs.deepseek.com/quick_start/pricing/
Depending on your volume, it might be worth writing a simple wrapper for your API calls to check the current UTC time and either delay non-urgent tasks or switch to a different model during those peak windows to keep your overhead low.
Next Can we actually handle a full video pipeline in the browser →