My billing alert fired at 9:14 AM. Not from a bug. From a price change I hadn't seen coming.
I checked the dashboard expecting a rounding error. It wasn't one — my cost-per-request for one specific token tier had gone up by a factor I had to double-check twice, because the first read looked like a mistake.
Here's what actually happened, and the script I wrote to quantify it before I did anything else.
The trigger
On August 17 (Beijing time), DeepSeek's new peak/off-peak API pricing went live — announced August 13, effective at 00:00 that day. Peak hours are 9:00–12:00 and 14:00–18:00 Beijing time; off-peak is everything else, priced at exactly half the peak rate across every tier.
That "half off" framing is accurate, but it's a discount off a much higher baseline than what DeepSeek was charging when V4 Pro launched just five days earlier. Multiple reports pegged the increase on cache-hit input tokens at up to 1100% during peak hours compared to the original launch price — I haven't independently confirmed the exact launch-day number against an archived source, so treat that figure as reported rather than verified, but it's the number that's been driving the conversation.
What I could verify directly, from DeepSeek's own current pricing page:
Peak is exactly 2x off-peak on every row, which at least makes the math predictable once you know which hour you're calling from.
Script 1: measuring the actual damage
Before deciding whether this mattered for my project, I wanted a number, not a feeling. This is a stripped-down version of what I ran — plug in your own daily token volumes and the reported launch price to see your delta:
# cost_delta.py
# Rough estimate — the "launch_price" figures below are from
# third-party reporting on DeepSeek's Aug 12 introductory pricing,
# not an official archived source. Treat as directional, not exact.
def estimate_daily_cost(cache_hit_tokens, cache_miss_tokens, output_tokens, prices):
"""prices: dict with keys cache_hit, cache_miss, output ($ per 1M tokens)"""
cost = (
(cache_hit_tokens / 1_000_000) * prices["cache_hit"]
+ (cache_miss_tokens / 1_000_000) * prices["cache_miss"]
+ (output_tokens / 1_000_000) * prices["output"]
)
return round(cost, 4)
# Your actual daily usage — replace with real numbers from your logs
daily_usage = {
"cache_hit_tokens": 4_000_000,
"cache_miss_tokens": 500_000,
"output_tokens": 300_000,
}
launch_price = {"cache_hit": 0.0035, "cache_miss": 0.42, "output": 0.83} # reported, unverified
off_peak_price = {"cache_hit": 0.022, "cache_miss": 0.66, "output": 1.98} # official, current
peak_price = {"cache_hit": 0.044, "cache_miss": 1.32, "output": 3.96} # official, current
launch_cost = estimate_daily_cost(**daily_usage, prices=launch_price)
off_peak_cost = estimate_daily_cost(**daily_usage, prices=off_peak_price)
peak_cost = estimate_daily_cost(**daily_usage, prices=peak_price)
print(f"Estimated daily cost — launch pricing: ${launch_cost}")
print(f"Estimated daily cost — off-peak (now): ${off_peak_cost}")
print(f"Estimated daily cost — peak (now): ${peak_cost}")
print(f"Worst-case increase: {round((peak_cost / launch_cost - 1) * 100, 1)}%")
Running this with my own numbers, the worst-case daily increase — if all my traffic happened to land in peak hours — came out well over 300%. That's not the sensational 1100% headline (that figure applies specifically to the cache-hit tier in isolation, not my blended daily cost), but it was more than enough to make me look at scheduling.
Script 2: making the provider swap boring
The second thing I fixed wasn't DeepSeek-specific. My integration had the base URL hardcoded:
client = OpenAI(base_url="https://api.deepseek.com/v1", api_key=DEEPSEEK_KEY)
I moved it to config, so a pricing change anywhere doesn't require a redeploy:
import os
from openai import OpenAI
client = OpenAI(
base_url=os.environ["AI_GATEWAY_BASE_URL"],
api_key=os.environ["AI_GATEWAY_API_KEY"],
)
For the gateway itself, I've been testing RouteAI — an OpenAI-compatible proxy sitting in front of DeepSeek, Qwen, Kimi, GLM, and a few others. I'm not claiming it's the cheapest option available; I haven't benchmarked every gateway, and pricing in this space shifts often enough that any "cheapest" claim would likely be stale within weeks. What it did do: turn "a provider changed pricing with five days' notice" from an emergency into a config edit. Worth testing against your own traffic pattern rather than taking that at face value.
What I'd actually recommend
Run the numbers on your own usage before reacting to headline percentages — the tier that moved the most (cache-hit input) may or may not be the tier your workload actually depends on. Then decide separately whether scheduling, provider abstraction, or just eating the cost makes sense for you.
TL;DR: DeepSeek's peak/off-peak pricing went live Aug 17 — peak is exactly 2x off-peak on every tier, and even off-peak is higher than the reported Aug 12 launch price. Widely cited reports put the cache-hit tier's peak increase at up to 1100% vs launch, though that specific figure isn't independently source-verified here. Run your own blended cost estimate (script above) before reacting to the headline number. Abstracting base_url/api_key into config — optionally via an OpenAI-compatible gateway like RouteAI — turns future pricing shocks into a config edit instead of a rewrite.
Here's the tool I referenced in this post: www.fastrouteai.com


Top comments (0)