DeepSeek V4.1 Flash: A Brand-New Base Model Wearing a Point-Release Number

DeepSeek V4.1 Flash shipped on September 10, 2026: open MIT weights, a one-million-token context, a brand-new Causal Encoder-Decoder architecture, and a 552-billion-parameter mixture-of-experts backbone that DeepSeek's own model card files under what the company calls its "new architecture family." It is also, if the tracker who flagged the naming is right, the first time DeepSeek has hung a .1 version number on a completely new base model — a label that normally signals a tune-up, not a rebuild. DeepSeek V4.1 Pro, the flagship that number now implies, still does not exist.

That mismatch is worth more than a naming quibble. Anyone comparing DeepSeek generations by version number will read "V4 Flash to V4.1 Flash" as a patch step and budget attention accordingly. The architecture underneath says otherwise, and the company's own decision to retire a 1.6-trillion-parameter flagship in favor of a Flash model says otherwise more loudly still.

What actually shipped on September 10

This one is not a leak and not a beta. The two-day API test that began September 8 under the model ID deepseek-v4.1-flash-expires-on-0910 ended the way its suffix said it would, and the real release landed today across DeepSeek's web app, mobile app, and first-party API, with weights and a technical report published on Hugging Face under deepseek-ai/DeepSeek-V4.1-Flash.

The practical details matter more than the ceremony:

• Model name — call deepseek-flash. The legacy names deepseek-v4-flash and deepseek-v4-flash-vision-exp are still accepted, but they no longer resolve to the models they used to: both are retired, and requests naming them are served by DeepSeek V4.1 Flash and billed at the Flash rate.

• What's in the box — 552B backbone parameters, a 1M-token context window, 384K maximum output, JSON output, function calling, and a thinking mode that is on by default with low, high and max effort settings.

• Licence — MIT, weights included, with an inference folder and a separate encoding module in the repository. DeepSeek is explicitly inviting the open-source community to build inference support, which is the standard signal that day-zero serving in the major runtimes is a matter of days rather than weeks.

The .1 that isn't a point release

The claim that started this piece came from teortaxesTex, a pseudonymous but closely followed DeepSeek watcher, in a September 10 post: that this is "the first time DeepSeek labels a completely new base model with a .1 release version," that V4.1 is "more different from V4 than, say, LLaMA 3 from LLaMA 1," and that DeepSeek "don't feel this is worth V5 yet" — without the poster being able to say why not.

Treat the causal part as inference and the structural part as checkable. The inference — why DeepSeek picked .1 over V5 — is one observer's read and nothing more; no one outside the company has explained the decision, and DeepSeek's own materials never address it. The checkable part is the architecture, and it does not read like a point release. DeepSeek's changelog describes V4.1 Flash as "the smallest model in our new architecture family," which is a strange sentence to write about a version bump: a version bump extends a family, it does not found one.

There is a real cost to the ambiguity, and it lands on buyers rather than on DeepSeek. Version numbers are the cheapest signal a developer has for "is this a new generation or a retune, and how much of my evaluation budget does it deserve?" DeepSeek has now made that signal unreliable in one direction — a model that founds an architecture family sits one decimal place away from one that changed its post-training recipe. The company gets to keep its V5 marker in reserve. Everyone doing a migration assessment pays for the confusion.

What "new architecture" means in the weights

The model card is unusually specific, which makes the generational claim easy to test without a single benchmark. Four things stand out.

• Asymmetric activation — the Causal Encoder-Decoder split is a 40-layer transformer organized as a 20-layer causal encoder followed by a 20-layer decoder, where the decoder's global KV cache is projected from the encoder's final hidden states rather than derived from each decoder layer's own. The point of that design is that the model activates only 8B parameters per token during prefill and 16B during decode. Input-heavy agent workloads — long documents, long tool traces — get the cheap half of the model; generation gets the expensive half.

• KV cache compression, measured per token — DeepSeek-V4.1-Flash runs FP4 main KV caching at 890 bytes per token, which the card puts at roughly a quarter of DeepSeek V4 Flash. Chinese coverage went further and framed the compression against the first-generation V4 model as a 437× reduction; that larger figure is vendor-sourced arithmetic on a different baseline, so treat it as a claim rather than a measurement.

• SWA Bounded Replay — sliding-window attention normally forces you to persist KV state to SSD to reconstruct context. This rebuilds missing SWA KV states by replaying only the most recent window of tokens instead, cutting the persistent KV footprint to about an eighth of DeepSeek V4 Flash's.

• Compressed Sparse Attention 2 — each attention layer runs in one of three static modes (Full, Reindex, or Reuse), sharing KV and indexer state across layers, with a hierarchical sparse indexer bounding the cost of deeper layers independently of context length.

Read those four together and the strategic picture is legible: this is a sparsity and cache-efficiency architecture first, sized so the same structure can be scaled up later. The mention of a "new architecture family" is doing real work — it is a statement that there is more coming.

The benchmarks: vendor-reported, and not yet contradicted

DeepSeek published a benchmark set with the release. On the company's own numbers, V4.1 Flash scores GPQA Diamond 90.9, a Codeforces rating of 3471, MathArena Apex 65.6, Terminal-Bench 2.1 at 90.6, DeepSWE v1.1 at 74.2, and 63.9 on HLE with tools — the last carrying a footnote restricting the baseline 36.8 figure to the pure-text subset of that benchmark.

Label those for what they are. They are vendor-reported, published without an accompanying independent evaluation, and they are the numbers DeepSeek used to justify retiring its own flagship — which makes them the numbers most worth checking. As of the September 10 launch, Artificial Analysis had not published a measurement of DeepSeek V4.1 Flash, and Hugging Face's own model page still carried the note that the model "isn't deployed by any Inference Provider." The load-bearing claim of this release — that a Flash-tier model comprehensively beats a 1.6T-parameter flagship on performance, cost, speed and total processing time — is currently a vendor claim with no external audit.

There is an honest caveat on the other side too. The same vendor reporting has V4.1 Flash winning 13 of 16 comparisons against Kimi K3 and 11 of 13 against GLM-5.3, while still trailing GPT-5.6 Sol and Claude Opus 5 on the newer Terminal-Bench 3.0 and 4.0 tasks and on ProgramBench. That is a coherent shape — strongest at the coding, terminal and agent-automation work this architecture is optimized for, weaker at frontier-reasoning tasks — and it is the shape a real generational step would have.

The price, and the routing switch worth calendaring

New pricing took effect with the launch, and it is the same Flash rate card as before rather than a cut: on deepseek-flash, cache-hit input runs $0.003 per million tokens off-peak and $0.006 at peak, cache-miss input $0.15 and $0.30, and output $0.60 and $1.20. Peak is exactly double off-peak and applies 01:00–04:00 and 06:00–10:00 UTC on weekdays.

The cut lands on Pro traffic instead. DeepSeek V4 Pro is priced at $0.022 and $0.044 cache-hit input, $0.66 and $1.32 cache-miss input, and $1.98 and $3.96 output — so routing Pro-named requests to V4.1 Flash drops their output cost by roughly 70% while, by DeepSeek's account, raising the capability that answers them.

That reroute is scheduled, not hypothetical. After 12:00 Beijing time on September 14, 2026, requests naming deepseek-v4-pro go to V4.1 Flash and are billed at Flash pricing, and stay there until DeepSeek V4.1 Pro ships. If your integration hard-codes the Pro model name, nothing breaks — you get a different model at roughly a third of the output price, with no code change and no notice beyond a changelog entry. If you route by capability tier rather than by model name, September 14 is the date to re-test.

What this means if you call DeepSeek today

OrcaRouter does not carry DeepSeek V4.1 Flash yet — as of today, the model page for deepseek-v4.1-flash returns "model not found," and we would rather say that plainly than imply otherwise. Two things follow. First, the reroute DeepSeek announced is a first-party API behaviour, so the September 14 switch happens on DeepSeek's own endpoint regardless of how you reach it. Second, if you want the new architecture today, you are calling the vendor directly.

What we do route is the rest of the DeepSeek line on one key: DeepSeek V4 Flash and DeepSeek V4 Pro, alongside 200+ other models. Pricing there is DeepSeek's provider list price passed through with 0% markup, which is the part that matters for a release like this one — when a vendor cuts a rate, the cut is live on our side the same day rather than after a repricing cycle. And when V4.1 Flash does land in the catalogue, the off-peak half-rate above is the rate, not a discount we negotiate.

The routing argument for a model this new is not really about price. It is about how much of your production path you stake on a first-week architecture with no independent benchmark and no third-party serving. Keeping the new model behind a tier you can switch — or testing it on a key that is not your production key — is the difference between an evaluation and an incident.

What would settle the naming question

Three things, in ascending order of how much they would tell you.

An independent evaluation of DeepSeek V4.1 Flash would test the architecture claim on someone else's harness. That is the one measurement that turns a vendor table into a fact, and it is the most likely next piece of news.

DeepSeek V4.1 Pro would test the family claim. The routing notice named it as the endpoint of the Pro-to-Flash window, which makes it the model this whole release is structured around — and it remains the one DeepSeek has confirmed the least about: no card, no parameter count, no date, no weights, no price.

And the useful if unglamorous one: whether DeepSeek does this again. A second .1 label on another new base model would turn an anomaly into a convention, and convention is something a developer can plan around. One model is a curiosity. The naming only becomes misleading in a useful way once there is a pattern.

For now, the practical read separates cleanly by who you are. If you are on DeepSeek V4 Pro, put September 14 in the calendar and re-run your evaluations before then, because the model behind that name is changing whether or not you ask it to. If you are on DeepSeek V4 Flash, you are already being moved, at the same price, onto an architecture DeepSeek built to scale. And if you were waiting for V5, the honest answer is that DeepSeek appears to have shipped the generation and declined to name it — which is the sort of thing you only get to do once before people stop trusting the number.