DeepSeek's 1017 update and the model name that moves under you

On 17 October 2026 DeepSeek released DeepSeek-V4.1-Flash-1017 and, on the same day, made it the model that answers API requests for deepseek-flash. Nobody calling the API had to change anything, and that is the point worth examining. A team that wrote deepseek-v4-flash into an agent's configuration in the spring has now had the model behind that name changed three times, without editing a line. This article looks at what changed in this release, what the benchmark figures do and do not show, and how to handle model names that move.

What DeepSeek released

The release note describes the 1017 model as having stronger benchmark results, faster task completion and shorter outputs than the previous version, and says it is "now live on our website, app, and API." The model card calls it "a minor update" to DeepSeek-V4.1-Flash, released under the MIT license with weights on Hugging Face.

The models and pricing page now lists DeepSeek-V4.1-Flash-1017 as the model version behind deepseek-flash, with a 1M-token context. Prices are unchanged, as the change log entry for the update says. Per million tokens, cache-miss input costs $0.15 off-peak and $0.30 at peak, and output $0.60 and $1.20. Peak hours are 01:00 to 04:00 and 06:00 to 10:00 UTC, Monday to Friday, excluding Chinese public holidays.

The name history

The change log makes the sequence clear for anyone who followed DeepSeek's own advice at each step:

1. 24 April 2026. With the V4 preview, the change log told developers to set the model parameter to deepseek-v4-pro or deepseek-v4-flash.
2. 31 July 2026. The official V4-Flash release went into public beta behind the same name: "simply set the model name to deepseek-v4-flash to use the latest version." The entry says DeepSeek-V4-Flash-0731 kept the preview's architecture and size and was post-trained again.
3. 10 September 2026. With V4.1-Flash, it said V4 Flash and V4 Flash Vision Exp had been retired, and that the names deepseek-v4-flash and deepseek-v4-flash-vision-exp were "temporarily routed to V4.1 Flash". The recommended name became deepseek-flash.
4. 17 October 2026. The pricing page now says the legacy names "are still accepted, but the corresponding models have been retired, their requests are served by the DeepSeek-V4.1-Flash-1017 model and billed at the Flash price."

So a name that looked like a version, deepseek-v4-flash, now reaches a V4.1 model's second release. And deepseek-flash, the current recommendation, is an alias by design: "simply use deepseek-flash to access the latest model," says the change log. The pricing page lists no way to request the September model on DeepSeek's API.

None of this is hidden. DeepSeek documents each step. The issue is that most teams do not read a provider's change log before every deployment, and an agent's behaviour depends on the model in ways that tests written for deterministic code do not catch.

What the benchmark figures show

The 1017 card reports gains over V4.1-Flash on every benchmark in its table, including Terminal-Bench 4.0 at 42.3 against 31.2, and DeepSWE v1.1 at 77.0 against 74.2. These are vendor-reported figures.

There is a detail worth noting before relying on the Terminal-Bench comparison. The 1017 card says "We use the Claude Code harness for Terminal-Bench 4.0". The V4.1-Flash card, which reports the same 31.2, says its code agent benchmarks, Terminal-Bench 4.0 included, were run with the Minimal mode of DeepSeek Harness. The 1017 card does not say whether the 31.2 was re-run with the Claude Code harness. If it was not, the two figures measure different set-ups, and part of the difference could come from the harness rather than the model. As we covered in measuring coding agents on Terminal-Bench 4, independent runs of the earlier model through a common harness already gave a much lower score than DeepSeek's own.

The release also says outputs are shorter and tasks finish faster. If that holds for your workload, the same price per token buys more completed tasks. It also means token counts, latency and output lengths in your dashboards will shift from 17 October for reasons unrelated to your own changes.

Why a silent model change matters for agents

A model update behind a stable name can change, among other things:

• how often an agent calls tools, and which ones;
• how it formats structured output that other code parses;
• how long its answers are, and so the cost per task;
• how it responds to your system prompt and rules.

Some of those changes will be improvements, and the release note claims several. But an agent that passed a security review or an evaluation suite in September was reviewed with a different model. If your change process treats a new model as a change, an alias swap is a change that bypassed it.

The open weights offer one way out. The September V4.1-Flash weights and the 1017 weights are separate repositories on Hugging Face, so a team that self-hosts can choose exactly which one it runs and when to move. The 1017 card also notes that the release has no Jinja chat template. It provides a Python reference encoder and a set of Rust libraries for the prompt format instead, so self-hosting teams should check that their serving stack encodes prompts the same way before comparing results.

What it means for engineering and security leaders

• Treat model names as dependencies. An alias is like an unpinned package version: convenient, and capable of changing behaviour without a commit.
• Track the provider's change log for every model your agents use, in the same way you track security advisories for libraries.
• Re-run evaluations on provider changes, not only on your own releases. A swap behind the name you already use should start the same review as choosing a new model.
• Expect metric shifts. Lower output lengths or different tool-call patterns after 17 October are likely to be the model, not your code.

Practical takeaways

• List every place your tools and agents name a DeepSeek model, and replace legacy names such as deepseek-v4-flash with deepseek-flash deliberately, after testing.
• Record the date of each provider-side model change next to your own deployment history, so a change in metrics can be traced.
• Re-run your agent evaluation set against the 1017 model, including structured-output and tool-call tests.
• Compare Terminal-Bench figures only when the harness is the same, and prefer your own runs.
• If you need a fixed model, self-host the open weights at a specific revision and move on your own schedule.
• Check the 1017 card's prompt-encoding notes before serving the model yourself.