DeepSeek Raises Prices: Three Options for Third-Party Gateways

Key Points

Effective date: the official notice reads 16:00 UTC on August 16, 2026 — that is 00:00 on 17 August, UTC+8
Not a time-of-day discount — an across-the-board increase, then split into tiers: off-peak is half of peak, but off-peak itself is above the old price. deepseek-v4-flash output goes from $0.28 to $0.66 off-peak and $1.32 at peak
Cache-hit input rises the most: deepseek-v4-pro cache-hit input goes from $0.003625 to $0.044 at peak, roughly 12x
The driver is concurrency, not unit cost: the official docs set account-level concurrency at 500 for deepseek-v4-pro and 2,500 for deepseek-v4-flash, with 429s beyond that; DeepSeek describes the change as allocating resources more reasonably
APIYI bills at the peak tier, fixed: no time-of-day variation, because covering official capacity shortfalls requires pricier backup routes — we take no margin on this, and recharge bonuses still stack

Background

DeepSeek’s last pricing move went the other way. When the V4 family launched this year it put input at $0.14 and output at $0.28 per million tokens — among the cheapest in its class, which is exactly why it became the default substrate for batch workloads and long-running agent chains. This time the direction reverses. The official pricing page now carries a notice: the API moves to peak and off-peak billing, off-peak set at half the peak rate, effective 16:00 UTC on August 16, 2026. DeepSeek’s stated reason is restrained — to allocate resources more reasonably, and to encourage users to schedule work around actual usage. What matters here is not how much prices rose but the form the increase takes. Time-of-day billing pushes cost uncertainty onto the caller. For an individual developer hitting the API directly, that means batch jobs can move to the small hours. For a gateway aggregating traffic from many customers, it is a pricing question that has to be answered before the deadline. Data in this article comes from DeepSeek’s official pricing page api-docs.deepseek.com/quick_start/pricing and rate-limit documentation api-docs.deepseek.com/quick_start/rate_limit, retrieved 15 August 2026.

The Change in Detail

New rates

deepseek-v4-flash (per 1M tokens):

Item	Before	Off-peak (new)	Peak (new)	Peak multiple
Cache-hit input	$0.0028	$0.007	$0.014	5.0x
Cache-miss input	$0.14	$0.22	$0.44	3.1x
Output	$0.28	$0.66	$1.32	4.7x

deepseek-v4-pro (per 1M tokens):

Item	Before	Off-peak (new)	Peak (new)	Peak multiple
Cache-hit input	$0.003625	$0.022	$0.044	12.1x
Cache-miss input	$0.435	$0.66	$1.32	3.0x
Output	$0.87	$1.98	$3.96	4.6x

The phrase “off-peak at half the peak rate” is easy to misread: off-peak is not a discount — it is still higher than the old price. Take deepseek-v4-flash output: even if every call lands off-peak, the rate goes from $0.28 to $0.66, 2.4x what it was.

How the windows are drawn

Peak hours are 01:00–04:00 and 06:00–10:00 UTC; everything else is off-peak. In UTC+8:

Window	UTC	UTC+8
Peak window 1	01:00–04:00	09:00–12:00
Peak window 2	06:00–10:00	14:00–18:00
Off-peak	remaining 17 hours	remaining 17 hours

Look closely at those two windows: 09:00–12:00 and 14:00–18:00 (UTC+8) are precisely the two blocks of a Chinese working day. Peak covers only 7 hours out of 24, which sounds modest — but for workloads serving users in that timezone, the bulk of real traffic sits inside those 7 hours. Off-peak falls across the night, early morning, and the lunch break; the only thing that can realistically move there is offline batch processing. The window design is not incidental. It is aimed squarely at shaving the peak.

The root cause: concurrency is a hard ceiling

The rate-limit documentation is more revealing than the price table:

Model	Account-level concurrency
`deepseek-v4-pro`	500
`deepseek-v4-flash`	2,500

A request counts as one concurrent connection from dispatch until the response completes; going over returns 429. The same document notes that capacity expansion can be requested and that expansion itself carries no additional cost, with per-user_id isolation once granted. Read that last point in reverse and it says a lot: the lever rationing capacity is approval and physical compute, not price. Industry coverage points the same way — demand growth has outrun capacity expansion, and under a supply constraint a price rise follows. Time-of-day billing is not there to earn more; it is there to push some of the load out of those 7 hours into the other 17. For a third-party gateway, that concurrency ceiling is the painful part. A gateway aggregates traffic from hundreds or thousands of customers, so an account-level cap gets saturated easily during business hours, and expansion runs through an approval cycle. That is why a gateway needs backup routes in the first place.

Three Options for Third-Party Gateways

Once time-of-day billing reaches the middle layer, there are only three exits.

Option 1: Follow the tiers

Mirror the peak/off-peak split upstream; user cost varies by time of call.

Option 2: Fix at off-peak

Quote everything at the off-peak rate — cheapest on paper.

Option 3: Fix at peak

Quote everything at the peak rate; the price never moves.

Option 1: follow the tiers

The most faithful approach, with two obstacles in practice. First, the billing system has to switch rates by time window and attribute every call to the correct tier on the invoice — not a small change. Second, and more importantly, cost becomes unpredictable for the user: the same job billed at 10:00 (UTC+8) versus 03:00 (UTC+8) differs by 2x, which complicates budgeting and cost attribution alike. For a middle layer whose selling point is a stable unit price, this hands the complexity to the customer.

Option 2: fix at the off-peak rate

Best-looking on paper — until you combine it with the window layout above. Those 7 peak hours are where the traffic actually is. Charging the off-peak rate means selling the densest block of demand at half price, and the gap has to come from somewhere. Short term it works as customer acquisition spend. Long term it either climbs back up or gets paid for on the supply side — throttling, queueing, or quiet downgrades to a cheaper source. A headline price that looks cheap alongside inconsistent latency is usually this structure at work.

Option 3: fix at the peak tier (APIYI’s choice)

We took the third path: deepseek-v4-flash and deepseek-v4-pro move to the official peak tier, fixed, with no time-of-day variation, effective at the same moment as upstream — 00:00 on 17 August (UTC+8). The secondary reason first: our billing system does not currently support time-varying rates. That is true, but it is not the deciding factor — it could be built. The main reason is supply structure:

We route to the official endpoint first, the lowest-cost and most standard path
When official concurrency falls short, BytePlus and Alibaba Cloud’s official resale take over as backup routes, so requests are not queued or dropped into 429s
Those backup routes cost noticeably more to source than the official endpoint — that has consistently been the case for DeepSeek

So a single published rate has to cover both paths. Pricing at the peak tier is what keeps the backup route available the moment it is needed — availability comes before headline price, and we take no margin on this.

Pricing at the official off-peak rate would leave only two moves once official concurrency saturates: queue requests behind the official endpoint, or subsidise the backup route. The first sacrifices availability; the second is not sustainable. A fixed peak tier buys the same availability at every hour of the day.

Practical Guidance

Model selection and cost control

1. Use flash unless you need pro. The gap between pro and flash is about 3x both before and after the change (cache-miss input $1.32 : $0.44, output $3.96 : $1.32), so the selection logic is unchanged. The V4 Flash GA build beat the Pro preview on all five agent benchmarks we measured — see the V4 Flash GA launch notes. 2. Caching still pays, though less spectacularly. Relative to cache-miss input, pro’s cache-hit rate moves from roughly 1/120 to 1/30, and flash from 1/50 to 1/31. The ratio compressed, but a hit still removes over 96% of input cost — long system prompts and long document prefixes should still be cached. 3. Do not reschedule batch jobs to the small hours. To be explicit: on APIYI the rate is fixed at the peak tier, so moving work to a different hour saves nothing. Rescheduling only helps callers hitting the official endpoint directly. To cut cost here, shorten output tokens, lean on caching, and push simple tasks down to flash. 4. Recharge bonuses stack as usual. The unit price tracks the official peak tier; discounts come through recharge bonuses, so effective cost stays below the nominal rate.

Code

Model IDs and call patterns are unchanged — the price move needs no code change:

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://api.apiyi.com/v1")

response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[
        {"role": "user", "content": "Group these log lines by error type and count them."}
    ]
)
print(response.choices[0].message.content)

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://api.apiyi.com/v1")

first = client.responses.create(
    model="deepseek-v4-flash",
    input="Here is an 80,000-word product manual. Read it through first.",
    caching={"type": "enabled"},
)

# Pass previous_response_id on each later turn to hit the full prior context
second = client.responses.create(
    model="deepseek-v4-flash",
    input="Per the manual: how many steps are in the refund flow?",
    previous_response_id=first.id,
)
print(second.output_text)

Pricing and Availability

APIYI rates after the change (per 1M tokens, fixed peak tier):

Model	Cache-hit input	Cache-miss input	Output
`deepseek-v4-flash`	$0.014	$0.44	$1.32
`deepseek-v4-pro`	$0.044	$1.32	$3.96

Effective at the same time as upstream: 00:00 on 17 August 2026 (UTC+8). Model IDs, endpoints, and parameter structures are unchanged, and both Chat Completions and Responses remain available.

Stacking recharge promotions

APIYI prices track the official rate; discounts come through recharge bonuses: 📖 Recharge promotion details

Conclusion

The signal matters more than the numbers: the window of cheap supply is closing. DeepSeek is surcharging peak load, which is another way of saying price is now rationing compute that is not sufficient to go around — and the concurrency figures suggest this is structural rather than a passing squeeze. Three recommendations:

Re-run your model selection. The 3x gap between pro and flash held, but with absolute prices this much higher, reaching for pro by reflex costs far more than it used to
Treat caching as mandatory, not an optimisation. A hit removes over 96% of input cost — the most certain engineering return available after this change
Do not plan on saving money by shifting hours. The rate here is constant; cost work belongs in token counts and model choice

Our commitment is simple: priced at the official peak tier, no time-of-day variation, backup routes available whenever they are needed. Availability first, at no margin, with discounts continuing through recharge bonuses.

Sources: DeepSeek official pricing page api-docs.deepseek.com/quick_start/pricing and rate-limit documentation api-docs.deepseek.com/quick_start/rate_limit. Notice effective 16:00 UTC on August 16, 2026; data retrieved 15 August 2026. APIYI rates are authoritative on the live model pricing page.

Changelog

AI Radar

DeepSeek Raises Prices: Three Options for Third-Party Gateways

Key Points

Background

The Change in Detail

New rates

How the windows are drawn

The root cause: concurrency is a hard ceiling

Three Options for Third-Party Gateways

Option 1: Follow the tiers

Option 2: Fix at off-peak

Option 3: Fix at peak

Option 1: follow the tiers

Option 2: fix at the off-peak rate

Option 3: fix at the peak tier (APIYI’s choice)

Practical Guidance

Model selection and cost control

Code

Pricing and Availability

Stacking recharge promotions

Conclusion

​Key Points

​Background

​The Change in Detail

​New rates

​How the windows are drawn

​The root cause: concurrency is a hard ceiling

​Three Options for Third-Party Gateways

Option 1: Follow the tiers

Option 2: Fix at off-peak

Option 3: Fix at peak

​Option 1: follow the tiers

​Option 2: fix at the off-peak rate

​Option 3: fix at the peak tier (APIYI’s choice)

​Practical Guidance

​Model selection and cost control

​Code

​Pricing and Availability

​Stacking recharge promotions

​Conclusion

Key Points

Background

The Change in Detail

New rates

How the windows are drawn

The root cause: concurrency is a hard ceiling

Three Options for Third-Party Gateways

Option 1: follow the tiers

Option 2: fix at the off-peak rate

Option 3: fix at the peak tier (APIYI’s choice)

Practical Guidance

Model selection and cost control

Code

Pricing and Availability

Stacking recharge promotions

Conclusion