DeepSeek’s API news post introducing V4.1-Flash changes what three existing model IDs mean. If your code or config pins one of them, a request that still succeeds no longer tells you which model answered.
What the announcement says
The post is undated on the page; the copy used here was captured on Sept 27, 2026. Its routing and pricing statements:
- V4.1-Flash “is now live on the DeepSeek API with native multimodal support,” and the instruction is: “Set your model to
deepseek-flash.” - “V4-Flash & V4-Flash-Vision-Exp are retired.” For compatibility,
deepseek-v4-flashanddeepseek-v4-flash-vision-exp“temporarily route to V4.1-Flash.” No end date is given. - DeepSeek says “We’re phasing out V4-Pro.” Starting at 04:00 UTC on Sept 14, 2026, “all
deepseek-v4-prorequests will route to V4.1-Flash at V4.1-Flash rates,” and “This will continue until V4.1-Pro launches.” No launch date is given, and the post does not say whatdeepseek-v4-proroutes to afterward. - “New pricing takes effect at 04:00 UTC on Sept 10, 2026.” Peak/off-peak pricing continues, and “Off-peak rates are 50% of peak rates.” The post lists no per-token prices and no peak or off-peak time windows.
Taken together: under DeepSeek’s stated plan, all three old IDs now land on the same model, and one of them has a second change coming on an unannounced date.
A successful request is not model identity
Because the old IDs are routed rather than removed, calls to them keep working, so nothing fails loudly. That is the risk. Eval scores, latency and cost-per-request figures recorded for deepseek-v4-pro before Sept 14 were measured on V4-Pro. Under the announced schedule, V4.1-Flash has been serving that ID since 04:00 UTC on Sept 14. The post also does not say whether API responses identify which model served an aliased request, so a successful call on an old ID shows only that the request was accepted.
DeepSeek does claim the replacement is stronger. It says new pre-training methods and larger-scale RL post-training “deliver benchmark results ahead of flagship models, including DeepSeek-V4-Pro,” and that “Tests by multiple parties put V4.1-Flash ahead of V4-Pro on performance, cost, speed & total runtime.” Those are the vendor’s own claims; the post names no benchmark, score or testing party. Even if they hold on average, they do not tell you whether your prompts, output parsers or edge-case handling behave the same.
What to change
The two v4-flash IDs: move to deepseek-flash. They are temporary compatibility aliases for retired models with no stated end date. For deepseek-v4-flash-vision-exp, the post says V4.1-Flash has native visual understanding, but it does not say whether image-input requests written for the experimental ID carry over unchanged, so check that path specifically rather than assuming it.
deepseek-v4-pro: make it a deliberate choice. There are two options:
- Switch to
deepseek-flash. Your config then names the ID DeepSeek tells users to set, instead of an alias for a model being phased out. The post does not say whetherdeepseek-flashstays fixed to V4.1-Flash or follows later Flash releases, so this is not a version pin either. - Keep
deepseek-v4-probecause you plan to move to V4.1-Pro. You are then accepting that the model behind the ID changes again when V4.1-Pro launches, on a date the post does not give and to a target it does not name. Record that decision next to the config.
Split baselines at two timestamps. A cost series crossing 04:00 UTC on Sept 10 may mix old and new pricing. A quality or cost series for deepseek-v4-pro crossing 04:00 UTC on Sept 14 mixes two models. Report the periods separately instead of averaging across them, and re-run your own evaluation set on whichever ID you choose before relying on V4-Pro-era numbers.
Move flexible work off-peak. The only price relationship the post quantifies is that off-peak costs half of peak, and it advises: “Schedule flexible workloads off-peak to save.” The actual windows and per-token rates are not in this post. For agent workloads, DeepSeek says cache-hit charges “often account for a large share of agent costs,” that V4.1-Flash’s KV cache needs 1/4 the HBM and 1/8 the SSD storage of the previous generation, and that compressing the cache “cuts those costs significantly.” It gives no cache-hit price, so that is a direction, not a figure you can budget with.
What the post leaves open
- An end date for the two v4-flash aliases.
- A V4.1-Pro launch date, and what
deepseek-v4-proroutes to after it. - Whether
deepseek-flashis fixed to V4.1-Flash. - Context length, output limits, tool calling and parameter compatibility between the old IDs and
deepseek-flash. - How gateways or aggregators exposing these ID strings map or price them. The post describes the DeepSeek API; if you use another provider, check its own documentation rather than assuming the same routing.
Until those gaps close, treat a DeepSeek model ID as a routing decision rather than a fixed model, and attach a date to every baseline built on one.