DeepSeek API models: deepseek-flash, V4 Pro, legacy aliases, and model selection
Updated: Sep 16

DeepSeek's hosted API has changed from a collection of long-lived model names into a smaller routing layer. In September 2026, the cleanest current identifier is deepseek-flash, which serves DeepSeek-V4.1-Flash. Legacy identifiers remain accepted in some cases, but they no longer necessarily identify the model that actually executes the request.
This page focuses only on hosted API model selection. It does not treat downloadable checkpoints as API products and it does not duplicate the broader DeepSeek model-family catalog.
··········
DEEPSEEK-FLASH IS THE CURRENT DEFAULT API MODEL
The current DeepSeek API documentation instructs developers to use model=deepseek-flash for DeepSeek-V4.1-Flash. The model supports thinking and non-thinking modes, a 1M context window, up to 384K output tokens, JSON output, tool calls, Responses API, Anthropic-compatible access and native vision.
........
API identifier | Backend / status | Context | Vision | Concurrency |
|---|---|---|---|---|
deepseek-flash | DeepSeek-V4.1-Flash | 1M | Yes | 2,500 |
deepseek-v4-pro | Transition-state / officially inconsistent routing description | 1M | No in current pricing table | 500 |
deepseek-v4-flash | Legacy alias to V4.1 Flash | 1M backend | Via V4.1 backend | Flash route |
deepseek-v4-flash-vision-exp | Legacy alias to V4.1 Flash | 1M backend | Yes via V4.1 | Flash route |
........
··········
THE OLD CHAT AND REASONER IDS SHOULD NO LONGER BE USED FOR NEW INTEGRATIONS
DeepSeek announced in April 2026 that deepseek-chat and deepseek-reasoner would stop being available after July 24. Before retirement, they were compatibility mappings to the non-thinking and thinking modes of V4 Flash. Existing code should be migrated to the current V4/V4.1 naming layer rather than depending on those retired aliases.
··········
V4.1 FLASH COMBINES THINKING AND NON-THINKING IN ONE MODEL ROUTE
Earlier DeepSeek integrations often encoded reasoning behavior into separate model names. The current architecture instead allows the same V4.1 Flash model family to operate in thinking or non-thinking mode. Model selection and reasoning-mode selection are therefore two separate configuration decisions.
··········
THE V4 PRO DOCUMENTATION CURRENTLY CONTAINS A REAL CONFLICT
DeepSeek's September 10 changelog states that V4 Pro API service would continue after September 14 with unchanged billing, but the current Models & Pricing page says deepseek-v4-pro requests are routed to V4.1 Flash and billed at the Flash price until V4.1 Pro arrives. Both are first-party DeepSeek pages. Data Studios therefore marks the identifier as transition-state and recommends checking the live pricing/model page immediately before production routing decisions.
··········
LEGACY V4 FLASH NAMES ARE COMPATIBILITY HANDLES, NOT MODEL-PINNING MECHANISMS
DeepSeek explicitly says deepseek-v4-flash and deepseek-v4-flash-vision-exp remain accepted temporarily, while the original models behind those names have been retired. Requests are served by V4.1 Flash. A developer using those names is therefore not pinning the old backend.
··········
DATA STUDIOS MODEL-SELECTION RULE: SELECT BY CAPABILITY, THEN VERIFY THE ROUTE
For a new integration, the selection process can be reduced to three checks: whether vision is required, whether the workload needs thinking mode, and whether the application must tolerate a vendor-controlled alias redirect. That is more robust than selecting a model solely from an old integration example.
........
Workload | Practical starting point | Why |
|---|---|---|
General text and agents | deepseek-flash | Current primary route and highest concurrency |
Image + text | deepseek-flash | Native vision on V4.1 Flash |
Reasoning-intensive text | deepseek-flash + thinking mode | Reasoning is now a mode, not a separate legacy ID |
Existing V4 Pro integration | Verify live routing before each production change | Official DeepSeek pages currently disagree on post-Sept-14 behavior |
Old deepseek-chat/reasoner code | Migrate | Those identifiers belong to the retired compatibility layer |
........
··········
API MODEL NAMES SHOULD BE TREATED AS LIVE ROUTING CONFIGURATION
DeepSeek's 2026 changes show why production systems should separate the model label in application code from assumptions about the exact backend. A name that still resolves can point to a different model generation, price schedule or capability set than it did when the integration was first written.
For the overall model ecosystem, see https://www.datastudios.org/post/deepseek-ai-models-available-full-lineup-capabilities-and-positioning-for-late-2025-2026.
··········
FOLLOW US FOR MORE
··········
DATA STUDIOS
··········
datastudios.org




