Pricing and documentation verified: 22 August 2026. Compiled from DeepSeek’s official API documentation, read on 22 August 2026, and compared against archived captures of the same page taken on 16, 18 and 21 August 2026. We do not hold a DeepSeek API account and have not run or benchmarked any of these models. Every rate and every rule below is a published vendor number or a verbatim vendor sentence. Every hour count, blended rate, percentage and timezone conversion built on top of them is our own arithmetic and is labelled where it appears.

Compiled and fact-checked by the AI Tools Worth editorial team. Corrections: contact page.

The notice went up yesterday and takes effect today

DeepSeek has added a single sentence to footnote (1) of its Models & Pricing page. In full, as published:

“Effective 00:00 (Beijing Time) on Sunday, August 23, 2026, we will adjust our peak/off-peak billing rules, with off-peak rates applying throughout the day on weekends (Saturdays and Sundays, Beijing Time).”

That sentence is new. The archived capture of the same page taken at 15:13 UTC on 21 August 2026 carries footnote (1) with the peak-hours definition and without the weekend sentence. The 18 August capture is identical to the 16 August one. So the notice appeared on the page some time after 15:13 UTC on 21 August — roughly a day of warning, against the ten days of warning DeepSeek gave before the 16 August price increase.

The rest of footnote (1) is unchanged and still governs: “Off-peak rates are half of the peak rates. Peak hours are 01:00 – 04:00 and 06:00 – 10:00 UTC (all other hours are off-peak).”

“August 23” is the wrong date for most of the world

The effective moment is given in Beijing time, and the peak windows are given in UTC. Beijing Time is UTC+8 and observes no daylight saving, so the conversion is fixed year-round and easy to state precisely — our arithmetic:

As published (Beijing, UTC+8)	In UTC
00:00 Sunday 23 August 2026 — rule takes effect	16:00 Saturday 22 August 2026
00:00 Saturday — weekend window opens	16:00 Friday
24:00 Sunday — weekend window closes	16:00 Sunday

So the change starts on Saturday afternoon UTC, not Sunday. Anyone reading “August 23” and setting a reminder for Sunday will have been billed under the new rules for eight hours already. And the recurring weekend window is not the UTC weekend: it runs Friday 16:00 UTC to Sunday 16:00 UTC.

This weekend is only half a weekend

The rule takes effect at 00:00 Beijing on Sunday, not Saturday. Saturday 22 August is therefore billed under the old rules for its whole Beijing day, and the first window the new rule actually covers is a partial one.

• This weekend (22–23 August): the window runs 16:00 UTC Saturday to 16:00 UTC Sunday. The peak hours it removes are Sunday 01:00–04:00 and 06:00–10:00 UTC — 7 hours.
• Every weekend from 28–30 August onward: the window runs 16:00 UTC Friday to 16:00 UTC Sunday and removes Saturday’s and Sunday’s peak windows both — 14 hours.

The Beijing-versus-UTC mismatch collapses into one simple rule

Mixing two timezones in one billing rule usually creates edge cases. Here it does not, and it is worth working out why, because the practical rule is much simpler than the published one.

Every peak window sits inside the 01:00–10:00 UTC band. The Beijing weekend, converted, runs from 16:00 UTC Friday to 16:00 UTC Sunday. Checking each peak window in the week against that span — our arithmetic:

Peak window (UTC)	Inside the Beijing weekend?	Billed as
Friday 01:00–04:00 and 06:00–10:00	No — before 16:00 Friday	Peak
Saturday 01:00–04:00 and 06:00–10:00	Yes	Off-peak
Sunday 01:00–04:00 and 06:00–10:00	Yes — both end before 16:00 Sunday	Off-peak
Monday 01:00–04:00 and 06:00–10:00	No — after 16:00 Sunday	Peak

Because all eight of Saturday’s and Sunday’s UTC peak hours fall comfortably inside the Beijing weekend, and none of Friday’s or Monday’s do, the rule reduces to something a scheduler can act on without any timezone conversion at all:

There is no peak billing on Saturday or Sunday UTC. Peak hours run Monday to Friday, 01:00–04:00 and 06:00–10:00 UTC.

That equivalence holds only because the peak band happens to sit eight to sixteen hours away from the Beijing day boundary. If DeepSeek ever moves the peak windows later in the UTC day, it stops holding, and the published Beijing-time rule is the one that governs.

What it removes: 14 hours a week

Our arithmetic on the published windows. Peak is 3 hours plus 4 hours = 7 hours per UTC day.

Measure	Before	From 28 August	Change
Peak hours per week	49	35	−14 hours (−28.57%)
Off-peak hours per week	119	133	+14 hours (+11.76%)
Share of the week at off-peak rates	70.83%	79.17%	+8.34 points

What it is worth: 6.45%, not 50%

“Off-peak rates apply all weekend” and “off-peak is half of peak” sit next to each other in the same footnote, which invites the reading that weekend work now costs half. It does not, for anyone who is not actually moving work.

Take a workload that runs at a constant rate around the clock and cannot be rescheduled. Its bill is the hour-weighted blend of the two rates. Before the change that was 49 hours at the peak rate and 119 at half of it; after, 35 and 133 — our arithmetic:

Rate line	Off-peak	Peak	Blended, before	Blended, after
v4-flash input, cache miss	$0.22	$0.44	$0.2842	$0.2658
v4-flash output	$0.66	$1.32	$0.8525	$0.7975
v4-pro input, cache miss	$0.66	$1.32	$0.8525	$0.7975
v4-pro output	$1.98	$3.96	$2.5575	$2.3925

Every line falls by exactly 6.45%, and that is not a coincidence of the numbers we picked. Since off-peak is defined as exactly half of peak on every rate line, the blended cost is 217/168 of the off-peak rate before and 203/168 after, whatever that rate is. The ratio 203 ÷ 217 = 0.9355 is the same for every model, every rate line and every future price change that keeps the one-half relationship. For an unschedulable workload, this announcement is a flat 6.45% discount and nothing else.

The larger saving is only available to work that can be moved. Jobs that were already being scheduled into off-peak hours gain 14 more hours of runway per week — an 11.76% increase in the off-peak window — which matters most for batch work that could not previously fit into a single overnight run.

A third model appeared on the pricing page this week

Separately, and not mentioned in the weekend notice, the pricing table has grown a third entry. The 18 August capture lists two models; the 21 August capture lists deepseek-v4-flash-vision-exp, model version DeepSeek-V4-Flash-Vision-Exp, alongside the other two.

It is priced identically to v4-flash on every line — $0.007/$0.014 cache-hit input, $0.22/$0.44 cache-miss input, $0.66/$1.32 output, off-peak and peak respectively — with the same 1M context window, 384K maximum output and 2,500 concurrency limit. The one capability difference published in the table is that FIM Completion (Beta), supported in non-thinking mode on both other models, is listed as not supported.

Images are billed as input tokens. Footnote (2) states: “Images sent to deepseek-v4-flash-vision-exp are converted into tokens based on their dimensions and billed as input tokens together with your text tokens.” The vision guide gives the conversion: images below roughly 384×384 pixels are scaled up preserving aspect ratio, larger ones are scaled down to roughly the pixel count of an 800×800 image, and there is an upper bound of 384 tokens per image.

A fixed token ceiling and a published per-token rate give a hard ceiling on what an image can cost — our arithmetic, at the cache-miss input rate:

Volume	Off-peak ceiling	Peak ceiling
One image	$0.00008448	$0.00016896
1,000 images	$0.08	$0.17
100,000 images	$8.45	$16.90
1,000,000 images	$84.48	$168.96

These are ceilings, not estimates: an image below the resize threshold encodes to fewer than 384 tokens and costs proportionally less, and any text in the same request is billed on top. The exp in the model name is DeepSeek’s own label, and experimental endpoints are the ones most likely to be repriced or withdrawn.

Correction to our 17 August rate card

Our 17 August piece on the DeepSeek price increase reported the full before-and-after rate card for two models, because two models were on the page when we read it. The vision model was added after publication and is not in that table. The per-token rates we published for v4-flash and v4-pro have not changed and remain correct; the table is incomplete rather than wrong, and this page carries the current one.

Questions this raises

Does the weekend rule replace the weekday peak windows or add to them?

It adds to them. The peak-hours sentence is unchanged and still applies Monday to Friday. The weekend sentence carves an exception out of it.

Which timezone decides whether my request is a weekend request?

Beijing time for the weekend rule, UTC for the daily peak windows — both as published. DeepSeek does not say whether a request that starts before a boundary and finishes after it is classified by start time, completion time, or per-token, which matters for long generations landing on the 16:00 UTC Sunday edge. See What we could not verify.

Is this permanent or promotional?

Not stated. The notice gives a start date and no end date. The pricing page separately reserves the right to adjust prices, and the 16 August increase arrived with ten days of notice, so a future change to this rule would not necessarily be sudden.

Does the weekend rule change the cache-hit economics?

Proportionally, yes, and only proportionally. Cache-hit input is priced at the same off-peak-is-half-of-peak relationship as every other line, so it falls by the same 6.45% for an unschedulable workload. The gap between cache-hit and cache-miss input — a factor of about 31 on v4-flash — is untouched and remains by far the larger lever.

Does anything else on the spec sheet change?

No. Context length stays at 1M, maximum output at 384K, and concurrency limits at 2,500 for v4-flash and 500 for v4-pro. This is a billing-rules change plus a new model entry.

What we could not verify

• Exactly when the notice was published. Archived captures place it after 15:13 UTC on 21 August and before our reading on 22 August. That brackets it to under a day but does not pin it, and we found no separate announcement, changelog entry or release note carrying the weekend change.
• How boundary-straddling requests are classified. The documentation defines the windows but not the rule for a request whose lifetime crosses one.
• Whether “weekend” tracks Chinese public-holiday working days. Mainland China shifts weekends around public holidays. The notice says only “Saturdays and Sundays, Beijing Time” and does not address adjusted working weekends.
• The vision model’s release date and status. We can date its appearance on the pricing page to between 18 and 21 August but found no release note for it, and no statement of what “exp” commits DeepSeek to.
• Actual billed rates. We hold no DeepSeek account and have not seen an invoice. Everything here is the published rate card and arithmetic on it, not observed billing.
• Image token counts below the cap. The 384-token figure is a documented upper bound; the documentation points to a calculator for specific dimensions rather than publishing the formula, and we did not run it.

Sources and method

Compiled 22 August 2026 from DeepSeek’s official API documentation: the Models & Pricing page including footnotes (1), (2) and (3), and the vision guide’s image-to-token section. The effective date and the peak-hours definition are quoted verbatim from footnote (1) as it stood on that date. The dating of the change rests on Internet Archive captures of the same URL taken at 18:27 UTC on 16 August, 01:55 UTC on 18 August and 15:13 UTC on 21 August 2026, which we retrieved and compared directly. All hour counts, timezone conversions, blended rates, percentages and image-cost figures are our own arithmetic on those published numbers and are labelled where they appear. We hold no DeepSeek API account and have not run these models. Prices and billing rules change — verify against the vendor before you commit.