Re-route your AI bill after DeepSeek's peak pricing

Your inference bill changed at 16:00 UTC on August 16, 2026, when DeepSeek's revised V4 API rate card took effect. The V4-Pro peak cache-hit input cost exceeds the previous rate by a factor of just over 12. If you own production AI spend, the change is a routing problem: some requests can wait, some cannot, and the new table prices that difference. The practical move is to schedule the movable work, then fix the cache rules that decide whether the schedule pays off.

The spread is the entry fee

The output numbers are blunt. V4-Flash output tokens now cost $0.66 per million off-peak and $1.32 at peak, up from $0.28. V4-Pro output tokens cost $1.98 off-peak and $3.96 at peak, up from $0.87. The off-peak rates do not undercut the old prices. The discount is relative, not absolute, so the decision is which requests deserve the premium. If a request can wait, waiting is a discount. If it cannot, the premium is a cost of service.

Peak hours are a timezone map

DeepSeek treats 01:00-04:00 UTC and 06:00-10:00 UTC as its daily peak period, which spans seven hours. The premium applies inside that window, so the first operational question is whether your batch jobs can wait until the remaining hours. Map the UTC blocks to the local hours where your users actually call the model. If a large job runs in a region where the window is overnight, you may be paying peak for work that could run off-peak. If the same job is user-facing, the window is a constraint, not a choice.

Cache misses are where the multiplier gets ugly

Cache pricing is the hardest part. For V4-Pro, the peak cache-miss input price becomes $1.32 per million tokens, up from $0.435. Long, repeated prompts built from system instructions and few-shot examples can let the hit price dominate the bill. A cache miss during peak is the worst case: you pay the input penalty and still get no discount for reuse. The fix is usually structural. Keep stable prefixes stable. Put system instructions, tool schemas, and few-shot examples before variable content. A prompt that changes every request defeats the cache. When a prompt is mostly stable, a miss is a bug.

Run these five checks before the next invoice

The list below is the part you can run in a normal workday. Each item is testable against your current queue. If a job cannot move, you stop optimizing its timing and start optimizing its token count, model tier, or whether it should run at all.

• Inventory batchable jobs: open your job queue and mark each job as batchable or user-facing.
• Map peak hours to your user time zones: mark which local hours fall in the provider's peak window.
• Shift batch work to off-peak: flag the largest batch job that can run outside the peak window.
• Fix cache misses: find one cache miss where the multiplier is steepest, especially V4-Pro peak cache-miss input.
• Re-run unit economics for immovable traffic: check one immovable endpoint against its margin after the rate change.

The order matters because scheduling changes the cache problem. A job that moves off-peak may no longer need the same prompt shape, and a user-facing endpoint that stays in peak needs a different fix. Run the list as a loop, not a one-time audit: after you move work, re-check the cache and the margin before you treat the bill as fixed.

The hard part is the immovable traffic. User-facing requests that land in the peak window will pay the premium, so the only levers are token count, model tier, and whether the request is necessary. Compress prompts where the answer does not depend on every example. Use the cheaper tier when quality allows. If a feature is only called during peak and only produces low-value output, delay it, batch it, or remove it. The re-routing ends when you can say which requests are worth the premium.