DeepSeek Model Names & Retired IDs: The 2026 Alias Reference

If you call the DeepSeek API today and want the newest small model, the model string is `deepseek-flash`. It points at V4.1 Flash, released September 10, 2026, and it is the recommended id for new integrations^[1][3].

DeepSeek decoupled the public model name from the architecture name. The architecture is V4.1 Flash; the API id is deepseek-flash. Keeping a stable public identifier across checkpoints lets the backend weights change without forcing every caller to edit code^[1].

The same id works on the OpenAI-compatible endpoint at `api.deepseek.com` and the Anthropic endpoint at `api.deepseek.com/anthropic`. For request examples, see the API setup guide.

• Current id: deepseek-flash
• Served by: DeepSeek V4.1 Flash
• OpenAI endpoint: https://api.deepseek.com
• Anthropic endpoint: https://api.deepseek.com/anthropic
• Concurrency limit: 2,500^[3]

This is the table to bookmark. It lists each model id, its current status, and what actually answers the request. Keep it next to your configuration files^[1][2].

The important column is the third one. A retired id does not necessarily mean a dead request. Several old ids still resolve, but the model behind them has been swapped, which is why the status and the serving model are listed separately^[1][2].

The current fleet is conceptually simple: one small id (`deepseek-flash`) that serves everything V4.1 Flash does, and a forthcoming flagship id, deepseek-v4-1-pro, that has no release date yet^[2].

The two old Flash ids — `deepseek-v4-flash` and `deepseek-v4-flash-vision-exp` — were retired with the V4.1 Flash launch. They were not deleted. Requests to them are routed to V4.1 Flash and billed at Flash rates^[1].

The compatibility route is both a convenience and a hazard. Your code keeps running, which is good. But the model answering the request is no longer the model your prompt was tuned for, which can invalidate regression testing. That risk is now a recurring theme in DeepSeek releases^[5].

The vision variant is a special case: V4-Flash-Vision-Exp was a separate experimental model. Routing it to V4.1 Flash means callers get the main multimodal model instead. In practice that is a capability upgrade, but it is still a behavior change that deserves a test pass^[1][4].

• deepseek-v4-flash: retired, routes to V4.1 Flash
• deepseek-v4-flash-vision-exp: retired, routes to V4.1 Flash
• Both bill at V4.1 Flash rates, not old rates
• Both changes are silent unless you log the resolved model^[1]

DeepSeek is phasing out V4 Pro. Starting at 04:00 UTC on September 14, 2026 — 12:00 Beijing time — every request to `deepseek-v4-pro` routes to V4.1 Flash and is billed at Flash rates, until V4.1 Pro launches^[1][3].

The stated reason is that multiple parties' tests put V4.1 Flash ahead of V4-Pro on performance, cost, speed, and total runtime. DeepSeek therefore frames the change as an orderly retirement rather than a failure. The id stays valid, but the backend changes^[1][5].

For V4-Pro customers this is mostly a price cut: off-peak output falls from $1.98 to $0.60 per million tokens. It also adds vision, which V4-Pro never had. The catch is that prompts tuned to V4-Pro's particular style should be re-tested rather than assumed safe^[2][5].

Earlier DeepSeek generations used the ids `deepseek-chat` and `deepseek-reasoner`. Both were retired on July 24, 2026 and are not part of the current V4.1 naming scheme^[1].

These names referred to chat and reasoning modes rather than to specific architecture versions, which made version tracking hard. The V4 era switched to explicit model ids, and the V4.1 era continues that with `deepseek-flash`^[1].

If you find one of these strings in an old config, replace it with `deepseek-flash`. Do not assume a silent compatibility route exists for ids retired before the V4.1 compatibility policy, and test before you deploy rather than trusting an old tutorial^[1].

• deepseek-chat: retired July 24, 2026
• deepseek-reasoner: retired July 24, 2026
• Replace legacy strings with deepseek-flash
• Re-run evals after any model-string replacement^[1]

DeepSeek's routing is a server-side alias. The endpoint accepts the old string, resolves it to the current model, and bills at the current model's rate. Your base URL and payload shape do not change^[1][2].

That design is convenient for migrations and dangerous for determinism. Requesty and Hacker News commentators made the same point: changing the model behind a pinned, production identifier can invalidate regression testing. The lesson is not to avoid the route, but to detect it^[5][7].

Three properties move together when a route changes. Billing follows the serving model, so cost changes. Capabilities follow the serving model, so a text-only id can gain vision. Behavior follows the serving model, so tuned prompts can drift. Any one of those can surprise a team that only watches uptime^[1][5].

• The retired id still appears in logs unless you log the resolved model
• Billing follows the serving model, not the requested id
• Capabilities follow the serving model, so a text id can gain vision
• Behavior follows the serving model, so tuned prompts may drift^[1][5]

A short checklist for teams that depend on DeepSeek model ids in production. Each item maps to a failure this release cycle actually demonstrated^[1][5].

The broader point is that model ids are now living pointers rather than frozen artifacts. Treat them like a dependency that can change under you: pin deliberately, test on change, and keep the migration path in your release notes^[5].

Because the same endpoint accepts both formats and both old and new ids, the surface area for silent misconfiguration is larger than it looks. A single integration test that asserts the resolved model and the effort value will catch most surprises before users do^[1][5].

• Never hard-code a retired id when a current one exists
• Add a startup assertion that fails if a deprecated id is configured
• Run regression evals before and after any announced routing change
• Log the resolved or returned model id on every call
• Track cost per task, since routing changes the effective rate
• Pin reasoning_effort integers, not labels, to avoid cross-source ambiguity
• Watch the changelog for the V4.1 Pro launch, which ends the V4-Pro route