DeepSeek V4.1-Flash-1017 Benchmarks and Access

DeepSeek open-sourced V4.1-Flash-1017 today, and the number attached to the drop is 60.5 on Automation-Bench. The checkpoint is a flash-line build for agentic coding and automation, tuned toward shorter completions.

Public weights remove the invite as a gate.

The suffix is the calendar pin. DeepSeek's release thread, status 2111375640717033777, marks October 17, 2026, the same day the weights went out (DeepSeek on X).

Shorter agent traces

V4.1-Flash-1017 is a pinned checkpoint inside the flash family. Flash is the tier aimed at long chains of small steps, where one heavy answer would be the wrong shape of work. Agent scaffolds store the model id beside the tool schema. A new id is a new thing to measure. A router entry that still says flash, with no date, is pointed at some other build, and latency notes from that build describe that build alone.

Length is the behavior this release is pushing. An agent turn takes a prompt in, writes a completion, and then consumes a tool result. The wait and the token bill sit on that completion. A training target that ends the step sooner makes a multi-step coding loop cheaper at an unchanged per-token rate. The same target spends a currency you do not see on the invoice. Tokens cut from the middle of a plan are sometimes the invariant, the file list, or the reason a later call was safe. You get the savings either way. You get the mistake only on the steps that needed the missing sentence.

Open weights split the bill again. The checkpoint can run on machines you operate, or it can go through DeepSeek's API, where the lab owns batching and uptime. Self-serving adds GPU memory, a runtime that matches the architecture, and someone to page. Hosted calls fold that into usage and leave rate limits and retention with DeepSeek. Bursty overnight jobs often fit the API, because idle accelerators dominate a self-serve bill. Steady, high-volume automation can fit machines a team already racks. Shipping weights is what fills the self-serve column.

Rate limits belong in that same setup. A self-hosted process and an API key sit in different queues, so a latency win on your own GPU box can flip under DeepSeek's hosted limiter. Record which path produced the trace. Otherwise the brief will describe a capacity result as a model result.

Most coding agents require a structured action: a path, a command, or a patch hunk. Prose around that payload is output you pay for, and a broken brace turns it into a failed parse. A model that stops when the action is complete produces fewer broken wrappers. Length and correctness still move on different axes. A tool call can be valid and still be the wrong edit. With a short completion, that edit arrives with less commentary packed around it, so the log has to carry the context the model no longer writes.

Keep the tool log, the exit code, and the diff next to the completion. A short model fills your trace store with actions. Incident review then lives in those side records. The completion itself is a poor diary. Teams that stored only model text will feel this checkpoint as a logging change, which is a property of the product, separate from any benchmark cell.

Dated pins are also how you catch silent movement. A scaffold on a floating alias follows whatever DeepSeek serves under that alias next week, and the pass rate follows it. Pin 1017, store the prompt prefix, and store a hash of the tool schema. When a nightly run drops, you can separate a checkpoint swap from a prompt edit. That split is the difference between a leaderboard number and a number your on-call can use.

Use the id string from the card you deploy against, character for character. Flash names collide. V4, V4.1, and a dated suffix are three different pins, and a client that truncates at Flash will silently call the wrong one. Log the id on every request. When a result surprises you, the log answers which weights produced it.

People hear flash and think of a batch discount. This checkpoint's case is different. The saving DeepSeek is describing comes from fewer generated tokens per step, which compounds inside an agent because each step's output is often copied into the next prompt. Trim the output and you trim the following input too. That second saving is easy to miss if you price a single completion in isolation. It is also easy to lose if the scaffold logs the full chain and sends it back verbatim. The model can write less and the bill can stay fat, because the history paste undoes the trim. Measure a loop, with your real history policy, before you treat a shorter style as a smaller invoice.

The workload that will show the length change is the unattended loop: dependency bumps, ticket-to-patch runs, refactors that end in a test command. A single chat reply is a weak lens. One answer never carried enough output tokens for a shorter style to dominate the experience. The loop does, because the same trim applies on every step, and the steps share a context that grows when earlier completions were verbose. Shorter early steps also leave more room in the window for later tool results. That is a mechanical benefit, and it vanishes if your scaffold pastes the whole history back in without trimming.

Automation-Bench 60.5

The 60.5 is the Automation-Bench mark in comparison screenshots posted with the release, set next to 50.3 for Claude Opus 5. Those images are the measurement being passed around. DeepSeek's thread is the release note in that conversation (status 2111375640717033777). Opus 5 is Anthropic's model in the pair (Claude's product page).

Ten points is a lead worth carrying into a bake-off when both runs share tasks, tools, and retry rules. Judged from the images alone, pulling Opus 5 off a coding stack would outrun the eval card. The task mix does the rest. Suites in the automation style pay for finishing a job inside a tool environment. They stay quiet on a security review, a long refactor, or any check that never sat in the set. A lead on the suite you measured is still a lead.

For agentic coding, 60.5 is a claim about task completion under the scaffold inside the screenshot. Shorter completions are a separate claim. They can raise a completion score by ending rambles that never finished the job. They can lower one when the trace that passed needed a longer plan. The two effects line up only on tasks where the short action was the right action. Everywhere else they pull apart, which is why one integer cannot settle a model choice.

Exams in this family hand the model a goal and a computer, then run a checker on the end state. The computer might be a shell, a browser, or a repo. Partial credit, when the authors allow it, is a property of that checker. A harsh checker and a generous retry loop can print matching integers for runs that were not alike. Bind the integer to the checker, the temperature, and the retry budget in the note you send to procurement. The integer alone is a label.

Screenshot benchmarks tell you which number a community is repeating on release day. A methods note tells you the scaffold, the seed policy, and the checker version. Quote the images as the public claim. Quote a methods note when you have one in hand. In the meantime, keep 60.5 in the claim column of your sheet and keep your own rerun in the evidence column. Mixing those columns is how a Tuesday thread becomes an architecture decision by Friday.

Automation-Bench is a different object from a software-engineering exam that scores merged patches. The name says the checker is watching a task finish, often through tools, rather than scoring a single diff in a vacuum. SWE-bench and its cousins answer a narrower coding question when a lab chooses to quote them. Mixing a 60.5 on an automation suite with a SWE-bench percent from another model is how vendor slides get a free win. Keep the suite name in the same cell as the number. If a later card from DeepSeek or Anthropic puts both models on one named suite with a public script, that card supersedes the screenshots (Anthropic, DeepSeek's thread).

A useful rerun stays small. Pick tasks your team already grades: a failing test in a repo you maintain, a migration with a known diff, a ticket whose acceptance check is a command. Run this checkpoint and the incumbent with the same prompt, the same tools, and a retry cap written down. Score the end state, then read the trace length. The pattern you want is a pass with a shorter trace. A pass with a longer trace means the length claim missed your work. A shorter trace that fails the check means the benchmark lead missed your repo. Write down which of the three you got.

Price comparisons with GPT-5.6 Sol start on OpenAI's API pricing page (openai.com/api/pricing). That page is Sol's rate card. Quality still wants a task list you can run twice, once per model, with the scaffold frozen. Freeze the temperature and the tool schema in the same note, or the second run is a different exam.

The license file in the weights repo is what decides whether those files can ship inside a product. API terms are a separate contract. They cover prompts you send to DeepSeek, which is a different act from storing a copy of the checkpoint. A vendor review will ask which of the two you used. Answer with the file you actually accepted.

The weights are published under DeepSeek's org on Hugging Face (huggingface.co/deepseek-ai), so the checkpoint itself has no seat cap. Hosted calls remain on DeepSeek's API for teams that will not serve the file.

DeepSeek's API reference is where the model id in your request has to match the id this pin expects (api-docs.deepseek.com).

No public eval card outside DeepSeek includes a rerunnable Automation-Bench trace for V4.1-Flash-1017.