DeepSeek retires V4-Flash in a silent swap, spares V4-Pro

DeepSeek retired its legacy V4-Flash model IDs this week and now silently serves the newer DeepSeek-V4.1-Flash behind them, and separately reversed a plan to shut down V4-Pro after users pushed back. Both changes live only in footnotes on DeepSeek's pricing page. For any builder who pinned deepseek-v4-flash, the model answering your calls changed without a version bump.

Key facts

• Legacy deepseek-v4-flash and deepseek-v4-flash-vision-exp IDs are retired; requests are "served by the DeepSeek-V4.1-Flash model and billed at the Flash price," per DeepSeek's pricing page.
• DeepSeek reversed its plan to migrate V4-Pro traffic to V4.1-Flash on September 14, stating it will keep V4-Pro API service at unchanged billing "in response to user demand," per the same pricing page.
• V4.1-Flash is a 552B-parameter multimodal MoE (8B active on prefill, 16B on decode) with a 1M-token context, MIT-licensed, per the Hugging Face model card.
• V4.1-Flash peak API pricing is $0.30/M cache-miss input and $1.20/M output; V4-Pro is $1.32/M input and $3.96/M output, per DeepSeek's pricing page.
• DeepSeek launched V4.1-Flash on September 10 as "the smallest model in its new architecture family" while preparing for a STAR Market IPO, per Reuters.

What happened

Two changes, both buried. The first is a retirement-by-redirect. DeepSeek's pricing page now carries a footnote: "The legacy names deepseek-v4-flash and deepseek-v4-flash-vision-exp are still accepted, but the corresponding models have been retired, their requests are served by the DeepSeek-V4.1-Flash model and billed at the Flash price." If your code calls deepseek-v4-flash, you are no longer talking to V4-Flash. You are talking to V4.1-Flash — a different checkpoint with a different architecture — and the endpoint never told you.

The second is a reversal. DeepSeek had announced that deepseek-v4-pro requests would route to V4.1-Flash starting September 14 at Flash prices, effectively sunsetting the Pro tier. On September 11 it walked that back: "In response to user demand, we have decided to continue providing API services for DeepSeek V4 Pro after September 14, 2026, with the billing method remaining unchanged." The about-face, tracked by third-party router OrcaRouter, means the Pro tier survives — for now, with a promise of "further notice" before any future change.

Neither change earned a changelog post, a versioned migration guide, or an announcement thread. Both sit as numbered footnotes under the pricing table.

Why it matters

This is a trust story, not a benchmark story. The entire premise of building on a hosted API is that the model name you pin is the model you get. When a provider swaps the checkpoint behind a stable name — even to a "better" one — it breaks the contract that makes reproducible integration possible. Outputs shift, evals drift, and the failure surfaces in your product before it surfaces in your logs. We covered the V4.1-Flash release itself in a PULSE on the launch discourse; this is the less visible, more consequential follow-on.

The V4-Pro reversal cuts the other way and is worth naming plainly: users pushed back on a forced migration, and DeepSeek listened. That is the healthy outcome. But the paired events on one page tell a single story about how this provider manages its fleet — silently swapping one model while publicly retreating on another, with the only durable record being a pricing-page footnote. For teams running our DeepSeek API and V4-Pro guides, the actionable takeaway is to pin by dated snapshot where the API allows, and to re-run your own evals against any endpoint that routes by family name.

Background

DeepSeek has built its reputation on aggressive pricing and open weights — V4.1-Flash ships under MIT with day-one weights on Hugging Face, per the model card. That openness makes the silent-swap pattern stand out. A lab that publishes its weights, its architecture, and its training-token count is, on the API side, changing the model behind a production endpoint without a version bump. The two postures — radical transparency on artifacts, quiet fleet management on serving — are in tension.

The broader context is a provider under commercial pressure. As Reuters reported, DeepSeek is preparing for an initial public offering on Shanghai's STAR Market, and it framed V4.1-Flash as the smallest entry in a new architecture family built for "faster inference, higher throughput and scaling." Consolidating two Flash IDs onto one checkpoint is rational fleet economics — one model to serve instead of two. The problem is not the consolidation; it is the silence. Builders deciding where to run sensitive or eval-critical workloads have long weighed exactly this kind of provider behavior, which is why we track it in our provider trust coverage and our decentralized inference roundup.

The mechanism is not unique to DeepSeek. Silent checkpoint swaps are an industry-wide habit — providers routinely update the model behind a stable name for cost or quality reasons, and the practice only becomes visible when outputs drift enough for users to notice. What makes this case instructive is that it is documented, dated, and paired with a public reversal, which together give builders a concrete example to point at when arguing for version pinning in their own stacks.

What's next

Watch three things. First, whether DeepSeek publishes a real migration notice or changelog entry for the V4-Flash retirement — the current footnote is the only record. Second, the September 14 date that no longer carries a V4-Pro migration; DeepSeek has said it will give "further notice" before any future change, so that page is the one to watch. Third, whether independent evaluators publish V4.1-Flash results over the coming week — the benchmark claims around the new checkpoint are, as we noted in our launch coverage, still DeepSeek's own numbers, and a silent swap into production raises the stakes on getting independent confirmation.