DeepSeek's Jul 24 API Cutoff: The Alias Migration Playbook

DeepSeek's API alias retirement lands on July 24, 2026 at 15:59 UTC: the legacy deepseek-chat and deepseek-reasoner model names stop being valid, per the deprecation notice on DeepSeek's own live pricing page. That single date is the only primary-confirmed fact in a week of louder claims — and it is the one every team calling the DeepSeek API has to act on.

Around that deadline swirls a genuinely confusing news cycle. DeepSeek emailed API subscribers on June 29–30 announcing an "official V4 version" targeted for mid-July, with the first peak-hour surcharge from a major LLM API provider — 2x rates during Beijing business hours. Several secondary sites now assert that V4 went generally available and that peak pricing is live. DeepSeek's own documentation, fetched directly on July 20, says neither: the changelog has zero July entries and the pricing page still shows one flat USD rate per model.

This guide separates the three layers cleanly — what is confirmed on primary sources, what is announced but not yet live, and what is secondary-only speculation — then gets operational: exactly what to change before July 24, and how to model cost exposure if the announced peak windows do land. It builds on our coverage of DeepSeek's April V4 Preview, where the models behind these aliases shipped.

Strip away every contested claim and one sentence remains, in plain text on DeepSeek's current Models & Pricing page: the legacy deepseek-chat and deepseek-reasoner model names will be deprecated on 2026/07/24, at 15:59 UTC. The platform-side pricing page carries the same marker — both aliases are still listed as live, callable model names today, each tagged "(to be deprecated on 2026/07/24)".

That framing matters. The aliases have not been retired yet — as of July 20 they still route. But any request path, SDK default, eval harness, or internal tool that passes either name has a dated expiry, and it is this week. Unlike the GA and pricing questions below, there is no ambiguity to wait out here: the date comes from DeepSeek's own documentation, and no source disputes it.

The good news: this is a shallow migration. Since the V4 rollout, the two legacy names have been compatibility shims — per DeepSeek's pricing docs, deepseek-chat maps to deepseek-v4-flash's non-thinking mode and deepseek-reasoner maps to its thinking mode. You are not changing models by migrating; you are naming the model you already use.

Three checks turn the rename into a safe deploy. First, inventory every call site — application code, but also environment variables, gateway and router configs, eval suites, cron jobs, and notebooks, where stale model strings outlive the code that set them. Second, retest mode behavior: if a consumer of deepseek-reasoner parses reasoning output, confirm the explicit thinking-mode call returns what your parser expects. Third, check concurrency assumptions — the current pricing page lists concurrency limits of 2,500 requests for V4-Flash and 500 for V4-Pro, which matters if you are consolidating alias traffic onto explicit names or considering an upgrade to Pro.

Teams still running the older open-weight stack have a bigger decision than a rename — for them, the fuller path is covered in the V3.2-to-V4 migration playbook. For API-only consumers, the checklist above is the whole job, and it fits comfortably inside a day.

Most coverage of this story conflates two different things: what DeepSeek's documentation shows right now, and what DeepSeek's June 29 subscriber email said would happen. The matrix below keeps them in separate columns, against a direct fetch of the live docs on July 20 — because a July 24 migration decision should rest on verified state, not on the loudest headline.

Read the matrix column by column and the story resolves itself. Everything in the middle column is real in the sense that DeepSeek said it — to subscribers, in CNY, with dates. Nothing in the middle column has crossed into the live-docs column yet. The only row where both columns agree is the alias retirement, which is exactly why it is the row to act on.

The timeline explains how the confusion formed. April 24: DeepSeek ships the V4 Preview — DeepSeek-V4-Pro at 1.6T total / 49B active parameters and DeepSeek-V4-Flash at 284B / 13B, MIT-licensed, with 1M-token default context. June 29–30: the subscriber email announces an official V4 version targeted for mid-July, plus the peak-valley pricing plan. July 4: two model build IDs (deepseek-v4-pro-202606 and deepseek-v4-flash-202605) leak on X — suggestive of a near-final build, but not an official statement. July 13: DeepSeek's pricing page is last touched, still showing flat rates and live aliases. Then, around July 19, a cluster of secondary sites began asserting that GA had happened.

Against that assertion stand two pieces of primary evidence. DeepSeek's own API changelog contains no July 2026 entry at all — the newest V4-related post remains the April 24 Preview announcement. And the most careful secondary tracker we found, kie.ai's release explainer, updated July 19 — the same window in which rival sites declared GA — explicitly keeps the question open.

There is also a tell inside the "GA is here" write-ups worth understanding, because it generalizes to every fast-moving AI pricing story. Several of those posts publish USD "off-peak" prices for V4-Pro and V4-Flash that are identical, to the cent, to the flat rates already on DeepSeek's current pricing page — $0.87 per 1M output tokens for V4-Pro, for instance — and then present exactly double those numbers as the "peak" price. That pattern is consistent with back-calculating from the June 29 announcement rather than reading an actually-updated DeepSeek page. Until DeepSeek's own docs show a peak tier, any USD-denominated peak figure should be treated as unverified extrapolation — which is why this article quotes the announced plan only in the CNY figures the email itself contained.

Here is what DeepSeek actually announced, per the June 29–30 subscriber email as relayed by TechNode, Odaily, and SCMP. Peak hours run 9:00am–12:00pm and 2:00pm–6:00pm Beijing time, daily — seven hours in total. During those windows, API prices for V4-Pro and V4-Flash would be exactly 2x the off-peak rate; off-peak prices stay unchanged. DeepSeek framed the mechanism as a way to allocate resources more reasonably and improve service stability.

The full announced schedule, in CNY per 1M tokens: V4-Pro output ¥12 peak against ¥6 off-peak; cache-miss input ¥6 against ¥3; cache-hit input ¥0.05 against ¥0.025. V4-Flash output ¥4 peak against ¥2 off-peak; cache-miss input ¥2 against ¥1; cache-hit input ¥0.04 against ¥0.02. TheNextWeb, writing on July 1, was explicit about the status: the surcharge is planned, not yet live, and launches when the full V4 version goes live in mid-July. As of July 20, that launch has not appeared in DeepSeek's documentation — so the plan remains exactly that.

You do not need live pricing to prepare a budget position — the announced structure is enough to bound the outcome. Because off-peak rates are unchanged and peak is exactly 2x, your blended cost multiplier is a single formula: blended multiplier = (peak-hour share of your token spend × 2) + (off-peak share × 1). The table below applies it to four representative traffic patterns, using the announced seven-hour peak window.

Two levers move you down that table. The first is time-shifting: batch jobs, eval runs, and overnight agent sweeps are usually schedulable, and under the announced windows even a partial shift out of Beijing business hours pulls the blended multiplier toward 1.0. The second is cache discipline: announced cache-hit input rates are two orders of magnitude below cache-miss rates in both tiers, so the cache-first design patterns we covered in our prompt-caching economics guide compound with any time-of-day plan rather than competing with it. For the cross-provider baseline to compare against, start from our LLM API pricing tracker. And if routing decisions like this sit inside a larger AI operating model you are still designing, that is the exact scope of our AI transformation engagements.

The interpretive story here is bigger than one vendor's billing page. DeepSeek spent roughly a year as the aggressive price-setter in LLM APIs — it made its V4 Preview's 75%-off promotional pricing permanent, and competitors repeatedly repriced in response. A peak-hour surcharge is that same company saying its cheapest hours can stay cheap only because its busiest hours will not. TheNextWeb read the announcement as a signal the price war may be cooling; we read it more specifically — as capacity economics surfacing in the price sheet. Inference capacity at peak demand is the scarce resource, and DeepSeek is the first major provider willing to say so in the rate card rather than in rate limits and degraded latency. Reuters' July 7 report that DeepSeek is developing its own inference-focused AI chip fits the same cost-control arc.

It is not happening in isolation. Coverage of the July 19 Qwen3.8 launch describes Alibaba Cloud running the inverse mechanic — extra discounts on night-time usage rather than surcharges at peak — a different company pulling the same time-of-day lever from the opposite direction; we cover that release in our Qwen3.8-Max-Preview analysis. Do not conflate the two: Alibaba discounts the quiet hours, DeepSeek's announced plan surcharges the busy ones.

Projecting forward: if DeepSeek's plan ships and holds, expect time-of-day pricing to spread the way per-token caching discounts did — first as a differentiator, then as a norm. The durable defense is architectural. Teams that build workloads to be time-shiftable and cache-first will treat congestion pricing as an arbitrage; teams with rigid, always-on pipelines will treat it as a tax. That design choice is available now, before any peak window goes live.