DeepSeek's 12x Price Rise: 1.7x to 3.6x on a Bill
DeepSeek moved to peak and off-peak pricing in August. Two worked bills show what the widely quoted 12x increase costs in practice.
This piece started on August 14 as a countdown: DeepSeek’s new prices would take effect on August 17, three days away. The headline said “up to 12x at peak hours”.
Two months later the window is long closed and the countdown is useless. In this rewrite I want to answer the question the original never worked out: what does 12x look like on an actual bill?
The conclusion first. The 12x is real, but it happens only in the cell that used to be cheapest. I ran two sample workloads, and the whole bill rises by 1.7x to 3.6x, depending mostly on what time of day you make your calls.
What was announced at the time?
The August 13 entry in DeepSeek’s changelog announced two things: the production release of V4 Pro, and a move to peak and off-peak API pricing, with off-peak at half the peak price. The new prices took effect at 16:00 UTC on August 16, which is 00:00 on August 17 in Beijing and Taipei.
The Wayback Machine saved a copy of the pricing page on August 14. The table of new prices looked like this:
Figure: The DeepSeek pricing page as captured on 2026-08-14, announcing the prices effective August 17 (source: web.archive.org)
The same capture shows the old prices still being charged: deepseek-v4-pro at 0.025 yuan on a cache hit, 3 yuan on a miss and 6 yuan for output; deepseek-v4-flash at 0.02, 1 and 2 yuan. All prices are CNY per million tokens.
The capture also confirms the main point of the August piece: on August 14, deepseek-v4-pro already mapped to model version DeepSeek-V4-Pro-0813, while the price was still the old one. That state of new model at old price lasted from August 13 to the early hours of August 17.
I covered how the model went live in a separate piece.
How much did each cell rise?
It is clearer with three points in time side by side. The rightmost column is what happened from September, which I come to later.
Figure: DeepSeek API prices at three points in time (compiled for this article from the 2026-08-14 capture of the DeepSeek pricing page and the live page)
Item by item, the August 17 change was:
- Input on a cache miss: 1.5x off-peak and 3x at peak for both models.
- Output: 2.25x off-peak and 4.5x at peak for both models.
- Input on a cache hit: 2.5x and 5x for Flash, 6x and 12x for Pro.
The 12x is that last cell: Pro input on a cache hit, from 0.025 yuan to 0.30 yuan at peak.
It could rise 12x because it started so low. 0.025 yuan is 1/120 of the cache-miss price. After the rise, 0.30 yuan at peak is still only 1/30 of the 9 yuan peak cache-miss price. Caching is still a good deal, just a less extreme one. The basics of token pricing and caching are in the glossary.
What is that on a bill?
A multiple means something only once you multiply it by usage. I set up two scenarios, both on deepseek-v4-pro:
- Scenario A: 10 million input tokens a month, none hitting the cache, plus 2 million output tokens. This resembles scattered one-off requests.
- Scenario B: 50 million input tokens a month, 80% hitting the cache, plus 2 million output tokens. This resembles a coding agent that sends the same long context again and again.
Figure: Monthly bills for two workloads at the old, off-peak and peak prices (calculated for this article from DeepSeek pricing page unit prices)
The arithmetic for scenario A: at the old price, 10 × 3 + 2 × 6 = 42 yuan. Off-peak, 10 × 4.5 + 2 × 13.5 = 72 yuan. At peak everything doubles, to 144 yuan.
Scenario B adds 40 million cache-hit tokens. At the old price that line costs 1 yuan and the whole bill is 43 yuan. Off-peak the line becomes 6 yuan and the bill 78 yuan. At peak it is 156 yuan.
Two things deserve your attention.
First, the cell that rose 12x was only 2% of the old bill in scenario B. After the change it is 8%. Its share quadrupled, but most of the bill is still cache-miss input and output.
Second, what decides whether you pay 1.7x or 3.6x is almost entirely the time of day. For the same usage, peak is exactly double off-peak. The cache hit rate matters much less: the multiples for A and B differ by only 0.1 to 0.2.
I chose these two scenarios myself. A different input-output ratio gives different numbers. The larger the share of output, the closer the overall multiple gets to 2.25 and 4.5.
The CNY and USD multiples are nearly the same. In USD, output went from $0.87 to $1.98 off-peak, which is 2.3x.
Which hours are peak?
Here is a detail that could not be seen in August.
The August 14 capture says peak hours are “9:00 - 12:00, 14:00 - 18:00 Beijing time (all other times are off-peak)”, with no mention of days of the week. The August piece therefore said “every day”.
The live pricing page is more specific:
Figure: The model and price table on DeepSeek’s live pricing page (source: api-docs.deepseek.com)
The note under the table says peak hours are 9:00 to 12:00 and 14:00 to 18:00 Beijing time, Monday to Friday, excluding Chinese public holidays. All other times, including whole weekends and Chinese public holidays, are off-peak.
The rule was changed later. I compared captures of the pricing page from different dates: the August 19 version still counts every day, the August 23 version adds “Monday to Friday”, and public holidays were added in late September. The step-by-step comparison is in the piece on weekends going off-peak.
The difference is not small. Counting every day, 49 hours a week are peak. Counting weekdays only, it is 35 hours, or 21% of the 168 hours in a week.
Figure: DeepSeek peak hours in other time zones (hours from the note on the DeepSeek pricing page; conversions calculated for this article)
Taiwan is in the same time zone as Beijing, so if you are there it is easy to remember: peak is weekday office hours, and the lunch break from 12 to 2 counts as off-peak.
For users in the United States, peak falls in the evening and the middle of the night, and the whole working day is at the off-peak price. The same price list feels very different depending on your time zone.
If your requests are spread evenly across the 168 hours of a week, 21% land in peak. On that basis the average Pro output price is 13.5 × 0.79 + 27 × 0.21, about 16.3 yuan, or 2.7x the old price.
Why split by time of day?
DeepSeek gave no reason. The changelog states only the new pricing method and the effective time.
Time-of-day pricing is common in electricity and cloud computing, where it moves flexible demand to off-peak hours. The August piece guessed that DeepSeek had the same aim. I still think that is the most plausible explanation, but it is a guess.
There is one piece of circumstantial evidence. The peak hours match weekday office hours in China exactly, down to the lunch break being carved out. That looks like a boundary drawn along a real load curve and not picked at random.
What changed after September?
On September 10 DeepSeek released V4.1 Flash, and the changelog says API prices were “reduced accordingly”. Compared against the live pricing page, the changes are:
- The model name became
deepseek-flash. The old namedeepseek-v4-flashcan still be called, but requests are served by V4.1 Flash and billed at Flash prices. - Flash input on a cache hit and on a miss is back to 0.02 and 1 yuan off-peak, the same as before August 17.
- Flash output is 4 yuan off-peak and 8 yuan at peak. That is a little below the 4.5 and 9 yuan of August, but still two and four times the old 2 yuan.
- Pro prices did not move. They are still the August 17 set.
So if you were on Flash and can now schedule your work off-peak, your input cost is back where it was before the change and only output is dearer. What changed is the model: V4.1 Flash is not the original V4 Flash. The details of that release are in this piece.
What was the three-day window worth?
The August piece advised readers to use the window and consider clearing backlogs early. The value of that advice can now be worked out.
Take scenario A as the unit: 42 yuan inside the window, 72 yuan off-peak afterwards. The difference is 30 yuan, a little over NT$130. If you happened to have ten or a hundred times that volume queued up, and the Pro concurrency limit of 500 let you finish it in three days, the saving was real.
For most people, though, the amount of work that can be pulled forward into three days is limited. What shapes the bill in the long run is every month after that. So I would now put the emphasis the other way round: the window was a small matter, and scheduling is the large one.
Concretely, I would look at three things first:
- How many of your requests fall on weekdays between 9 and 12 and between 14 and 18. That decides whether you are nearer 1.7x or 3.6x.
- Which jobs can wait. Batch processing, offline generation and overnight evaluation runs lose nothing by moving off-peak. Requests that answer a user in real time cannot move.
- How much of the bill is output. The output increase is the hardest to avoid. Applications with a high share of output are hit hardest.
What would change my view? If DeepSeek later widens the peak hours or shrinks the off-peak discount from one half, scheduling pays less. The pricing page itself says prices may change. Between August and September they changed twice.
What this rewrite corrected
- The original opened with a first-person account of when a price notice email arrived. I could not verify that email this time and removed it; the changelog and the pricing page capture are the basis now.
- The original said peak hours applied “every day”. The August 14 pricing page did not mention days of the week; the live page says Monday to Friday, excluding Chinese public holidays. Both wordings are given here.
- The original headline stressed “up to 12x”. This version adds bill-level calculations and the headline has changed.
- The original was a countdown before the increase. This version adds the Flash price and model name changes from September 10.
