DeepSeek has published V4.1 Flash: 552 billion parameters, a million tokens of context and open weights under an MIT licence. It has been available on Helmcode since yesterday, on every plan, on EU infrastructure, with no log retention and no change to what you pay.
It replaces V4 Flash and keeps the same model id.
But the figure that best explains this launch has nothing to do with its size or its active parameters. The striking one is its 890 bytes of cache.
890 bytes go a long way
That is what the global KV cache of V4.1 Flash occupies for each token of context.
The KV cache is the working memory the model keeps about what it has already read, so that it does not have to recompute it while generating. You can think of it as its "notes" on the prompt.
In V4 Flash it was around 3.5 KB per token. In DeepSeek's first generation, close to 389 KB.
That is about 437 times less than V1 and roughly a quarter of V4 Flash.
What is interesting is that they did not get there simply by quantising harder. DeepSeek changed the architecture.
Why that matters now
A couple of years ago, cutting the KV cache would have looked mostly like an infrastructure problem.
With agents it starts to be a product problem too.
An agent does not make one call and finish. It reads files, runs code, calls tools, receives results, fails, reads the error and carries on. By step 80 it may be generating a few hundred tokens while receiving hundreds of thousands as input.
And much of that input had already appeared in earlier steps.
That changes the workload. The model spends a lot of time reading and holding context, not only generating new tokens.
Two things matter there: what it costs to process that context, and what it costs to keep it so it can be reused.
V4.1 Flash touches both.
You have surely heard that we already have models that are smart enough, and that what we need now are lighter and cheaper ones. Well, V4.1 Flash is exactly the wish we asked for.
What DeepSeek changed
Four decisions explain most of the reduction.
It reads the context with half the model. V4.1 splits its 40 layers into a 20-layer causal encoder and a 20-layer decoder. Prefill activates 8B parameters per token; decode, 16B. For a workload that can read far more than it writes, that asymmetry makes a lot of sense.
It shares the KV between layers. With CSA2, only four of the 40 layers build their global KV and their context selection from scratch. Other layers can reuse the memory, or reuse the positions another layer already decided to look at as well. Thirty of the 40 layers are in Reuse mode.
It takes the global KV from FP8 down to FP4. This is not compression applied at the end: DeepSeek introduces those conditions during post-training through Quantization-Aware Training. The local memory of Sliding Window Attention, which is more sensitive, stays in FP8.
It stops persisting the local memory for hours. The global KV stays in persistent storage. The local SWA state moves to host DRAM and expires in minutes. If it is needed again, the model rebuilds the last 128 tokens in a bounded way rather than recovering the whole history.
Together, these decisions leave the global KV at 890 bytes per token and the persistent cache at around an eighth of V4 Flash.
If you want to go down to how CED works, what the difference is between Full, Reindex and Reuse, why FP4 holds up or how Bounded Replay works, we took it apart in a separate piece: DeepSeek V4.1 Flash, the architecture built for agents .
You can decide how much it reasons
V4.1 Flash brings a lever that is already common in closed models, the reasoning effort.
On our endpoint it is the reasoning_effort parameter and it accepts four values, always as a string: low, medium, high and max. If you omit it, the model reasons with its default behaviour.
-d '{
"model": "deepseek-v4-flash",
"reasoning_effort": "high",
"messages": [...]
}'The reasoning comes back in message.reasoning_content and the count of tokens it consumed in completion_tokens_details.reasoning_tokens. That is how you measure what each level is costing you on your own workload.
DeepSeek documents that raising the effort improves average accuracy across a benchmark set, and that the middle of the range recovers much of the maximum while spending considerably less. That is an aggregate trend. Prompt by prompt it does not have to order from least to most: in our tests, the same level produces far more reasoning on some tasks than on others, and the order flips depending on the case.
The practical recommendation is the usual one: set the level per type of task, measure it with your own prompts, and do not assume the maximum is always better. On a flat rate, lowering the effort does not change your bill. It saves you latency and monthly quota, which on an agent running hundreds of steps is exactly what you notice.
What happens to the cost
DeepSeek cut its API rates with the launch.
Output came down 9%. Input without a cache hit, 32%. Input with a cache hit, 57%.
On Helmcode you do not pay those rates: V4.1 Flash counts against your plan's monthly quota exactly as V4 Flash did, and the price of the subscription does not change.
Efficiency is falling far faster on input, and above all on cached input, than on output. Which means what a task costs depends more and more on a variable you do not fully control: how much context is resolved by cache hits and how much has to be processed again.
And on top of that sits the real problem of estimating what an agent spends. A chat has a reasonably predictable cost per conversation. An agent does not. It depends on how many turns it needs to finish, and that varies with the task, with the state of the repository, with whether the first approach fails. The same request can cost four calls or forty.
That is why a flat rate fits this workload so well. It does not save you a percentage off an invoice: it takes the variance away. You can leave an agent running for an hour without the cost of the task being an unknown until it finishes.
The benchmarks of DeepSeek V4.1 Flash
V4.1 Flash does well on several agentic and software benchmarks. It scores 90.6 on Terminal-Bench 2.1, 74.2 on DeepSWE, 54.8 on AutomationBench and 31.8 on Agents' Last Exam. On those tests it lands level with or above the closed comparators DeepSeek publishes.
It is worth knowing where those figures come from.
The 90.6 on Terminal-Bench is obtained with DeepSeek Harness Minimal. With Codex, the same checkpoint and the same task give 84.1. The 74.2 on DeepSWE comes from mini-SWE; with OpenCode, 65.5.
Almost nine points without changing the model.
This is a model that behaves very differently depending on the harness, the tools, the context strategy and the infrastructure around it.
It is exactly the idea we explored in Inside DeepSeek Harness : same model, different agent.
V4.1 adds another layer to that story. The architecture of the model is also starting to change around the way those agents work.
It does not win everywhere either. On Terminal-Bench 4.0 it gets 31.2 against 51.8 for Opus 5. On Humanity's Last Exam, 36.8 against 56.3. The report itself acknowledges room on agentic science tasks and on multimodal work.
The pattern fits the architecture they have presented rather well: V4.1 Flash is especially interesting when the work combines agents, tools and a lot of context. That does not mean it is automatically the best model for any hard task.
So what is V4.1 Flash?
The interesting part is not summing it up as a faster DeepSeek.
DeepSeek has grown the backbone to 552B and, at the same time, cut a great deal of the model that is active while reading and the memory needed to hold context.
That points in a fairly clear direction: more total capacity without making the cost of each step grow in the same proportion.
For a long time we compared models by asking how much they knew or what it cost to generate a million tokens.
With agents another useful question starts to appear: what it costs to keep the model working until the task is finished.
V4.1 Flash is one of the most explicit designs so far around that question.
It is live on Helmcode
V4.1 Flash is available on every plan, on EU infrastructure and with no log retention.
About the id. deepseek-v4-flash now points at V4.1 Flash. If you were already using it, you are receiving the new model without touching your integration. We are keeping the id because DeepSeek has retired V4 Flash and renamed theirs to deepseek-flash, and we would rather you did not have to change code over someone else's naming change.
That said, it is a different model behind the same name. If you have tuned prompts or a suite of evals in production, it is worth running it again: the architecture changes in this version affect how it behaves with long contexts.
curl https://api.helmcode.com/v1/chat/completions \
-H "Authorization: Bearer sk-your-key-here" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"reasoning_effort": "high",
"messages": [
{
"role": "user",
"content": "Explain RAG in one sentence."
}
]
}'You need an active Helmcode or NaN subscription and a key from your Dashboard .
- The full architecture, with figures
- What the plans include
- Every model we serve
- The right open model for every use case
If you want to size it against what you are paying per token today, tell us what you run and we will work it out with you.
