DeepSeek V4.1-Flash Lands With Native Vision — and Kills deepseek-v4-pro in Four Days

Two things happened on the DeepSeek API today, and only one of them is a model launch.

The launch is DeepSeek-V4.1-Flash: a new architecture, native multimodal input, and a changed model name. The consequential part is the deprecation notice buried two paragraphs below the benchmarks: from 12:00 Beijing time on September 14, 2026, every call to deepseek-v4-pro routes to V4.1-Flash and gets billed at Flash rates. That's four days away.

If you have deepseek-v4-pro hardcoded in any agent, proxy, or router config and you haven't audited the capability delta, keep reading.

What changed in the API surface today

The name change is the first operational fact. The new canonical identifier is deepseek-flash — not deepseek-v4-flash, not deepseek-v4-1-flash. DeepSeek is moving to generation-agnostic names.

The legacy names deepseek-v4-flash and deepseek-v4-flash-vision-exp still resolve, but they now serve V4.1-Flash rather than the models they originally pointed to. The underlying models were retired today. If your routing config has deepseek-v4-flash, you're already on V4.1-Flash output without having asked for it.

deepseek-v4-pro is the one that hasn't moved yet — but it will. The Sept 14 change is not a soft deprecation with a parallel endpoint. It is a silent reroute inside the same model name, same URL, same authentication. Your calls will succeed; they'll just be answered by a different model, at a different price.

The capability delta between V4-Pro and V4.1-Flash

DeepSeek's own language is direct: "extensive testing shows that V4.1 Flash now outperforms DeepSeek V4 Pro across performance, cost, speed, and total time." That's a strong claim. Here is what the published benchmarks say:

Two things jump out. First, HLE without tools is lower on V4.1-Flash (36.8 vs 42.7). That matters for tasks where knowledge retrieval happens inside the model rather than via tool calls — world knowledge queries, long-document comprehension, complex reasoning on static context. Second, on every agent and code benchmark V4.1-Flash is ahead, sometimes materially so (DeepSWE: 74.2 vs 62.7).

The sensible interpretation: V4.1-Flash is a better agent runtime and a weaker pure-text oracle. If your V4-Pro usage is dominated by coding agents, function-calling pipelines, or tool-augmented workflows, the Sept 14 reroute is probably a net improvement. If you are using V4-Pro as a no-tools reasoning model — legal document analysis, dense academic Q&A, long-horizon planning over static context — you should test V4.1-Flash before the deadline rather than after.

Vision is now part of the default model

V4.1-Flash accepts image inputs natively. The previous generation required a separate model name (deepseek-v4-flash-vision-exp). That model is now retired; its requests are served by V4.1-Flash.

For gateway operators, this creates two concrete changes. First, you no longer need to route vision requests to a different endpoint. Any call to deepseek-flash with an image payload works. Second, if your policy layer was blocking vision requests on deepseek-v4-flash (common in enterprise gateways that wanted text-only behavior), that explicit block is now your only control — the model itself won't reject the image.

The concurrency limit for deepseek-flash is 2500. For deepseek-v4-pro it was 500. After Sept 14, anyone who was on Pro gets that expanded concurrency headroom automatically — which is arguably the most underappreciated part of this migration.

What the pricing change actually means

Before today, deepseek-flash (formerly V4-Flash) was already the cheaper option. The Sept 14 migration takes deepseek-v4-pro calls and bills them at flash pricing:

If you're currently running significant volume on deepseek-v4-pro, your invoice drops roughly 4× on input and 3.3× on output after September 14 — without any config change. That's a cost event worth tracking in your billing dashboard.

The risk is the reverse side: if you were relying on deepseek-v4-pro for workloads where V4.1-Flash underperforms (see HLE without tools above), you lose quality without any explicit signal. The API returns 200, the model name in your logs still reads deepseek-v4-pro, and your quality metrics are the only thing that tells you something changed.

What to pin before September 14

If you explicitly want V4-Pro behavior preserved: you can't. DeepSeek is retiring the model. There is no deepseek-v4-pro-0813 or versioned alias that stays on the old model post-deadline. The recommended path is to validate V4.1-Flash on your workload before the 14th and adjust accordingly.

If you want V4.1-Flash now (before the reroute): change your model string to deepseek-flash. That's the canonical name going forward.

If you're running deepseek-v4-flash in any config: you're already on V4.1-Flash as of today. No action needed, but audit your logs if you have vision policy rules based on that model name.

On TheRouter: model aliases that point to deepseek-v4-pro will continue to resolve after September 14, but the underlying model they reach is V4.1-Flash. If you have cost caps or quality filters scoped to the Pro tier, review them before the deadline.

The four-day window is short. Test now, not on the 15th.