DeepSeek Raises Its API Prices and Adds Peak Pricing: What It Means for Your AI Costs

What exactly did DeepSeek announce?

Alongside the full official release of the DeepSeek V4 model series, the company announced on August 13, 2026 an update to its API pricing that takes effect at 16:00 UTC on August 16, 2026 — 7pm Riyadh time. This is not only a price increase; it is a change in how billing works. DeepSeek is moving to peak and off-peak pricing, with off-peak rates set at half the peak rates.

The notice to customers adds that continuing to use the service after the change takes effect is deemed acceptance of the new terms, and that anyone who disagrees may cancel the service and request a refund. That sentence usually passes unnoticed, but in practice it means the cost of running your product changed by another party's decision, and your decision window is three days.

Before and after: the official numbers

Prices below are in US dollars per 1M tokens, taken from the official pricing page. Note that pricing splits into three line items: input served from cache (cache hit), fresh input billed in full (cache miss), and output.

Turning those figures into ratios shows where the impact really landed. V4-Pro output rose roughly 4.5x at peak hours and 2.3x off-peak. Fresh input rose about 3x at peak and 1.5x off-peak. But the line item that moved most is cached input on V4-Pro: from 0.003625$ to 0.044$ at peak, roughly 12x.

Peak hours in Riyadh time

DeepSeek defines peak as two windows in UTC: 01:00 to 04:00 and 06:00 to 10:00. Everything else is off-peak. Converted to Riyadh time, peak runs from 04:00 to 07:00 in the morning, and from 09:00 to 13:00.

In practice this means the most expensive window sits in the middle of the Saudi working morning, while everything from 1pm until 4am the next day is off-peak. The entire evening and night — the natural window for scheduled jobs, reports, and batch processing — costs half the peak rate.

If you wonder why those particular windows were chosen, the answer is geography: 01:00 to 04:00 UTC is 9am to noon in Beijing, and 06:00 to 10:00 UTC is 2pm to 6pm there. Peak is the Chinese working day — a useful reminder that your provider balances capacity around its primary market, not around yours.

Lesson one: timing is now a line item on your bill

Until now, AI cost in most projects was a function of two variables: how many requests, and how much text. A third variable has been added: when the request runs. That forces a classification that was not necessary before, between two kinds of workload:

• Interactive workloads: a customer is waiting for the answer now — a support conversation, a search inside the system, an assistant running while an employee uses the software. These cannot be deferred, and you pay the rate of the moment.
• Schedulable workloads: summarising yesterday's calls, classifying support tickets, extracting data from invoices, generating product descriptions, analysing customer feedback, building semantic indexes. It makes no difference whether these run tonight or tomorrow morning.

In most companies the second category is clearly the larger one by volume, and it is exactly what can be moved into off-peak hours by changing a scheduler, not by rebuilding anything. The saving here is not marginal: half price on more than half your consumption.

Lesson two: the caching discount is not what it was

Input caching is the trick many teams built their cost model on: you send the same system prompt or the same document repeatedly, and the repeated portion is billed at a fraction of the rate. Under the old pricing, cached input on V4-Pro was about 120x cheaper than fresh input. Under the new pricing that ratio is about 30x.

The discount is still substantial and still worth designing for, but anyone whose financial model assumed repeated input was practically free will find the difference on the invoice rather than in the spreadsheet. The practical step is not to abandon caching; it is to recompute your per-transaction cost at the new rates before month-end does it for you.

Lesson three: never build your cost base on one provider

The most important lesson in this announcement is not a number but a principle: the price of an input to your production changed threefold by the decision of a company in another country, with days of notice. Any business that tied its product economics to a single provider without a ready exit has taken on a real operational risk.

The answer is not to stop using cloud services, but to build an isolation layer between your application and the model, so that switching providers is a configuration decision rather than a rewrite project. Whoever owns that layer negotiates with the market; whoever does not simply receives notices. In DeepSeek's case there is an additional exit: the V4 models are open-weight, so self-hosting on your own infrastructure remains an option if your consumption volume justifies the hardware.

Is it still the economical choice after the increase?

Yes, and the gap is still wide. Even after the increase, V4-Pro output at peak is 3.96$ per million tokens, against roughly 25$ to 30$ per million tokens for leading closed frontier models. The gap narrowed; it did not flip.

Still, when a price gap narrows, the balance of the decision shifts: the closer prices get, the more weight goes to the other factors — output quality on your specific task, latency, where the data is processed and how sensitive it is, and the maturity of the surrounding tooling. The right choice is no longer automatically the cheapest but the most suitable per workload, and you may well end up running more than one model inside the same product.

What to do before August 16

• Take last month's invoice and recompute it at the new rates, once assuming peak and once assuming off-peak, so you know the actual impact rather than the expected one.
• Classify your jobs into interactive and schedulable, and move the schedulable ones to after 1pm Riyadh time.
• Review the longest prompts and documents you send with every request; whatever can be trimmed just became more expensive.
• Make sure you have an isolation layer that allows swapping the model without touching application logic, and test it against an alternative model in practice, not in theory.
• Assign a named owner for reviewing pricing and terms notices, because acceptance here happens through silence and continued use.

The Origami view

When we build systems that rely on AI models for our clients, we treat the model as a replaceable external supplier, not a fixed part of the architecture. In practice that means three things: a single internal interface every request passes through, token consumption logged at the level of each business operation rather than the account as a whole, and a clear separation between what must run now and what can wait for a nightly schedule.

Companies that have those three received today's news as a scheduling item adjusted in an hour. Companies that do not will discover the impact on next month's invoice with no way to attribute it to a product or a customer. The difference between the two has never been the model they picked; it is the discipline of the architecture around it.

Sources

• DeepSeek — official models and pricing page, including the peak and off-peak table: api-docs.deepseek.com
• Reuters — DeepSeek raises API pricing for its V4 models, August 13, 2026: reuters.com