This post argues that a model's API name is not evidence of which weights were running, and that any record of a model's behaviour needs the date and the checkpoint as well as the name.

What DeepSeek changed

DeepSeek published DeepSeek-V4.1-Flash-1017 on Hugging Face on October 17, 2026, at 02:40 UTC, under the MIT licence (model card). A checkpoint is one saved state of a model's weights, the numbers that make up the trained model. The card calls this one "a minor update" to DeepSeek-V4.1-Flash, which DeepSeek released on September 10. Its configuration file is identical to the September model's, and Hugging Face reports the same parameter count for both repositories. Same architecture, new weights.

DeepSeek's API change log for the same day says: "DeepSeek V4.1 Flash has been upgraded to DeepSeek-V4.1-Flash-1017. The official web and APP models have also been updated to the new version. The API calling method and pricing remain unchanged — simply use deepseek-flash to access the latest model" (DeepSeek API change log). Anyone calling the name "deepseek-flash" on October 16 got one model. Anyone calling it on October 17 got another.

The new checkpoint behaves differently

DeepSeek's own benchmarks show a different specimen. On Terminal-Bench 4.0, a test of agents working in a command line, the score rose from 31.2 to 42.3. On ProgramBench it rose from 20.3 to 29.1 (model card). DeepSeek also says it cut task runtime and output length. These are the maker's numbers and nobody has checked them independently yet.

Some numbers are missing. The September release notes reported three cyber-offence benchmarks: CyberGym 88.1, SEC-Bench Pro 62.8 and ExploitGym 15.3 (change log, September 10 entry). The October notes and the new model card report none of them. So the public does not know whether the model now behind "deepseek-flash" is better or worse at finding and exploiting software flaws than the one it replaced.

This has happened to the name before

The same change log shows that names at DeepSeek follow the service, not the weights. When V4.1-Flash launched on September 10, DeepSeek retired V4 Flash and wrote that "for compatibility, the model names deepseek-v4-flash and deepseek-v4-flash-vision-exp are temporarily routed to V4.1 Flash." After that date, a request naming "deepseek-v4-flash" ran a model of a newer generation than the name says.

This matters for evidence already on the record. CrowdStrike's report on attacks against South Korean financial firms, which this blog covered on October 8, says the attacker's tool "used DeepSeek v4.1-flash as the primary LLM backend" (CrowdStrike). That observation predates October 17, so it describes the September checkpoint, if the attacker reached DeepSeek's own service. The report says the attacker probably went through a reseller, and a reseller's routing is unknown. An incident logged next month under "deepseek-flash" will describe the new checkpoint, or whatever replaces it.

How zoologists stop a name from drifting

Zoology solved a version of this problem by tying each name to a physical object. Under the International Code of Zoological Nomenclature, every species name has a name-bearing type, usually one preserved specimen in a museum, and that type "provides the objective standard of reference whereby the application of the name is determined" (ICZN, Article 61.1). If later workers disagree about what a species is, the name goes with the type specimen. The definition can change, and the specimen it refers to stays fixed.

An API name works the other way round. "deepseek-flash" is fixed, and the specimen under it moves whenever the maker decides. That is a sensible design for a product, because customers want upgrades without editing their code. It is a poor design for evidence. A name like this behaves like a common name, such as "robin", which means a different bird in Britain and in North America. Nobody would file a museum record under "robin" alone.

DeepSeek does publish the type material. The Hugging Face repository for the new checkpoint has a fixed commit, 1bae0e1, and the September repository still exists separately. So the weights are pinned. The link from a log line to those weights is not, unless the record also says when the call was made and through whose server.

What a record of a model's behaviour should hold

For any observation of a hosted model, whether a benchmark score, a red-team result or an incident, the name alone is not enough. The record needs the name the caller used, the date and time, the provider that served the request, and where the maker publishes one, the checkpoint the name resolved to on that date. DeepSeek's change log makes the last step possible for its own service, because it dates each switch. Many providers do not publish switch dates.

What to watch

The open question is whether DeepSeek, or anyone else, reruns the cyber-offence benchmarks on the October 17 checkpoint. Until someone does, the model now answering to "deepseek-flash" has published scores for coding and agent work and none for exploitation.