The 2026 Lineup, and Why Model IDs Matter

The two names that matter

As of the September 2026 generation, the DeepSeek API accepts two supported model identifiers.

Notice what is not on that list: deepseek-chat, deepseek-v4-flash, deepseek-v4-flash-vision-exp. Those names still resolve — the API will not reject them — but the models behind them have been retired. A request sent to a retired name is served by V4.1-Flash and billed at the Flash price.

Why retired aliases are a trap, not a courtesy

Rerouting retired names is a kindness that creates a specific class of bug. Consider the failure it enables:

1. You write integration code in the V4 era against deepseek-v4-flash-vision-exp, because you needed the experimental vision model for a screenshot-parsing task.
2. V4.1-Flash ships. The experimental model is retired. Your string still works.
3. Your code keeps passing tests. Your bills keep looking reasonable.
4. Six months later you are debugging why a pipeline behaves differently, and the answer is that the model changed underneath you and nothing told you.

The lesson generalises well beyond DeepSeek: any identifier your system sends that is not the canonical current name is a silent dependency on someone else's migration policy. Treat alias resolution as a thing to eliminate, not a feature to rely on.

curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [{"role":"user","content":"hi"}],
    "max_tokens": 1
  }'
# Read the "model" field in the response. If it is not what you sent,
# you are on a compatibility route and should pin the canonical name.

The September 2026 architecture family

V4.1-Flash is described by DeepSeek as the smallest model in a new architecture family, released with native multimodal visual understanding. The family framing is the important part: a lab releasing the small model first, explicitly noting the architecture was built to scale "to larger models," is telling you the shape of the next few years.

What actually changed for you as a user:

• Vision is native, not bolted on. There is no separate vision endpoint to call. You send image content blocks in the same message array. The old -vision-exp model is gone and its capability has been absorbed.
• Prices fell. The release notes state a price reduction alongside the model. Re-read the pricing table any time you are doing cost math — this generation has moved twice.
• Thinking is on by default. Both supported models support non-thinking and thinking modes, with thinking as the default. Lesson 9 is entirely about that switch.

Capabilities, in one table

This is the feature matrix you will keep coming back to. It is short, and every row is something you will eventually need.

Exercise: build the alias detector

Write a small script — ten lines is plenty — that takes a model string, sends a one-token completion, and asserts that the model field in the response matches what was sent. Print a clear warning when it does not.

Then run it against deepseek-v4-flash. You should see the warning fire. You now own a reusable detector for the single most common silent-failure class in provider integrations, and you built it in one lesson.