On October 17, DeepSeek released DeepSeek-V4.1-Flash-1017. As the name suggests, it is not a new model family — it is a dated refresh of V4.1 Flash, which shipped on September 10.

But the numbers make "minor update" a strange label. On the official model card, Terminal-Bench 4.0 goes from 31.2 to 42.3, and Automation-Bench v1.0.6 goes from 54.8 to 60.5. Same family, same architecture — and a noticeably higher rate of agents actually finishing tasks.

This piece unpacks what those numbers measure, and why you cannot pick a model from the scoreboard alone.

What the release claims

Here is what the official model card says changed.

DeepSeek-V4.1-Flash-1017 (official model card, summarized)

- improvements across reasoning, coding, agentic and visual benchmarks
- reduced task execution time
- reduced output length
-> "finish tasks faster and at lower cost"
-> advancing the performance-cost Pareto frontier
   across multiple agent harnesses

That last line matters. The claim is not just accuracy. It is that the same work now takes fewer tokens and less wall-clock time. For anyone running agents, cost is tokens times price, so shorter outputs are worth nearly as much as better answers.

The numbers side by side

First, the refresh against its own predecessor. Every figure below is DeepSeek's own reported result.

Benchmark V4.1 Flash 1017 Change
Terminal-Bench 4.0 31.2 42.3 +11.1
Automation-Bench v1.0.6 54.8 60.5 +5.7
DeepSWE v1.1 74.2 77.0 +2.8
ProgramBench 20.3 29.1 +8.8
NL2Repo-Bench 65.4 68.2 +2.8
Agents' Last Exam 31.8 35.4 +3.6
Apex Bench v1.1 64.6 72.1 +7.5
HLE (no tools) 36.8 42.6 +5.8
Chartography (with tools) 78.9 83.0 +4.1
BabyVision (with tools) 89.6 92.5 +2.9
ZeroBench-main (with tools) 49.0 51.0 +2.0

The standout is Terminal-Bench 4.0. That benchmark measures whether a model finishes real work inside a terminal: reading files, running commands, checking output, and reaching a target state. It is not "can it write code," but "can the agent close the loop." For anyone building coding agents, that is the number that matters most.

ProgramBench climbing from 20.3 to 29.1 is notable too. The gain is larger on a harder axis.

It is not first everywhere

The same table places competitors next to it. Honestly read, 1017 does not win every column.

Benchmark 1017 K3 GLM-5.3 GPT-5.6 Sol Opus 5
Terminal-Bench 4.0 42.3 12.6 37.9 39.9 51.8
Automation-Bench v1.0.6 60.5 46.7 48.8 45.8 50.3
DeepSWE v1.1 77.0 67.5 66.9 73.0 74.0
ProgramBench 29.1 17.5 19.0 23.0 37.0
HLE (no tools) 42.6 43.5 42.0 44.5 56.3
NL2Repo-Bench 68.2 58.0 58.0 56.8 75.3

The read: 1017 leads or sits near the front on Terminal-Bench, Automation-Bench, DeepSWE, ProgramBench, Agents' Last Exam and Apex Bench. But Opus 5 clearly leads on HLE and NL2Repo. In other words, 1017 is strong at using tools to finish work, while the hardest reasoning still belongs to frontier closed models.

K3's low Terminal-Bench score of 12.6 is interesting. It may not mean K3 is a weak model. Terminal benchmarks are sensitive to the exact tool-calling format a model was trained on.

A score is a model-plus-harness value

Here is the heart of this piece. The model card footnotes tell you the conditions behind the numbers.

Terminal-Bench 4.0  -> measured with the Claude Code harness
DeepSWE v1.1        -> measured with the Mini-SWE-V2 harness
HLE's dagger mark   -> the text-only subset

So a single cell is actually this:

  [score] = f(model, harness, tool definitions, prompt format, retry policy)
              change the harness and the same model moves

A harness is the shell around a model: which tools it gets, in what format, how results are returned, and when it stops. Same brain, different shell, different completion rate. That is why lining up scores measured under different harnesses and declaring a winner is risky. We covered the background in Model vs Harness in AI Coding.

For harness builders: prompt encoding changed

One practically important change in this release: 1017 does not ship a Jinja-format chat template.

Instead it offers two things.

1) encoding/encoding.py — a self-contained reference implementation
   - multi-turn conversations
   - tool calling
   - thinking mode
   - numeric reasoning effort
   - mid-conversation system messages
   - interleaved image content
   with test cases for each

2) deepseek-recipe — a protocol-aware Rust library (with Python bindings)
   - converts Messages / Chat Completions / Responses API requests
     into the Conversation format
   - encodes them into V4 / V4.1 prompts or token IDs
   - parses model output back into complete or streamed responses
     (thinking, tool calls, images, generation settings)

Why it matters: harness quality depends heavily on matching the exact prompt format the model expects. Teams that maintained chat templates by hand can now use the official encoder — at the cost of a dependency on the model or server side. Either way, change the tool-calling format and the benchmark scores move.

The specs, briefly

1017 is not an architecture change; it is a training and post-processing update to the V4.1 Flash family. The family's basics:

DeepSeek V4.1 Flash family (official card plus community aggregation)

- backbone: 552B-parameter MoE
  (plus roughly 196B of Engram conditional memory,
   which some aggregators total to about 748B)
- active parameters: 8B during prefill / 16B during decode
- context: up to 1M tokens
- max output: 256K tokens or more
- KV cache: about 890 bytes per token
- modality: text and image input, text output
- license: MIT
- recommended sampling: temperature 1.0, top_p 1.0

The 1M context and MIT license are unchanged. The substance of this update is the same container, filled better.

Three traps before you adopt it

First, harness dependence. Scores are a function of the harness. If your harness differs from the benchmark's, the ranking does not transfer. For the general rules of reading benchmarks, see AI Benchmarks: How to Read Them.

Second, self-reporting. Every number is DeepSeek's own. Publishing the measurement conditions raises confidence, but it is not independent verification. And when a benchmark version changes, scores shift on their own, so comparing against older articles needs care (Why Benchmark Scores Change by Version).

Third, the illusion of magnitude. Going from 31.2 to 42.3 is a big jump, but how much you feel it depends on how saturated the benchmark is and how its tasks are built. A number shows direction, not size.

Conclusion: comparison is only meaningful under identical conditions

The briefing's action, turned into a protocol:

[1017 vs the previous version, a fair comparison protocol]

1. Pick 10 real tasks from your repo
   (bug fixes, test additions, refactors, docs updates)

2. Run both models under the same conditions
   [ ] same harness (e.g. Claude Code, or your own)
   [ ] same tool definitions and prompt format
   [ ] same retry policy, same timeouts
   [ ] same reasoning effort

3. Record four things
   [ ] task completion rate
   [ ] total tokens (input and output separately)
   [ ] cost per task ($)
   [ ] number and duration of human interventions

4. Decide on cost per successful task

The whole thing reduces to one line.

Model capability lives on the model card.
Real capability lives in the harness.

The way to stay unshaken by every "it got better" claim is to measure on your own tasks, your own harness, your own cost basis. 1017 is a good inflection point to start measuring.

Further reading

References

Go deeper with a course

The sense that the same model behaves differently under a different harness is best learned by designing the loop yourself. Write the tool definitions, the execution order, and the verification steps by hand, and you will feel why benchmark numbers wobble.