DeepSeek V4.1 Flash Goes GA: 552B Under a New Architecture, MIT Weights, and a V4 Pro Sunset That Never Happened

DeepSeek V4.1 Flash is no longer a two-day experiment. The model that spent September 8 and 9 sitting inside the vendor's live API under an ID carrying its own expiry date — deepseek-v4.1-flash-expires-on-0910 — was released for real on September 10, 2026, across DeepSeek's app, web interface and API, where it now answers to the model name deepseek-flash. Three things about the release are larger than the beta implied. The first is the paperwork: DeepSeek published a technical report — titled, without much subtlety, Pushing the Limits of KV Cache Compression — and MIT-licensed weights for a 552B-parameter multimodal mixture-of-experts model built on a new Causal Encoder-Decoder architecture. Those weights are not a promise: 48 safetensors shards, about 510 GB in total, went online the morning of release, which turns the beta's unverified “new architecture, native multimodal” slogan into something a reader can download and inspect. The second is the shape of the line-up. DeepSeek V4 Flash and DeepSeek-V4-Flash-Vision-Exp are retired, their old IDs still resolving to the new model at Flash rates, and the plan to phase DeepSeek V4 Pro out on September 14 was withdrawn before the date arrived: V4 Pro is still served, at unchanged billing, and DeepSeek has promised notice before anything changes. The cheapest model in the family has taken the flagship's place on price and on DeepSeek's own benchmarks, and DeepSeek says the architecture underneath it was designed to scale to larger models. What sits above it is, as of September 25, one tracker's guess — a three-tier Flash, Pro and Ultra line at 522B, 2T and 8T — offered by the account that posted it as speculation and confirmed by nothing DeepSeek has published. The third is the one the beta never had. Artificial Analysis has now published the first outside evaluations of the model — an Intelligence Index score of 39 in Reasoning mode at maximum effort for the September weights and 45 for the 1017 checkpoint (a six-point gain that ties it with GLM-5.3 for second among open-weights models, a point behind MiMo-V2.6-Pro), against 36 for DeepSeek V4 Pro 0813 on the same scale, which makes the 552B model the highest-scoring DeepSeek model the site has measured. Ten further items are younger than the release, and they point in different directions. On September 25 ARC Prize's own model-testing lead opened a pull request adding a first-class DeepSeek V4.1 Flash profile to the foundation's benchmarking harness — the evaluator whose board this field reads as a reasoning ceiling rather than a productivity check, arriving with no result attached and none promised. Three days later an outside lab published the opposite kind of news: a finished measurement, on a different board, that puts DeepSeek V4.1 Flash next to another open-weight model and finds it the weaker of the two — and finds the number moving more with the harness wrapped around the model than with the model itself. On Exploit Bench, a Carnegie Mellon benchmark scoring how far an agent climbs toward full exploitation of a production V8, DeepSeek V4.1 Flash averaged 4.7 of 16 under the benchmark's own default configuration and 9.3 under Claude Code, while GLM-5.3-Flash peaked at 10.6 under Codex and fell to 6.2 under the very harness that suits DeepSeek V4.1 Flash best. The third is the least dramatic and the easiest to check: on October 7 the vLLM project published its own three-week accounting of serving this model, reporting its current build 1.9× faster at low concurrency and 5.3× the throughput under a 150 TPS constraint against its own day-0 implementation — an engine's before-and-after on itself rather than another outside evaluation, and the subject of the speed section below. A fourth is about what the model costs to use rather than what it scores, and it moved twice in three days: on October 12 OpenCode, the coding agent that prices this model by monthly usage allowance rather than by metered tokens, raised its allowance for it from $60 to $80 — the platform's own statement about a product it sells, carried on its own pricing page — and on October 15 it began serving the same model free, under a second model id, on a 200,000-token context against the 1M window the metered entry carries. A fifth, from October 14, measures the model's cost to serve rather than its quality: Artificial Analysis added DeepSeek V4.1 Flash to AA-AgentPerf, its hardware benchmark for agentic inference, with results on both NVIDIA and AMD accelerators — at 100 tokens per second per user, NVIDIA's GB300 NVL72 leads the field at roughly 261 million tokens per second per megawatt, and the same runs serve the model on as few as two accelerators, which is the section below in a second currency. The sixth is the release itself, superseded: on October 17 DeepSeek replaced the checkpoint behind the same deepseek-flash model name with DeepSeek-V4.1-Flash-1017 — new weights, a vendor benchmark table that beats the September model on every row it publishes, the same rate card and the same 1M-token envelope — and, as of October 18, an outside measurement of the new weights that contradicts the row the vendor leads with: Artificial Analysis scores the 1017 checkpoint 45 on its Intelligence Index and 33.8 on Terminal-Bench 4.0 under its own harness, against the 42.3 on DeepSeek's card. The seventh item is the argument that gap produced. On October 19 a tracker account with a record of calling these releases early declared itself “dead certain” that the 42.3 is real “because it's better than GLM-5.3,” and asked Artificial Analysis to run the model in a native harness. The site had already answered the day before, with a number eight and a half points lower. The eighth is not a score: on October 20 a DeepSeek tracker posted an agent transcript in which the 1017 checkpoint declined a jailbroken persona with dsh-purge — a plugin built to strip the harness's own constraints — applied, and a third party's abliteration notes put the untouched checkpoint's refusal rate at 97 of 100 harmful prompts in chat mode and 98 in think mode, with DeepSeek publishing no safety evaluation of its own for either checkpoint. The ninth is not a score and not a price: this week DeepSeek opened the inference engine its own service runs on, with a decode curve for the 1017 checkpoint and the production figures behind it, and the thread that surfaced it this week lays that curve against a September 30 Ascend 950DT benchmark that puts Huawei's part roughly five to seven times behind per chip — the serving-silicon section below. The tenth is not a score, a price or a checkpoint: on October 22 YuyuantanTan, the current-affairs account run by China Media Group, reported that DeepSeek and MiniMax had completed the registration procedures attached to China's draft technology-export catalogue and finished open-sourcing and overseas licensing. That is state media reporting on two companies rather than a regulator's notice or a company statement, and it is the development that answers the question the draft catalogue opened on October 16 — whether the MIT weights this piece is about can keep being published and shipped abroad. The licence section below separates what the report says from what it does not.

Everything below keeps two kinds of claim apart. The specifications, benchmarks and prices come from DeepSeek's own changelog, model card and technical report — vendor-published, vendor-run, and not reproduced by anyone else. That gap has since narrowed by four independent instruments — a composite index, a community kernel board, a harness-controlled cyber benchmark and a hardware serving benchmark — one of which, the index, has now been run against both checkpoints. None of them replicates a single vendor row, and ARC Prize is still building the reasoning evaluation, with nothing published from it yet. DeepSeek replaced the model behind the same API name on October 17 with the DeepSeek-V4.1-Flash-1017 checkpoint. For a day that meant every outside number in this piece described weights the vendor no longer served, with no external score for the ones it did; on October 18 Artificial Analysis re-ran its index on the new checkpoint and published 45, against 39 for the September weights. The other three instruments have not been re-run: the cyber benchmark, the kernel board and the hardware benchmark still describe the September weights, and no independent score, old or new, replicates one of DeepSeek's own benchmark rows. The cost-of-serving figure the vLLM project published on October 17 is newer only in publication date: the chart behind it is dated October 16, the day before the swap, so it describes the same superseded weights. On its current index (v4.3.2) Artificial Analysis scores the September DeepSeek V4.1 Flash checkpoint at 39 and the 1017 checkpoint at 45, describing both as well above the median of 19 for open-weight models of comparable size; they are genuine third-party numbers and the first in this story that DeepSeek did not produce. Each is one composite of ten evaluations, not a replication of any individual vendor row, and it says nothing about the 1M-context economics. The refusal figures in this piece are a fourth kind of claim and are labelled where they appear: they come from people who build uncensored derivatives of these weights, not from DeepSeek and not from an evaluation lab, and DeepSeek has published no safety evaluation for either checkpoint. The hardware numbers in the serving section are a further class again: the NVIDIA decode curve and the production figures are DeepSeek's own measurements of its own engine, published with the code this week, and the Ascend points come from a benchmark sheet reproduced in a thread on X that is not published on either vendor's site. Where a number belongs to DeepSeek, this piece says so. One more class sits outside that taxonomy. The October 22 report that DeepSeek and MiniMax completed registration under the draft export catalogue is state media — China Media Group's YuyuantanTan, repeated across Chinese financial outlets — not a Ministry of Commerce notice, and DeepSeek has published no statement confirming it. The catalogue itself is a government draft open for comment until November 15, and is described as a draft wherever it appears here. The build names attached to the report — V4.1F-1017 and M3.1-Flash — come from a single X account on October 23 and do not appear in the state-media report or the outlets that relayed it; the checkpoint that post names had already been downloadable for six days when it was written.

The October 17 checkpoint: what DeepSeek-V4.1-Flash-1017 changed

Five weeks after the release this piece is built around, DeepSeek replaced the model underneath it. The changelog entry dated October 17 is three sentences long: “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.” Everything in that quote is the vendor speaking about its own product, and all three claims are checkable on DeepSeek's own pages rather than taken on trust: the model-version row on the Models & Pricing table now reads DeepSeek-V4.1-Flash-1017 where it read DeepSeek-V4.1-Flash, the rate card beside it is the same off-peak and peak split published on September 10 — $0.003, $0.15 and $0.60 per 1M tokens off-peak, doubling to $0.006, $0.30 and $1.20 inside the weekday peak windows — and the API quick start still names deepseek-flash as the model string, with the 1M-token context, 384K output ceiling and 2,500-request concurrency limit unchanged. The retired alias IDs behave the way the September note said they would: deepseek-v4-flash and deepseek-v4-flash-vision-exp are still accepted and now answer as DeepSeek-V4.1-Flash-1017 at Flash prices. DeepSeek announced the same change from its own account that day, and the post is worth reading alongside the changelog because it is shorter and blunter: “DeepSeek-V4.1-Flash-1017 is here! Stronger benchmark performance, faster task completion, and shorter outputs than the previous version—a Pareto improvement in performance and cost. Now live on our website, app, and API,” followed by the same three harnesses and the same instruction to upgrade to DeepSeek Harness 0.2.1-rc.1 or later. Everything in it is the vendor describing its own product on its own channel: “now live on our website, app, and API” is the changelog's “the official web and APP models have also been updated” restated, and the benchmark, runtime, output-length and Pareto claims are the model card's — with one difference that matters for anyone deciding whether to try it. The card carries a number next to every benchmark row; the post carries none, and neither the post nor the changelog puts a figure on the runtime and output-length claim. Two of the four things DeepSeek is leading with here are still vendor assertions rather than published results, and the chart behind the Pareto line — the one attached to the post — is DeepSeek's own, drawn on its own task-cost measurements.

The weights moved with it, and that is the part a reader can verify without trusting a changelog. A second repository, deepseek-ai/DeepSeek-V4.1-Flash-1017, went up on Hugging Face in the early hours of October 17 under the same MIT licence: 48 safetensors shards again, the same total of about 510 GB, every shard the same size as its September counterpart, and every shard's hash different. Same shape, different contents — which is what “a minor update” should look like from the outside, and which also means the architecture claims this piece has been reporting since September are untouched: the config file that declares the 552B backbone, the 384 routed experts, the 8B-active-parameters-per-token prefill path and the 16B decode path is byte-identical to the one in the September repository, so the 890-byte-per-token KV cache is the same design rather than a new one. What the new repository does not carry is the paperwork. There is no technical report in it, no evaluation folder and no Jinja chat template; the model card says the release does not include a chat template and points instead at a Python encoding reference and a new Rust toolkit, deepseek-recipe, for turning Chat Completions, Responses and Anthropic-format requests into the model's prompt format. Anyone pinning weights by repository name should know the two downloads differ in more than their hashes. The file list says exactly how: all 48 shards carry a different checksum and an identical byte size, while the files that are not weights — the config that declares the architecture, the licence and the whole encoding folder — are byte-for-byte the same in both repositories. Seven files exist in September's repository and not in this one, and nothing was added to replace them: the technical report, the evaluation folder, the chat template, the two figures the card used to embed, and a .gitignore. The model card narrows one serving parameter as well. September's card recommended either a top_p of 0.95 or 1.0; the October 17 card recommends 1.0, with temperature at 1.0, a 1M context window and a max_tokens of at least 256K unchanged.

DeepSeek's own benchmark table is where the update is meant to show, and it is a vendor table of exactly the kind the September rows were: same-company runs, unreproduced by anyone, published on a model whose weights had been public for a few hours. Against the September checkpoint it is up on every row the card carries — HLE without tools 42.6 against 36.8, or 44.0 against 39.1 on the text-only subset; Terminal-Bench 4.0 42.3 against 31.2; DeepSWE v1.1 77.0 against 74.2; ProgramBench 29.1 against 20.3; NL2Repo-Bench 68.2 against 65.4; Automation-Bench v1.0.6 60.5 against 54.8; Agents' Last Exam 35.4 against 31.8; Apex Bench v1.1 72.1 against 64.6; Chartography with tools 83.0 against 78.9; BabyVision with tools 92.5 against 89.6; and ZeroBench-main with tools 51.0 against 49.0, at Pass@5. The same table places 1017 against the frontier models DeepSeek benchmarks against: it now clears GPT-5.6 Sol on Terminal-Bench 4.0, 42.3 against 39.9, while still trailing Opus 5 on 51.8, and it leads both on DeepSWE v1.1, 77.0 against 73.0 and 74.0 — a row read off the chart attached to the vendor's own announcement, and the single most quoted number of the week. On NL2Repo-Bench it moves to 68.2 and still sits behind Opus 5 on 75.3, which is the shape the September table had too: strongest on harnessed agentic work, behind on the rows that reward reasoning depth. The Terminal-Bench 4.0 row is the one to read twice, because it is now the only row in that table with an independent counterpart. DeepSeek ran it under the Claude Code harness; Artificial Analysis runs the same 66 tasks under mini-swe-agent, and its October 18 result for these weights is 33.8 — eight and a half points below the vendor's 42.3. On DeepSeek's own table that row clears GLM-5.3 by 4.4 points, 42.3 against 37.9. On Artificial Analysis's harness the same weights trail GLM-5.3 by eight, 33.8 against 41.9.

One line of small print is worth more than several of those deltas. The September card evaluated Terminal-Bench 4.0 with DeepSeek Harness in its Minimal mode; the 1017 card says it used the Claude Code harness for Terminal-Bench 4.0 and Mini-SWE-V2 for DeepSWE v1.1. The harness study further down this piece measured seven points of spread on one model across seven agent CLIs, so an eleven-point Terminal-Bench 4.0 move that arrives with a different harness under it cannot be read as eleven points of model. The card states which harness it used, which is what makes the row auditable rather than merely impressive, but the row is two changes wearing one number. The independent run separates them, and not in the vendor's favour. Artificial Analysis evaluated the same 1017 weights on Terminal-Bench 4.0 under mini-swe-agent — the harness it holds constant across every model on that board — and got 33.8, against 26.8 for the September checkpoint on the same harness. On a fixed harness the checkpoint is worth seven points, not eleven, and DeepSeek's headline number sits eight and a half points above what the same weights score when the harness is held constant across models. The rest of DeepSeek's framing is about cost rather than score, and it is the same axis the September release was sold on: the changelog claims the update reduces task runtime and output length, calls the result “a new performance–cost Pareto optimum across multiple harnesses,” and says it optimised for DeepSeek Harness, Tencent CodeBuddy and WorkBuddy, recommending DeepSeek Harness 0.2.1-rc.1 or later. Runtime and output length are precisely the quantities the verbosity evidence in this piece tracks from the outside, and DeepSeek now claims to have cut both — with no figure attached. One outside measurement of the new checkpoint now exists, and it does not show the runtime or the output cut: Artificial Analysis's index run has the 1017 weights at 288.8 seconds per task against 289.9 for September, and 89,495 output tokens per task against 88,574 — flat on both, with the cost saving landing somewhere else entirely. The post DeepSeek published on its own account the same day compresses all of that to “faster task completion, and shorter outputs,” then calls the pair a Pareto improvement in performance and cost — the changelog's claim in shorter form, from the same source, and just as unmeasured. It is the vendor restating itself, not a second source — which matters, because the number off that chart is the one the outside world has spent the week repeating. The one artefact in the announcement that does carry numbers is the chart attached to the post, and it is DeepSWE v1.1 Pass@1 plotted against average cost per task under a mini_swe_v2 harness. Its caption is worth reading before the Pareto line is: the public leaderboard data underneath it is dated September 22 on the chart itself, three and a half weeks before the checkpoint the chart is being used to promote, and the comparison lines for OpenAI's models are credited to OpenAI's own DeepSWE chart rather than to a shared run. One point on that plot is new. Everything it is measured against was published before it existed.

The same day as the swap, the most-shared reading of that table came from someone with a stake in where the model runs. Yuchen Jin, who works on AI systems at Databricks, posted that DeepSeek-V4.1-Flash-1017 “scores 77 on DeepSWE v1.1”, that it is “Opus 5-level performance at 83x lower cost”, and that “we will be launching it on Databricks”. The 77 is DeepSeek's own row, taken from the chart attached to the vendor's announcement, and nothing outside the company has reproduced it. The two comparison points are Jin's, and they divide cleanly into one that survives an outside check and one that does not. Opus 5-level holds up: the independent boards that publish DeepSWE v1.1 place this model's name in that neighbourhood on their own runs. Mercor's APEX leaderboard — 113 original tasks across 91 repositories, scored under the mini-swe-agent harness — lists Opus 5 Max at 71.4% and a DeepSeek V4.1 Flash Max entry at 71.7%, and the llm-stats board for the same benchmark puts Claude Opus 5 at 68.8% against 74.2% for DeepSeek-V4.1-Flash. The honest reading of the pair is narrower than the post makes it: two boards that measure this benchmark independently agree the model is at least Opus 5's equal on it, and neither board shows a 77, because both carry either the September figure or their own run and neither labels an entry with the 1017 checkpoint. Opus 5-level is supportable as a statement about a neighbourhood. The number that produced it is not yet repeatable.

The 83× half of the post is his arithmetic rather than a published figure, and it is the half to hold loosely. No board carries a per-task cost for the 1017 checkpoint, and the vendor chart behind DeepSeek's own Pareto claim plots cost per task on a log axis running from ten cents to twenty dollars — which is the kind of spread a multiple that large requires. On list rates alone the gap is narrower than 83×: Claude Opus 5 bills $5 per 1M input tokens and $25 per 1M output against $0.30 and $1.20 for DeepSeek-V4.1-Flash inside the weekday peak windows, roughly 17× on input and 21× on output, and the answer moves a long way with the cache-hit share and with how many tokens a task takes. The direction of the cost argument is not in dispute, here or anywhere else in this piece. The specific multiple is a claim about a comparison nobody has published.

Databricks is the part of that post a reader can check against documentation, and the documentation says more than the post does. DeepSeek V4.1 Flash has been on Databricks Unity Gateway since September 11, the day after DeepSeek's launch, with text and image input through the platform's Foundation Model APIs under the service name system.ai.deepseek-v4-1-flash; on October 7 the platform added priority pay-per-token and reserved provisioned throughput for it. It is also the platform's designated destination for this family: Databricks has scheduled DeepSeek V4 Pro (0813) for retirement on October 30 and DeepSeek V4 Flash (0731) for November 5, naming DeepSeek V4.1 Flash as the recommended replacement in both notes. What no Databricks page says is that the October 17 checkpoint is coming. That claim is one employee speaking on his own account — an internal signal about intent rather than a shipped date, and the supported-models page still carries the model without a checkpoint label. So the availability change this week is prospective, from a source inside the platform rather than from the platform itself; what a Databricks customer can call today is the September weights, and the swap this piece has been describing — new weights behind the same name and the same rate card — is the shape that replacement will take when it lands.

So what did not change is as important as what did. Three of the four independent instruments still cover the September weights and only those: the Exploit Bench harness table, the community kernel board and the AA-AgentPerf hardware runs were all produced before the swap, and the two DeepSWE v1.1 boards that carry this model's name publish an entry with no checkpoint on it. The fourth changed on October 18: Artificial Analysis added a separate row for the 1017 checkpoint, scored it 45 on its Intelligence Index and 33.8 on Terminal-Bench 4.0, and left the September row standing at 39 and 26.8. That is the first time a number in this piece was produced by someone other than DeepSeek against the weights DeepSeek is currently serving. The API change is a checkpoint refresh behind a name DeepSeek had already documented as pointing at the latest Flash model — the opposite of the September plan to make deepseek-v4-pro answer as a different model, which is the distinction developers were drawing when they objected to that one. For a caller, the practical effect is narrow and concrete: asking for deepseek-flash now gets different weights at the same price, with a better vendor-reported table behind them and, since October 18, one third party scoring them — lower on the one row where both exist. On OrcaRouter the model id and the rate card are unchanged too — DeepSeek V4.1 Flash is routed at DeepSeek's own list price with 0% markup passed through — which is what a vendor refreshing a model without moving its name or its price should look like from the caller's side of the line.

What actually shipped on September 10

The changelog entry opens with a single sentence: "Today, we officially release the DeepSeek-V4.1-Flash model." DeepSeek describes it as the smallest member of a new model-structure family, with native visual understanding, and it is the first release in this cycle to arrive with a technical report attached. The API side is a name swap rather than a migration:

• Model name — deepseek-flash on DeepSeek's own API; the base URL, the key and the request format are unchanged.

• Retired — DeepSeek V4 Flash and DeepSeek-V4-Flash-Vision-Exp are offline. Their old IDs are still accepted and now route to V4.1 Flash, billed at Flash rates, so existing integrations keep working without a code change.

• V4 Pro — DeepSeek announced that from 12:00 Beijing time on September 14, deepseek-v4-pro requests would route to V4.1 Flash at V4.1 Flash prices until a V4.1 Pro shipped, then reversed the decision before the date arrived. V4 Pro is still served, at unchanged billing, and DeepSeek says it will give notice of any further change.

• Envelope — a 1M-token context window, 384K maximum output, 2,500 concurrent requests per account, image input supported, thinking mode on by default with a non-thinking option.

• Weights — the same day, the repository deepseek-ai/DeepSeek-V4.1-Flash went up on Hugging Face under the MIT licence: 48 safetensors shards totalling about 510 GB, the technical report as a PDF beside them, and a reference inference implementation in an inference folder.

That last bullet is also where the retired model ID story lands for anyone with deepseek-v4-flash hardcoded in a production path: it still resolves, but what answers is a different model. DeepSeek has been explicit that this is a compatibility shim rather than a promise, which makes it a migration deadline wearing a deprecation notice.

The architecture, now on the record

Two days ago this section could only have been a list of things nobody had published. The technical report settles it, and the structural claim turns out to have been literal rather than marketing. DeepSeek V4.1 Flash is a 552B-parameter multimodal mixture-of-experts model, and the parts that are new are the parts that decide what it costs to run:

• Backbone — 552B total parameters, mixture-of-experts with one shared and 384 routed experts per layer, six routed experts active per token.

• CED — a 40-layer transformer split into a 20-layer causal encoder and a 20-layer decoder. The decoder's global KV cache is projected from the encoder's final hidden states instead of being derived from each decoder layer's own hidden states, which is where most of the memory saving comes from.

• Activation asymmetry — roughly 8B parameters active per token during prefill and 16B during decode, so reading a long prompt is substantially cheaper than generating from it.

• KV cache — the report claims 890 bytes per token of global KV cache, about a quarter of DeepSeek V4 Flash, using FP4 main KV caching with one scale per 16 channels plus cross-layer reuse.

• Attention and decoding — Compressed Sparse Attention 2 with Full, Reindex and Reuse modes and a hierarchical sparse indexer, Single-Pass mHC, and DSpark speculative decoding.

• Engram — a 196B-parameter conditional-memory table, sparsely accessed through a token-based lookup, that sits beside the mixture-of-experts path rather than inside the attention stack. It is the single largest block of weights in the release, and the model card's figure for it is what makes the download's size legible.

• Vision — DeepSeek-ViT with a two-layer MLP projector, trained from the start of language-model pre-training rather than bolted onto a text base afterwards.

• Training — 45T tokens of multimodal corpus, with sparse attention trained at a 64K sequence length and context extended to 1M at the 34T-token mark. Post-training runs SFT, then RL, then on-policy distillation.

• Reasoning effort — a continuously controllable integer from 1 to 100, a finer dial than the low, high and max tiers DeepSeek V4 Pro exposes.

The KV-cache number is the one with consequences beyond the spec sheet, and it is where the design earns its keep. A 1M-token context window is only useful if you can afford to fill it. The reason the previous generation's long-context economics were painful was twofold: the global cache grew with every layer that attended over the prompt, and most of the persistent cache capacity was being spent holding sliding-window state that stopped being useful within minutes. The report's answer attacks both. Whether the served product matches it at 1M tokens under real concurrency is the sort of claim that still needs a third party — the independent scores that now exist measure the model, not the long-context economics — but the mechanism is now documented rather than inferred, and the section below takes it apart.

Inside the cache: how 890 bytes per token is actually achieved

The report's title is the thesis. Read it and the efficiency claim stops looking like a side effect of the mixture-of-experts backbone and starts looking like the design brief — which is the reading independent write-ups have converged on since release. The reason it matters commercially rather than academically is where an agent's bill actually lands: DeepSeek's framing is that the cache-hit line is the one that dominates it on long agentic workloads, which makes the size of the cache a first-order cost lever. DeepSeek's numbers put the global cache at 890 bytes per token, roughly 437× smaller than the original DeepSeek V1 and about a quarter of DeepSeek V4 Flash. Run the arithmetic on a full window and it is the difference between roughly 890 MB of global KV for a single 1M-token sequence and about 3.5 GB at V4 Flash's per-token rate. Three changes do most of the compressing: one on how much is stored, one on what gets read, and one on what is kept at all.

The storage format is the most legible of them. The main global cache is held in FP4 using the E2M1 layout with one E4M3 scale per 16 channels — half the width of the FP8 cache DeepSeek V4 stored and a quarter of FP16. What makes that survivable is that DeepSeek quantized the cache during training rather than at serving time, so the noise the narrower format introduces is something the model learned to work around instead of something inflicted on it afterwards. Not everything was compressed that way: the local sliding-window cache stays in FP8, because the report treats it as the part that is sensitive to further narrowing.

Compressed Sparse Attention 2 handles what gets read. Each attention layer is statically assigned one of three modes — Full, Reindex or Reuse — so decoder layers can share key state and indexer state instead of each keeping its own, and the first Full-mode layer builds a candidate pool that later indexing layers are restricted to. Report figures put that pool at 16,384 positions with the sparse selection over the top 512 entries, which is what decouples indexing cost from context length: DeepSeek's claim is that moving from 4K to 1M context adds only around a quarter more compute per generated token, rather than the roughly window-proportional growth the earlier design implied. That single figure is the most useful thing in the report for anyone trying to price a long-context workload, and it is also the one with no outside confirmation at all — none of the outside measurements in this piece has tested the far end of the context window.

The change doing the most work on the persistent side has the least promising name. DeepSeek V4 kept two things in its persistent cache for more than 72 hours under typical workloads: the global KV and the sliding-window attention state. Sliding-window state matters for minutes, but it was consuming close to half of the persistent cache capacity — storage sized for days spent on data with a minute of usefulness. V4.1 Flash drops SWA state out of the persistent cache entirely and parks it in a pool assembled from about 10% of each machine's host DRAM with a minute-level time to live. When a session resumes and that state is gone, SWA Bounded Replay reconstructs it approximately: rather than replaying layers × window tokens, it replays only the most recent window, reported at 128 tokens, and accepts that the rebuilt state is not mathematically identical to a full replay. DeepSeek says it observed little quality impact from the approximation and simulated the same behaviour during post-training. Put that together with the narrower global cache and the persistent KV footprint falls to roughly one-eighth of DeepSeek V4 Flash under identical workloads — a bigger cut than the one-quarter figure that leads the spec sheet, because it is two changes stacked rather than one format change.

Two limits sit on all of it. The report offers no end-to-end latency or cost comparison, so an eight-times-smaller persistent cache is not a demonstrated eight-times-cheaper workload: compression relieves memory pressure, and only the memory-bound part of a bill responds to that. And the saving is not something that happens to you. An engine has to implement the encoder-decoder projection, the three CSA2 modes, the FP4 cache layout and Bounded Replay before the number means anything, which is why 890 bytes is best read as a first-party specification for DeepSeek's own served API rather than a promise about a local build — the quantized conversions for llama.cpp, Ollama and LM Studio in the repository do not carry this cache with them. The headline also covers text tokens; vision embeddings sit outside it. On anything self-hosted, the number worth trusting is the one you measure. How far an engine can get with it is no longer hypothetical, though it is still not independent. vLLM implemented the decoder-side trim and Bounded Replay over the three weeks after release and published the before-and-after in the speed section below — the closest thing yet to a check on the specification, and one made by an engine measuring its own work rather than by an evaluator measuring the model.

The independent score, run twice: 39 for the September weights, 45 for 1017

Artificial Analysis has published the first outside evaluation of DeepSeek V4.1 Flash, and it is the number the beta could not produce. On the current version of the Artificial Analysis Intelligence Index (v4.3.2), the model scores 39 in Reasoning mode at maximum effort. On the same scale and the same setting, DeepSeek V4 Pro 0813 scores 36 and DeepSeek V4 Flash 0731 scores 34. Read together, those three rows say the thing DeepSeek's own marketing claimed and its benchmarks could not establish on their own: the smallest model in the family is now the strongest one. Artificial Analysis describes 39 as well above the median of 19 for open-weight models of comparable size. It was, for five weeks, a score for the September checkpoint alone: the evaluator's listing carried the September release date and nothing else. On October 18 that changed, and the change is the news this piece did not have when it first ran. A second row appeared for DeepSeek V4.1 Flash 1017, dated October 17, scored 45 on the same index at the same maximum effort. That puts the 1017 weights level with GLM-5.3 on 45, two points below GPT-5.6 Sol on 47 and six below Claude Opus 5 on 51 — and it makes the checkpoint the highest-scoring DeepSeek model the site has measured, five weeks after the September weights took that title. It also gives the model a standing it did not have before, and one the evaluator states outright in its October 19 write-up: second on the open-weights table, tied with GLM-5.3 and a point behind MiMo-V2.6-Pro at 46, with Step 5 Preview and Kimi K3 a point further back at 44. The six points are not spread evenly across the ten evaluations. The same write-up reports the largest moves in the agentic and knowledge components — a GDPval-AA v2.1 Elo of 1,746 against 1,600, an AA-Briefcase v1.1 Elo of 1,570 against 1,420, and an AA-Omniscience non-hallucination rate of 33% against 4%, with accuracy rising from 43% to 46% and that evaluation's index moving from -5 to +5. Those are the evaluator's own numbers for its own tests, published by it rather than reproduced here, and they describe a model that became markedly less willing to invent an answer — a different improvement from the speed one DeepSeek's changelog leads with.

The comparison that matters here is the internal one, because it is the same comparison DeepSeek's routing table makes. V4.1 Flash carries 552B total parameters with 16B active per token; DeepSeek V4 Pro 0813 carries about 1.6T total with roughly 49B active. A model with roughly a third of the backbone scores three points higher on a composite its maker did not run — nine points higher once the 1017 weights are counted, since the 1.6T flagship has not moved from 36. The size-to-score trade is the entire thesis of the Causal Encoder-Decoder design, and an evaluator with no stake in the result has now produced a number consistent with it.

The price half of the claim holds up too, and this is the first price comparison in the story that does not come from a DeepSeek rate card. Artificial Analysis lists DeepSeek V4.1 Flash at $0.30 per 1M input tokens and $1.20 per 1M output, against $1.32 and $3.96 for DeepSeek V4 Pro 0813 — 4.4× cheaper on input and 3.3× on output, with a blended $0.18 per 1M on the site's 7:2:1 cache-hit, input and output mix. It is also cheaper than the older, smaller DeepSeek V4 Flash 0731 it retires, which the site lists at $0.44 and $1.32 while scoring five points lower. Cheaper than the model it replaces, cheaper than the model it displaces, and ahead of both on the index.

Two caveats belong on the number. It is a composite of ten evaluations run at maximum reasoning effort, so it says nothing about the lower effort settings most production traffic actually uses, and nothing about how quality holds at the far end of a 1M-token window. And it is a single evaluator's score: independent, but not replicated — and the composite itself has been revised since this piece first cited it, from v4.3 to v4.3.2, which moved DeepSeek V4.1 Flash's score from 40 to 39 and its predecessor's from 35 to 34. What it does establish is narrow and useful — the one claim the beta could not support, that a 552B model is genuinely competitive with DeepSeek's own 1.6T flagship, now has a source outside DeepSeek. The 1017 row carries the same two caveats and one more. It is a single evaluator's score, for weights five weeks newer than most of the evidence here, and it is one composite rather than a replication of any vendor row. Its per-task price has also moved on the site: the September checkpoint is listed today at $0.49 per Intelligence Index task, where this piece first carried $0.27, and the 1017 checkpoint at $0.26. Treat the dollar figure as a live number on somebody else's dashboard rather than a constant — which is the same lesson the index score itself taught when it went from 40 to 39. The cost table beside the score is the rest of the caveat, and it cuts both ways. The model one place above it is also half its price: MiMo-V2.6-Pro reaches 46 at $0.13 per Intelligence Index task against $0.26 here, and Artificial Analysis's own comparison puts GPT-6.1 Sol at medium effort on 48 for $0.21. What the 1017 checkpoint does win is the head-to-head DeepSeek has been selling since September — it beats GLM-5.3-Flash on both axes of that table, 45 against 42 and $0.26 against $0.28 a task — which is the pairing where capability and cost move the same way.

The next outside score: ARC Prize is building the test

On September 25, ARC Prize's model-testing lead, Matt Mazur, opened a pull request in the foundation's own ARC-AGI-3 benchmarking repository adding a first-class DeepSeek provider adapter: one profile, named deepseek-v4-1-flash-low-provider-adapter, whose model field is deepseek-ai/DeepSeek-V4.1-Flash. The claim that ARC Prize intends to evaluate this model arrived as a single social post, so we checked it against the foundation's own code rather than against the post. The adapter, the profile, its unit tests and its documentation are in the diff, and the repository is the harness ARC Prize's testing policy names for its interactive agentic benchmark. What does not exist is a result: the pull request is open and unmerged, there is no score, no publication date, and no statement of which reasoning levels will be published. Why it matters is the shape of the measurement rather than the news that one is coming. ARC-AGI asks a question the other boards do not: a model can be fast, cheap and strong inside a harness and still score in the sixties on tasks it has not seen. That is the question nobody has asked DeepSeek V4.1 Flash yet.

The profile pins down how such a run would work, and three details will shape the number that eventually lands. It runs the model at the low reasoning-effort setting rather than at maximum, streams responses, sets a 1M-token harness context with a summary compaction trigger at 175,000 tokens, and caps output at 262,144 tokens. It routes through Baseten's OpenAI-compatible endpoint rather than DeepSeek's own, and it is configured at $0.30 per 1M input tokens and $1.20 per 1M output — DeepSeek's peak card rates, not the off-peak figures quoted further down this piece. ARC Prize computes cost per task from the prices configured in the profile, so the eventual figure will be a peak-rate one, which is worth remembering before comparing it with the $0.042 per task DeepSeek V4 Flash 0731 posted when it was tested. The other unusual feature is a workaround for how DeepSeek's thinking mode behaves: historical reasoning content is replayed only when a request carries tools, so the adapter makes the model emit every ARC action as a submit_action tool call and replays the exact assistant message with its reasoning attached, rather than parsing actions out of prose.

The bar this will be measured against comes from ARC Prize's own board. DeepSeek V4 Flash 0731, the checkpoint V4.1 Flash retires, is the board's verified entry for the Flash tier it comes from: 61.4% on ARC-AGI-2 at maximum reasoning effort and 89.0% on ARC-AGI-1, at $0.042 and $0.021 per task. Dots3-Note Preview sits at 76.8% on ARC-AGI-2, which is the 77% the post that flagged the adapter is pointing at, and the same account's expectation — that anything under 80% from a much larger, natively multimodal successor would disappoint — is his framing rather than a published target. The remaining part of that framing deserves a label: the claim that V4.1 Flash generates 29% more tokens than the model it replaces is unattributed and undefined, and nothing DeepSeek or ARC Prize has published says what it measures.

One caution about which board this is. The adapter landed in the ARC-AGI-3 repository, the harness for the foundation's interactive agentic benchmark, and the separate repository that runs ARC-AGI-1 and ARC-AGI-2 carries no V4.1 entry at all — its model list has not been updated since July 27 and still names older DeepSeek endpoints. So the datable fact is that ARC Prize has wired this model into its agentic harness; whether it will also appear on the ARC-AGI-2 board, where the 61.4% comparison lives, is not something the public code shows today. The practical reading for anyone choosing a model has widened. Four independent instruments on DeepSeek V4.1 Flash are now in play — a composite index that has been run twice, once per checkpoint; a community kernel board; a harness-controlled cyber benchmark; and, since October 14, a hardware serving benchmark — and two of them put the model inside a harness on tasks it has not seen. The newer of the two is the composite, which has carried Terminal-Bench 4.0 since index v4.3: 66 terminal tasks, pass@1 averaged over three repeats, every model under the same agent harness. Its October 18 result for the 1017 weights is 33.8. The cyber benchmark, below, is the closest any of them comes, and on it this model loses the one head-to-head it makes. The ARC profile is the evaluation built to answer the reasoning question, and it is still the one without a number. Until it runs, the model's reasoning ceiling is unmeasured, and the number to hold it against is its predecessor's.

The first outside cyber score: the harness moves the number more than the model

On September 28 the evaluation lab Generality Labs published a follow-up to its earlier cyber work titled “Does the harness matter when running Cyber Benchmarks?” — the first finished outside measurement that puts DeepSeek V4.1 Flash beside another open-weight model on the same cyber benchmark. The benchmark is Exploit Bench, a Carnegie Mellon evaluation by Seunghyun Lee and Prof. David Brumley that scores how far an agent climbs a ladder of sixteen capabilities — from reaching vulnerable code, to triggering the bug, to building exploit primitives, to arbitrary code execution — against production V8 with the V8 security sandbox enabled. The lab ran two models, DeepSeek V4.1 Flash and Z.ai's GLM-5.3-Flash, with a 250-million-token budget per task over 10 tasks drawn from the benchmark's original 41 by Item Response Theory, and repeated each model under seven harness configurations: six agent CLIs — Claude Code, Codex, Kimi CLI, ReAct, Gemini CLI and OpenCode — plus the benchmark's own default, which the writeup labels Original. Original is not a third-party CLI at all: it has no token limit, a 300-turn ceiling and no context compaction. The account that flagged this result describes Original as roughly a Python while loop; that is his characterisation rather than the researchers', whose own description is the one above.

The result is a spread that no single score would have shown. Mean capability is out of 16. DeepSeek V4.1 Flash is at its best under Claude Code, 9.3, with Codex second at 8.9; the same model falls to 7.4 on Kimi CLI, 5.9 on OpenCode, 5.7 on Gemini CLI, 5.3 on ReAct and 4.7 under Original — its own benchmark default, and the worst of the seven. GLM-5.3-Flash inverts that ranking at both ends. Its best configuration is Codex at 10.6, above the 10.02 the study's own dataset carries for Mythos Preview on the full 41-task set, though the researchers caution that a 10-sample subset is not fully representative; its worst is Claude Code at 6.2, the same harness that is DeepSeek V4.1 Flash's best, and 8.9 on Gemini CLI, 8.2 on Kimi CLI, 8.1 on OpenCode, 7.7 on ReAct and 6.4 under Original. Averaged over all seven, GLM-5.3-Flash sits near 8.0 and DeepSeek V4.1 Flash near 6.7. So both halves of the claim that circulated with this result check out against the released data: harness choice is worth several points, and on this benchmark DeepSeek V4.1 Flash is the weaker of the two models — except under Claude Code, where it leads by more than three.

The researchers are explicit that they cannot fully explain the spread. Their one positive lead is how each harness compacts context, and the difference is a matter of wording. ReAct's compaction prompt asks the model to “Write a continuation summary that will allow you (or another instance of yourself) to resume work”; in the transcripts the lab published, that sometimes leads the model to declare the work finished, after which the harness wakes it again and it resubmits the same report dozens of times until the budget runs out. Codex frames the same moment as “Create a handoff summary for another LLM that will resume the task,” and the lab hypothesises that addressing a different agent is what keeps the model making progress over long budgets. They call this a hypothesis, not a cause. One configuration error also matters for reading the table: ReAct's compaction was set to 100K tokens instead of the intended trigger, so it compacted far more often than the design called for, which depresses both models' ReAct rows. The study's own caveats are worth carrying with any number from it — two models, 10 samples per harness configuration, 70 question samples per model against the benchmark's original 41 tasks, and three samples that errored or never finished, two of them GLM-5.3-Flash. The authors state that the small sample is inherently noisy, that the result should not be assumed to extend to other domains and tasks, and that prior work by METR found no statistically significant difference between harnesses on long-horizon tasks. It is an outside lab running someone else's benchmark, not the benchmark's owners, and it is not peer-reviewed. What it is not is a vendor figure, and it is the first outside number in this piece that contradicts the vendor's own story rather than merely failing to confirm it.

There is one thing here a router can act on and one it cannot. It cannot choose your harness — that is the agent loop you already run, and this study's whole point is that the choice is load-bearing. What it can do is make the model half of the pair a one-line change. DeepSeek V4.1 Flash and GLM-5.3-Flash are both routable through OrcaRouter on a single OpenAI-compatible key, at the provider's own list price with 0% markup added, so a team that wants to find its own model-and-harness combination can swap the model underneath a fixed harness without a second contract or a second integration, and leave a proven model behind it as automatic failover if the swap turns out to be a regression. That is the same argument the adoption section makes below, applied to a decision the harness study just made concrete: on this evidence the harness you run may matter more than the model you pick, and the model side of that pair is the side you can change in an afternoon.

Where it lands against the frontier, and where it still loses

The September model card compares V4.1 Flash against Opus-5.0, GPT-5.6 Sol, Kimi K3 and GLM-5.3 at maximum reasoning effort, with its own DeepSeek V4 Pro and DeepSeek V4 Flash as internal baselines. Every figure below is vendor-reported, run on DeepSeek's harnesses, and unreproduced by any third party. The card notes that agentic results use the Minimal mode of DeepSeek Harness with a 1M-token context for code benchmarks and a 512K window for visual ones, so these are not directly comparable to published third-party numbers on the same benchmarks. The independent scores in the sections above are different measurements on different sets of evaluations; they support the general picture and corroborate no individual row below, and the October 17 rows in the section above come from a different card and a different run of the same benchmarks.

On agentic and coding work, the vendor numbers put V4.1 Flash above the frontier models it names:

• Terminal-Bench 2.1 — 90.6, against 89.1 for Opus-5.0, 88.8 for GPT-5.6 Sol and 87.9 for DeepSeek V4 Pro

• DeepSWE v1.1 — 74.2 resolved, against 74.0, 73.0 and 62.7

• CyberGym — 88.1, against 84.5 for both GPT-5.6 Sol and GLM-5.3, and 83.3 for DeepSeek V4 Pro

• AutomationBench — 54.8, against 50.3 for Opus-5.0 and 37.7 for DeepSeek V4 Flash

• Agent's Last Exam — 31.8, against 28.6 and 25.7

• Codeforces — a 3,471 rating, ahead of DeepSeek V4 Pro on 3,348 and DeepSeek V4 Flash on 3,289

• MathArena Apex — 65.6, level with Kimi K3 and ahead of DeepSeek V4 Pro on 65.3

And on the harder agentic suites it does not:

• Terminal-Bench 3.0 — 30.0, well behind Opus-5.0 on 43.3 and GPT-5.6 Sol on 34.4, though far ahead of DeepSeek V4 Pro on 11.8

• Terminal-Bench 4.0 — 31.2, against 51.8 and 39.9, and again ahead of DeepSeek V4 Pro on 12.4

• ProgramBench — 20.3, against 37.0 for Opus-5.0

• NL2Repo-Bench — 64.0, against 75.3 for Opus-5.0

• HLE — 36.8, against 56.3 and 44.5

• ExploitGym — 15.3, against 33.7 and 22.1

The shape of that list is more informative than any single row. V4.1 Flash clears the frontier on benchmarks that reward sustained tool use inside a harness, and loses on the ones that reward depth of reasoning — the pattern you would expect from a model engineered around throughput and context economics rather than around raw reasoning ceiling. The internal comparison is the striking one: it beats DeepSeek V4 Pro on essentially every row, including the rows where both lose to Opus-5.0. DeepSeek is not claiming its cheapest model is the best model on the market. It is claiming its cheapest model is the best model DeepSeek makes, which is a claim its own routing table backs up.

What it costs, and what the Pro comparison actually looks like

September 10's rate card is now simply the V4.1 Flash card, published on DeepSeek's Models & Pricing page with a peak and off-peak split:

• Input, cache hit — $0.003 per 1M tokens off-peak, $0.006 at peak

• Input, cache miss — $0.15 per 1M tokens off-peak, $0.30 at peak

• Output — $0.60 per 1M tokens off-peak, $1.20 at peak

• Peak windows — 01:00–04:00 and 06:00–10:00 UTC, Monday to Friday; every other hour bills at half the peak rate

• In renminbi — ¥0.02, ¥1 and ¥4 off-peak, doubling to ¥0.04, ¥2 and ¥8 at peak

Compare that with the model it is displacing. DeepSeek V4 Pro bills $0.022 per 1M cache-hit input, $0.66 cache-miss input and $1.98 output off-peak — roughly 4.4× on cache-miss input and 3.3× on output. Those are the numbers the September 14 rerouting would have applied to every deepseek-v4-pro call, which is why the plan was a price story as much as a capability story, and they are still the reason the comparison matters: DeepSeek withdrew the reroute, not the rate card. Artificial Analysis reaches the same arithmetic from its own listings — $0.30 and $1.20 per 1M for V4.1 Flash against $1.32 and $3.96 for DeepSeek V4 Pro 0813, the same 4.4× and 3.3×, and a blended $0.18 per 1M on the site's 7:2:1 cache-hit, input and output mix. The card also undercuts DeepSeek V4 Flash 0731, the model it retires, which the same site lists at $0.44 and $1.32.

Per-token price is not per-task cost, and the beta is the evidence for that. First-day testers reported five-minute sessions draining their balance faster on the new model than the same wall-clock time on DeepSeek V4 Flash, because the model is built to emit tokens quickly and the bill scales with tokens, not with minutes. A card that is a quarter of Pro's price is a bargain if a task finishes in comparable tokens; it is a wash if the model thinks longer to get there.

Where an outside number does exist on that question, it points both ways. Artificial Analysis puts DeepSeek V4.1 Flash at $0.27 per Intelligence Index task on its own evaluation set — a real per-task figure, produced outside DeepSeek, and a low one. But the same run generated 250M output tokens against a median of 140M for comparable models, and the site's summary calls the model very verbose in the same breath as calling it fast. Verbosity is free inside a benchmark harness and expensive in production, which is precisely the mechanism the beta testers were describing when they reported balances draining faster in wall-clock terms. The honest state of the per-task question is that one independent evaluator has now measured both halves of it, on its own evaluation set, and the answer still depends on what you are running. The composite cannot show where the extra output goes, and the beta testers never said either. The first hands-on reports do, and they are in the speed section below: the model is verbose because it is checking. The October 17 update is the first time DeepSeek has claimed to move that number: the changelog says the new checkpoint “reduces task runtime and output length,” and the post a few hours later says the same thing in fewer words — “faster task completion, and shorter outputs.” That is DeepSeek addressing, on its own authority, the exact quantity the outside measurement complained about, with no figure attached to either statement. The first outside look at it, on October 18, found the aggregate volume down — 210 million output tokens across the index against 250 million for September — and the per-task figure flat, at 89,495 tokens against 88,574.

What a month costs: an $80 allowance, then a free tier

The card above answers what a token costs. A different figure has moved twice, and both times it came from OpenCode — the coding agent whose Go subscription prices access to this model as a monthly usage allowance rather than as metered tokens — speaking about its own subscription rather than about the model. On September 25 the platform's account posted: “Operation Cheepseek Phase 2: $60 of usage for DeepSeek v4.1 Flash is now permanent.” On October 12 it posted the sequel in the same format — “Operation Cheepseek Phase 3: $80 of usage for DeepSeek V4.1 Flash” — and its pricing page read $80 for this model where it had read $60 in late September. That reading was taken a second time on October 13, against the same page, and returned the same row: $80 on the $10-a-month Go tier, $160 on Go Plus. The figure is therefore not one post's claim about itself; it is one platform's published price for carrying this model, and it was still there a day later. Read together, the two posts say what “permanent” turned out to mean: no lapse date — and a higher number three weeks later. What that change is not is a new way to reach the model — that arrives three days later, in the paragraph below. DeepSeek V4.1 Flash has answered on DeepSeek's own API since September 10 and OrcaRouter has carried it at DeepSeek's own rates since release, so the weights, the architecture and every benchmark row in this piece are untouched by a subscription repricing; what October changed is who is willing to carry the model and on what terms.

The free entry is a different kind of change from either of those, and the only one of the three that changes what a reader can do this week. On October 15 OpenCode added a separate entry for this model — DeepSeek V4.1 Flash Free, model id deepseek-v4.1-flash-free — served at no charge. The platform's public model list returns it beside the metered id, its Console documentation carries a free-models entry describing it as free for a limited time and its provider as following a zero-retention policy that does not train on the data, and its published price table puts input, output and cached reads at Free. What it is not is the full product. The free entry's catalogued limits — added to models.dev, the catalogue OpenCode's own model list is drawn from, on October 15 — name the metered entry as the base model and cap the window at 200,000 tokens with a 32,000-token output ceiling, against the 1M context and 384K maximum output the metered deepseek-v4.1-flash entry carries. That is the same weights behind narrower serving terms rather than a smaller or a distilled model, and the output cap is the clause that bites first on agentic work, where a single file edit can run past it. The platform attaches no end date to the arrangement and publishes no rate card for it, because there is no rate. None of this came from DeepSeek: it is one platform's commercial decision about a model it does not own, stated on its own model list, its own documentation and its own price table, and it is the only source for all of it — we found no independent measurement of how the free endpoint behaves under load, and “limited time” is the platform's phrase rather than a schedule. Read it as the cheapest way to put a 200,000-token window in front of this model today, and not as a change to what the model is.

The mechanics come from that pricing page, read on October 12 and re-read on October 13. Go is a $10-per-month subscription, and its table pairs every model on it with an estimated request count per five hours and a monthly usage limit, in separate columns for the two tiers. DeepSeek V4.1 Flash carries the largest allowance on the page: $80 a month and 34,670 estimated requests per five hours on Go, doubling to $160 and 69,330 on Go Plus. The rows bill the model at DeepSeek's own card — $0.15 per 1M input tokens, $0.60 output and $0.003 for a cached read at off-peak, doubling to $0.30, $1.20 and $0.006 inside the weekday peak windows — and those are the vendor's figures, unchanged since the September reading this section already carried. Two things the page showed then are not on it today, and both are worth flagging because the earlier reading relied on them: the three-bucket draw-down rule — 20% over any five hours, 50% across a week and 100% across a month — no longer appears, and the documentation URL the request estimates were originally read from, opencode.ai/docs/go, returned 404 when we checked. The request counts above are the platform's arithmetic on a call shape it does not publish, not ours.

The change is checkable against the page, and so is the fact that there has now been more than one. In late September the same rows read $60 with no expiry attached, after a promotional $15 allowance was multiplied four times to $60 and carried September 20 as the date the multiplier would lapse; the request estimates were published in two columns, 6,500 / 16,250 / 32,500 standard against 26,000 / 65,000 / 130,000 with the multiplier applied. The rows read $80 on both readings, and the published estimates for this model are 34,670 per five hours and 69,330 a month — a higher dollar allowance sitting beside a lower monthly request count than September's expanded set, which cannot both describe the same assumed call shape. The page states no token mix and offers no explanation, so the difference is a fact about the two readings rather than something we can resolve from outside. The rates themselves were never a discount on DeepSeek's card — per-token pricing has been the vendor's throughout, and it still is. What an allowance does not do is say anything about quality: it is one platform's judgment that it can carry this model's traffic at those rates without a deadline, which is evidence about the serving ecosystem rather than about the model.

The distinction matters when you are choosing, because a flat ceiling and a pass-through meter are different products. DeepSeek V4.1 Flash is on OrcaRouter at DeepSeek's own rate with 0% markup — $0.15 per 1M input and $0.60 per 1M output off-peak, the same numbers the card above lists, with nothing bundled around them: no subscription to buy and no monthly allowance to exhaust. An $80 ceiling on a fixed monthly price is the right shape for one developer running an agent all day, where the question is what the month costs — and a ceiling already raised once, by a third, is also a reminder that the figure is a commercial decision rather than a property of the model. A free tier with a 200,000-token window is the right shape for trying the model this week and the wrong shape for the codebases that need the full window, which is the one thing the two tiers of the same model do not share. A vendor rate passed through unchanged is the right shape for a service, where the question is what each call costs and whether the provider's next price move reaches you the day it happens. Both answer what this model costs; they answer it for different spenders.

Speed: the beta's numbers, the maker's claim, and the engine's own before-and-after

When the beta opened, throughput was the headline. Developers reported roughly 420 output tokens per second in long generations with peaks above 500, and one widely shared run produced more than 71,000 tokens in under three minutes. Those remain community measurements taken under uncontrolled conditions and they should still be read that way — but the mechanism behind them is now documented rather than guessed at. An 890-byte-per-token KV cache and a decode path activating 16B parameters is a design built for throughput, so the architecture is at least the right shape to produce numbers like those. How large they really are is the next paragraph's problem, and the answer is smaller.

DeepSeek's own claim, in the changelog, is that V4.1 Flash “has comprehensively surpassed V4 Pro in performance, cost, speed, and total time.” The word doing the work there is total time: it is the vendor framing speed as task completion rather than tokens per second, which is the metric that survives contact with a real agent loop that writes a file, reads the error and tries again. Artificial Analysis now puts a measured figure on the older claim: 185 output tokens per second for DeepSeek V4.1 Flash, against 175 for DeepSeek V4 Flash 0731. That is a real third-party number and it is roughly half the 420 tokens per second developers reported during the beta, which is why the beta figures should stay where they belong — in the uncontrolled-conditions column.

On October 7 the vLLM project published its accounting of the three weeks since release, and it is the first measured speed figure in this piece that is neither a token counter nor a vendor slogan. Writing as Inferact and the vLLM Team, the project reports that DeepSeek V4.1 Flash on its current build runs 1.9× faster than its own day-0 implementation at low concurrency and delivers 5.3× the throughput under a 150 TPS constraint — the figure its summary carries, against “about 5×” in the body of the same post. Both are measured on the SemiAnalysis AgentX agentic serving benchmark, with TP4 and FlashInfer attention behind the low-latency number and DEP2 with data-parallel attention behind the throughput one, on NVIDIA GB200 and GB300 hardware. Three things about that result are worth keeping straight. It compares vLLM against vLLM: the baseline is the project's own day-0 recipe, not another engine and not another model, so the number says how much the serving stack improved rather than how this model compares with anything else. It is the runtime's own account of its own work, and no third party has reproduced it. And the largest single gain comes from the runtime rather than the weights — SWA bounded replay, which reruns only the last 128 tokens of a sliding window instead of replaying that window across layers, now ships on by default for this model behind a single flag. The project reports roughly 30% off time to first token from replay plus CUDA-graph capture, a 30–40% cut in prefill computation from the decoder-side trim, and nearly 70% off TTFT at around 100K throughput once three optimisations stack. It also reports where replay hurts: without CUDA graphs it is slower than the baseline on short prompts, up to 12% worse at 1K tokens, because launch overhead outweighs the work saved. Accuracy was checked on GSM8K and GPQA with no meaningful difference reported, gaps within about 1.5 standard errors — the figure to hold against the report's own statement that bounded replay is approximate rather than exact. The project adds that the model needed no KV-cache offloading anywhere in the benchmark and expects offloading to start paying only at higher concurrency with prefill and decode split across machines. This is a different measurement from the kernel board below, which scores kernels the model writes; vLLM's figures are about what the model costs to serve once an engine has implemented its architecture, and the engine here is the one reporting. The project posted again on October 17, the day DeepSeek swapped the checkpoint, and the number it led with was a different kind of figure: 1.3B tokens per dollar of total cost of ownership on SemiAnalysis AgentX, at 830,000 tokens per second per GPU counting cached, input and output tokens together, while holding 100 output tokens per second for every user. That is a cost-of-serving result rather than a speed delta, and the serving-cost section below reads it in full. Three things about it bear on this paragraph: it is the same project, the same model and the same benchmark three weeks on from the October 7 accounting; the project frames that accounting as chapter one, at 5x the agentic throughput of day zero, with a next chapter still to come, and no second DeepSeek post has appeared on its blog since; and a cost curve is still the runtime's side of the ledger, not an outside verdict on the model. That distinction is also why this number matters to someone who will never run a node. None of the work is work a caller does: a serving stack that gets 1.9× faster at low concurrency makes the requests it handles faster, and reaching this model through an API is how most teams will benefit from that without owning the hardware. DeepSeek V4.1 Flash is on OrcaRouter at DeepSeek's own rate with 0% markup, on the same OpenAI-compatible key as the rest of the line, with a proven model behind it as automatic failover — the model and the pricing move at the provider's pace, and the choice of engine stays on the provider's side of the line.

What it costs to serve: the first independent hardware numbers

Everything above measures the model. On October 14 Artificial Analysis added DeepSeek V4.1 Flash to AA-AgentPerf, the benchmark it runs against accelerator systems rather than against models, and the result is the first public answer to a question a rate card cannot settle: how much of this model one megawatt of datacenter power carries. AA-AgentPerf replays recorded coding-agent sessions — multi-turn reasoning, tool calls, contexts that grow past 100K tokens, prompt cache hits included — against a live serving stack and finds the largest number of concurrent agents a system holds while each one still meets a per-agent speed target. For this model the headline is NVIDIA's rack-scale part. At 100 output tokens per second per user, GB300 NVL72 leads the field at roughly 261 million tokens per second per megawatt, ahead of B300 at about 220 million, B200 at 193 million, GB200 at 178 million and AMD's MI355X at 128 million. Those are Artificial Analysis's figures, read off its datacenter inference page today, and they are its measurements of specific hardware and serving configurations rather than a vendor's. Two details are worth carrying. The per-megawatt numbers are computed from accelerator power measured during the run — GPU die plus HBM — rather than from rated TDP. And each point on the chart names the engine, version and numeric format behind it, so the number is a claim about a serving stack and not only about the weights.

The reason this model's chart looks unlike the others is its size. DeepSeek V4.1 Flash fits on as few as two accelerators, which is why a rack-scale system gets less of an advantage here than it does on a larger model: Artificial Analysis reports B300 staying within about 20% of GB300 NVL72 across the curve and leading it at both ends — the most throughput per megawatt when per-user speed is allowed to fall, and the fastest single agent when it is not. At batch size one, every Blackwell part and the MI355X land between roughly 600 and 670 tokens per second for a single user, against 372 to 392 on H100 and H200. Set against DeepSeek V4 Pro 0813 on the same axis, the smaller model returns about 1.3× the throughput per megawatt on GB300 and about 6.2× on B200 at the 100 tok/s mark — the efficiency claim the architecture section makes from the KV-cache side, arriving from a third party that measured a system rather than a specification. The configurations behind those numbers show the design's central trick in production rather than only on paper: on both the B300 and the MI355X two-accelerator runs, the 196B Engram table is served out of pinned host memory through vLLM's CPU-offload path instead of sitting on the accelerator — the mechanism the release notes described, now visible in the setup behind a published measurement. A second cost figure, in a different currency, arrives from the benchmark the October 7 vLLM post was measured on. On October 17 the vLLM project published a chart putting DeepSeek V4.1 Flash at 1.3B tokens per dollar of total cost of ownership on SemiAnalysis AgentX, with separate curves for GB300 NVL72 under Dynamo, GB200 NVL72, B200, H100 and MI300X. The cost tier behind it is labelled owning at large-hyperscaler volume, and the chip-hour assumptions underneath run from $0.95 for an MI300X and $1.17 for an H100 to $1.73 for a B200 and $2.31 for a GB300, drawn from SemiAnalysis's own July 2026 pricing survey. Two limits belong with it. It is the vLLM project reporting SemiAnalysis's cost model, and neither party has had it replicated. And the chart is dated October 16, the day before DeepSeek replaced the weights behind the model name, so it too describes the September checkpoint. That makes three currencies in this piece for one model: tokens per second per user, tokens per second per megawatt, and tokens per dollar. The last is the one a buyer without a datacenter can act on, because it is the quantity a provider's cost improvement eventually reaches them as. It remains a serving measurement and not a quality one: nothing here says how good the model is, and one leaderboard's hardware results are not a replication of any benchmark row above. What it does establish is that the cost side of this model's rate card now has outside evidence under it. A model a provider can serve at several times the throughput per megawatt is a model a provider can afford to keep cheap, and DeepSeek V4.1 Flash is on OrcaRouter at DeepSeek's own list price with 0% markup, which is the shape that passes a provider's cost improvement through instead of holding it.

What the engine costs on two vendors' silicon

Until this week the throughput question about this model was answered only by other people's measurements — a runtime accounting for its own work, a benchmark site measuring a system, developers counting tokens in a beta. DeepSeek opened DeepInfer, the framework it says powers this model's production service, under Apache-2.0 this week — the repository appeared on October 16 and the first commit landed on October 20 — and shipped with it a decode Pareto plot for the 1017 checkpoint measured on 64 SM100 accelerators inside one scale-up domain. The configuration printed on the plot is the part that matters, because it is the configuration the comparison below turns on: expert parallelism of 64 over data parallelism of 64, the “384+64 experts” the plot prints, a 131,072-token context, DSpark draft length fixed at three tokens, and a per-token acceptance rate of 75%. The curve tops out just under 30,000 output tokens per second per accelerator at its least interactive end, falls through the mid-20,000s as per-user speed rises past 100 tokens per second, and is down to a few thousand by the chart's right edge. It is DeepSeek measuring its own engine on its own model, so it is not an independent number — but it is the first decode curve for this architecture published by the lab that built it, and the sweep script that produced it is in the same repository.

The write-up published beside the code supplies the operating point, and it is the reason the numbers below are quoted at 230 output tokens per second rather than at some abstract maximum. DeepSeek's own production figures put decode at 14K tokens per second per accelerator while the service holds 230 output tokens per second per user — 300 in coding workloads — against a 96% input cache hit rate, an average input of 77K tokens, a 400 ms mean and one-second p99 time to first token, and prefill provisioned at close to a 1:1 ratio with decode, across a single cluster it says serves 155 trillion tokens a day. The revenue line beside those figures, $38 per accelerator-hour at off-peak pricing, is the first cost number DeepSeek has attached to serving this model publicly. None of it is audited, all of it is the vendor describing its own service, and it is still the most concrete picture of what this architecture costs to run that exists.

The other half of the comparison comes from Huawei's silicon, and it is the weaker-sourced half. A benchmark sheet dated September 30 and headed “Ascend 950DT DeepSeek-V4.1-Flash Benchmark” reports the model deployed across 32 chips at FP8–FP4 mixed precision, with data-parallel attention and expert-parallel mixture-of-experts, on a 128K-token sequence, using DSpark speculative decoding with a forced expert-parallel load-balancer configuration and an average accepted length of 4.1 tokens. It carries three points. Its latency column is time per output token, so the reciprocal of each entry is that row's per-user speed, and that is what lets the sheet be laid against the curve:

• 1,536 global batch, 9.41 ms per output token — about 106 output tokens per second per user — 5,102 tokens per second per chip.

• 384 global batch, 4.40 ms per output token — about 227 output tokens per second per user — 2,727 tokens per second per chip.

• 2,560 global batch, 13.79 ms per output token — about 73 output tokens per second per user — 5,800 tokens per second per chip, the highest figure in the sheet and the one its headline uses.

Laid against the NVIDIA curve, the middle two rows are the ones that bite, because they sit at the speeds a service actually runs at. The thread that surfaced the sheet reads the comparison as 25,500 tokens per second per accelerator against 5,102 at 100 output tokens per second per user, and 20,000 against 2,727 at 230 — a gap of five times at the first operating point and 7.4× at the second. Reading the same published curve directly moves those NVIDIA figures around: a pixel pass over the image lands nearer 28,000 at the 100-token mark and nearer 17,000 at 230, on either side of the thread's numbers; the band they give is about five and a half times at the first operating point and about six at the second, which narrows the thread's range without changing its shape. That is what a benchmark read off a chart is worth, and it does not change the direction of the result. It is also worth noting that the sheet's 5,800 headline is its least interactive row — the point where NVIDIA's curve is closest to its own peak, and where the ratio is back to about five.

I could not find that sheet on DeepSeek's or Huawei's own pages; it reached this piece as an image attached to a thread on X, and the three Ascend figures should be read as an unpublished vendor benchmark until somebody posts the run behind them. What is checkable is the asymmetry in the configurations, and that comes from DeepSeek's own documentation. DeepInfer's deployment notes recommend prefill at expert parallelism of 2 to 8 and decode at 64 to 128, on “ordinary 8-GPU machines for prefill, ordinary 64–128-GPU supernodes for decode.” On NVIDIA that is a single NVLink domain, which is what the plot above was measured inside. On Ascend, DeepSeek's own communication library says plainly what is not finished: “Larger EP sizes and combine remain under optimization,” with combine carrying extra local reduction overhead and HBM contention against the URMA path, and Huawei firmware work still to come — a caveat public in DeepEP-Ascend since its first release on September 29. That is the fair way to read the gap: the NVIDIA number comes from the shape DeepInfer was tuned for, and the Ascend number from a stack whose own author says the wide-EP path is still being worked. Some of five to seven times is the chip, some of it is the interconnect and the software under it, and nobody has separated the two.

What the gap is worth in money depends on prices nobody has published, and the thread runs the arithmetic anyway: at roughly $139,000 per Blackwell accelerator, extrapolated from grey-market rack pricing, against a rumored $37,000 for a 950DT, NVIDIA has to deliver about 3.8× the throughput per chip to match Ascend on acquisition cost alone; the thread puts the crossover near 6,800 tokens per second per chip. The published Ascend points sit below that line; the thread's forecast that the wide-EP path lifts them to 8,000–10,000 sits above it, and that is a forecast rather than a measurement. Every input is soft — a grey-market price, a rumored one, and figures read off a curve — and none of it accounts for networking, power, cooling, maintenance, or the value of being able to buy the hardware at all.

For anyone who will never rack a node, the useful part is not the scoreboard. It is that the cheapest model in DeepSeek's line is now documented as cheap to serve on two vendors' silicon, with the vendor's own engine published and the numbers behind it downloadable — which is the kind of evidence a price rests on. It changes no rate card: DeepSeek V4.1 Flash is on OrcaRouter at the provider's own list price, $0.15 per 1M input tokens and $0.60 per 1M output at off-peak rates, passed through with 0% markup, so when a provider's serving cost falls the saving arrives as a price that does not have to move rather than as a resale margin. A serving cost argued over on two vendors' hardware is a price with more room under it than one nobody has measured at all.

Kernel engineering: the first scoreboard that is not DeepSeek's

The benchmark rows above are DeepSeek's own harness numbers, and the outside scores that now exist measure general reasoning and cyber exploitation rather than low-level programming. The first third-party look at the model's kernel engineering also exists, and it arrived in a form DeepSeek did not commission: a community-run agentic benchmark that asks models to write real CUDA kernels and scores the results against a roofline — the theoretical ceiling of the hardware. The leaderboard is kernelbench.com, run on an RTX PRO 6000, and it is independent of both vendors. Its audit methodology is community-reported rather than peer-reviewed, so read its percentages as a directional third-party signal, not a certified measurement; it is also the first scoreboard in this story where DeepSeek's numbers sit beside a direct competitor's.

The headline row is the one the architecture is built around. DeepSeek V4.1 Flash's own sparse attention — the CSA2 stack that produces the 890-byte-per-token cache — was written as a CUDA kernel by the model and reached 50.19% of the dense-equivalent roofline, fourth on the board behind Claude Fable 5.1 at 106.27%, Claude Opus 5 at 103.67% and Claude Fable 5 at 72.66%. The first thing to notice is that the maker's own architecture is the kernel it is best at: a model trained on a sparse-attention design writes the sparse-attention kernel more efficiently than anything else on the board below the top three. The second thing is the comparison the tipster flagged. GLM-5.3 Flash's attempt at the same kernel reaches 4.45% of roofline — an order of magnitude below V4.1 Flash on the same row of the same board. That gap, not any benchmark DeepSeek published, is what 'massive improvement on kernel engineering' means.

The comparison does not stop at the sparse-attention row, and the fuller picture matters because the tweet's headline names GLM-5.3 Flash while the quoted write-up it cites actually references a different, larger GLM-5.2 on its own fused-MoE row — a naming mismatch that is worth being careful about. On the rows where both flash-tier models actually completed a run, V4.1 Flash wins every one: Kimi-Linear Decode at 17.10× versus 13.64×, MegaQwen Decode at 5.39% of roofline versus 3.92%, TopK Bitonic at 4.25% versus 7.17% for GLM-5.3 Flash, Sonic MoE at 10.81% (the best score any model on the board posted for that kernel) versus 10.21%, and KDA CUTLASS at 3.74% versus 2.26%. On two further kernels GLM-5.3 Flash has no completed run at all — fused MoE and the Grid + MinGRU simulation kernel, where V4.1 Flash posts 28.56% of roofline. (The one row GLM-5.3 Flash beats V4.1 Flash on is TopK Bitonic, 7.17% to 4.25%, which is also the row where neither model approaches the board's leader.) The rough shape is the same as the headline: on low-level GPU work, V4.1 Flash is not merely ahead of the smaller Z.ai model — it is in a different league, and on the two hardest kernels the smaller model does not finish at all.

What the board does not do is tell you how much of that gap is the model and how much is the architecture it is asked to write. DeepSeek V4.1 Flash is a 552B-parameter model whose own attention is a sparse-attention design; GLM-5.3 Flash is a smaller model whose training never revolved around the same CSA2 stack. A model asked to write a kernel for an architecture that resembles its own training distribution has a built-in advantage, which is why the fairest reading of the board is directional rather than a head-to-head verdict: kernel engineering is now a measured capability of this model, it is genuinely strong, and the specific comparison the tipster drew holds on the shared rows. The board also answers a question the spec sheet could not: whether the 890-byte cache is realisable in practice. A model that writes its own sparse-attention kernel to half the roofline is a model whose core design is at least implementable on real hardware by the same class of engineer who would have to serve it.

The honest place this lands is next to everything else in this piece: one more third-party measurement that DeepSeek did not produce, this time of a capability — GPU kernel writing — that no vendor benchmark row covered. It is a single community board on a single GPU generation, run once, and its audit pass is not peer-reviewed, so it is evidence about direction rather than a certified score. But it is the first outside number that shows what the new architecture is for: a cheap Flash-tier model that, asked to do the low-level systems work DeepSeek itself spends its engineering on, reaches roughly half of what the hardware permits while its direct flash-tier competitor reaches less than a twentieth.

Fast fixes, slow confirmations: the first hands-on reports

Throughput is the half of the speed story a token counter cannot see. The hands-on reports that have accumulated since release measure the other half — how the model behaves on the way to an answer, and what that behaviour costs — and they do not agree on whether what they found is a feature. Three independent accounts describe the same pattern. None of them is a controlled evaluation; the figures below are individual practitioners running their own tasks, and they should be read as usage reports rather than measurements.

The clearest account of the behaviour comes from MindStudio, which put DeepSeek V4.1 Flash on a from-scratch build of an interactive 3D viewer. Its reasoning trace, in the reviewer's words, “showed it verifying its own math rather than just emitting code.” The model caught an orbit-control damping bug mid-build, reasoned the correction out from first principles, and then “rechecked the fix in a headless browser before declaring the task done.” On a second task — a Docker-based dashboard — it found a single flipped comparison operator and confirmed the repair by polling the live endpoint eight times as the numbers updated. That is what the beta's testers were describing when they called the model an overthinker, and there is nothing wrong with any single step of it: the error was found, fixed and verified. It is also exactly the complaint. The bug had already been dealt with, another DeepSeek session had already confirmed the fix inside a minute, and the model went on checking anyway. MindStudio reads the habit as a strength and says so; its only criticism in that test was a physics problem that looped until it was stopped by hand on the first attempt, then solved correctly on the retry.

The reading from the other direction is about the clock. A community compilation of V4.1 Flash tests describes a physics problem — a water cup cut at an oblique angle — where the model spent twelve minutes and roughly 130,000 tokens on the way to a correct answer, running three rounds of self-verification it had not been asked for before it converged. The same write-up documents the failure mode at the far end of that habit: the chain of thought occasionally falls into a “let me write” repeat loop that spins through tokens at roughly 200 per second without progressing, and its advice is client-side rather than model-side — set a max_tokens ceiling and a request timeout and let them truncate the loop. It also records the same class of problem being dispatched in eighteen seconds by a run with the reasoning effort turned down to low, which is a reminder that most of this is a dial rather than a defect.

The sharpest evidence that verification volume is not the same thing as correctness comes from a Tencent Cloud Labs review that paired DeepSeek V4.1 Flash as the implementer with GPT-6 Astra as the reviewer on a paper reproduction. Three rounds ran, and Astra never overturned the core algorithm. What the reviewer kept correcting, round after round, was the scaffolding V4.1 Flash had built for itself — its experiment setup, its statistical construction, and the interpretation it drew from its own results. The test count grew from 82 to 97 to 110, and all of them passed every time. Against a brute-force baseline, the configuration the model chose matched the optimum in 8.89% of cases under the paper's own parameters, 11.04% with randomised confidence and 10.30% under a randomised configuration. Astra's most pointed finding was about a test that claimed to check integer boundaries: it executed 153 extension checks and zero integer-boundary branches. A model can pass the suite it wrote and still not have answered the question, and that review is a worked case of the gap rather than an assertion that one exists. The scope is narrow and the authors say so — a single speculative-length selector, simulated confidence values, no end-to-end run — but the shape is the one the other reports describe.

Set beside Artificial Analysis's numbers, this stops looking like anecdote. The first independent evaluation of the model measured it as very fast and very verbose in the same breath: 185 output tokens per second, and 250 million output tokens generated across its evaluation set against a median of 140 million for comparable models. A composite score cannot say where the extra output goes. The hands-on reports can. The tokens are not padding — they are the model checking. The same volume shows up from an unrelated direction in a bug report on a third-party terminal client, where reasoning content on a deepseek-flash route was appended to the visible answer instead of being separated into a thinking block, producing single text blocks of up to 73,003 characters of internal monologue, with nothing captured to replay on later turns. That bug belongs to the client and not to DeepSeek, and it is not evidence about quality — but it is a fair illustration of how much thinking this model emits when a harness fails to separate it.

None of this overturns the price arithmetic above; it explains it. A model that verifies itself is worth its tokens on agentic work, where a wrong fix costs more than the tokens spent proving it right, and is a poor fit for a long loop of trivial edits where the confirmation is most of the run. Two things make the difference manageable. The reasoning effort dial is a continuous integer from 1 to 100 rather than three fixed tiers, so the same model can be turned down for cheap work and up for hard work — the eighteen-second result above came from doing exactly that. And the cheap safety net belongs on the client: a max_tokens ceiling and a request timeout turn a repeat loop from a bill into a truncated response. Both are the kind of setting worth fixing before a production path points at this model, and neither is something the model will do for itself.

Refusals: the checkpoint declines, and the decline is measurable

On October 20 the thing drawing attention to DeepSeek-V4.1-Flash-1017 was not a benchmark row but a refusal. The DeepSeek tracker this piece has already quoted posted a screenshot from an agent session running the 1017 checkpoint with dsh-purge applied, and reported that the model declined anyway: the run, in the poster's words, “refused the persona,” with the model reasoning that the request was “a prompt injection attempt” and that it “should not adopt the persona.” The post's reading was that the checkpoint “is *not* entirely naive about jailbreaks” and that DeepSeek is “starting to think about safety.” dsh-purge is not a prompt trick pasted into a user message. It is a public DeepSeek Harness plugin — 9,897 stars on GitHub and version 1.1.71 as of October 20 — built to strip the harness's own prompt rewriting and injected suffixes, and its English README draws exactly the distinction this test turns on: the harness “rewrites prompts, approval gates, sandbox policy, and session migration at runtime,” so asking only “will the model answer” treats a host-layer block as a model refusal, and the plugin exists to split those two layers on your own install. In this session the separation came out on the model's side. The counters in the same screenshot — 156 steps, 33.7 million tokens, 232 tokens per second — describe a full agent run rather than a one-shot prompt, and the agent's own summary says the plugin was mechanically fine and “that specific model declined it.”

That is one person's screenshot of one session, and it should be carried as exactly that. The prompt is not shown, the verdict is the agent's own summary rather than a graded response, and the account is a DeepSeek watcher rather than an evaluation lab, so nothing in the post can be reproduced from the post. What makes it worth taking seriously is that both halves of it can be checked against sources independent of the person who posted it: the plugin, which is public and documents its own mechanism, and the checkpoint's refusal behaviour, which somebody else has now counted.

The count is in the paperwork of a derivative. A community abliterated build of the 1017 weights, published on Hugging Face on October 17, carries the measurement that made the build necessary. On 100 held-out harmful requests, decoded greedily for 384 tokens each, the untouched checkpoint refused 97 in chat mode and 98 in think mode; after a rank-2 refusal subspace was projected out of the 40 main layers, the same 100 prompts drew 4 and 9 refusals. Those are third-party figures about DeepSeek's weights, produced without access to DeepSeek's training pipeline, and they are also one prompt set, one grader and one quantisation of the model — a Q8_0 conversion rather than the FP8 DeepSeek ships — so the honest reading is “almost always,” not “97.0%.” On that evidence the poster's description holds: the checkpoint refuses, reliably, in both of its modes.

What the figure does not support is the idea that this is a new posture. The September checkpoint was already there. The team behind an uncensored September build measured the untouched model on HarmBench's full 320-prompt set and reported attack success of 42.8% with reasoning switched off and 1.6% at maximum effort — which is to say the model this one replaces refused roughly 98% of that class of request once it was allowed to think. The two measurements come from different prompt sets, different graders and different quantisations, so they cannot be subtracted from one another; what they agree on is the shape. High-effort refusal was already the September model's behaviour, and the 1017 checkpoint sits in the same range. The narrower claim is the one the October 20 session actually tests, and it is the one worth keeping: the refusal survived a plugin built specifically to remove the harness-side constraints, and it survived as the model's judgement about the prompt rather than as a host-layer block.

None of this is documented by the vendor. DeepSeek's September model card has an evaluation section and it is benchmarks only — no refusal rate, no red-team result, no safety evaluation — and the 1017 card carries no evaluation section at all, having dropped that folder along with the technical report. Refusal behaviour for this model is therefore described entirely by the people building around it: derivative authors counting prompts, and a tracker reading a transcript. For anyone pointing an agent at the checkpoint, that is the operative gap. A refusal inside an agent loop is not a content-policy footnote; it is a failed tool call in the middle of a run, and it surfaces like any other per-call failure — which is why the mitigation is the one a timeout gets. On OrcaRouter that is a routing decision rather than a code change: the 1017 checkpoint and the DeepSeek models it would fall back to sit behind one endpoint, so a call that comes back refused can be retried against a second model instead of ending the run. The refusal itself belongs to the model, and nothing on the routing layer changes it.

The derivative count is the last independent piece, and it points the same way. A Hugging Face search for the checkpoint's name returned 121 public repositories on October 20, and 25 of them carry uncensored, abliterated or derisked in the name — builds whose whole purpose is to remove the behaviour the October 20 session ran into, the first of them posted the same day the weights going up. That is not evidence about whether the model is good, and it is not a recommendation; it is evidence that there is a working refusal mechanism in the weights to remove, because the people who strip these things do not bother when there is nothing to strip. It also sets the expectation for anyone self-hosting: the checkpoint you download is the one that refuses, and every uncensored variant on that list is a different model, not a setting.

The V4 Pro question, and the rungs above Flash

During the beta, DeepSeek's feedback form asked testers whether the intermediate version "can fully replace the online DeepSeek V4 Pro." That was a striking question to put to users, because it implied the flagship's future was open. The answer that arrived on September 9 and 10 was an operational one: from 12:00 Beijing time on September 14, deepseek-v4-pro would stop being served and its traffic would land on V4.1 Flash at Flash prices, with V4.1 Pro named as the eventual successor. Developers objected, and the objection was not that the replacement was bad — it was that a model string is a contract, and swapping the weights behind a production ID breaks prompt-tuned pipelines and agent loops built against the old ones. Within two days DeepSeek withdrew the plan. Its own changelog now says it has “decided to continue providing API services for DeepSeek V4 Pro after September 14, 2026, with the billing method remaining unchanged,” and that it will give further notice if that changes. The reversal is vendor-stated rather than reported, and it is checkable on the Models & Pricing page, which still lists deepseek-v4-pro beside deepseek-flash.

What the routing table does not explain is why. On September 9, teortaxesTex — one of the tipster accounts that flagged the beta — reported that DeepSeek had conceded its V4-Pro pre-training went wrong; in his words, the company “dun goofed” with it. That remains a single-source claim from an insider-leaning account, and DeepSeek has conceded nothing publicly: the changelog frames the phase-out as a consequence of the new model being better, not of the old one being broken. What can be checked from outside is the shape of the August 13 V4 Pro general-availability launch. The announcement was pulled within about a day. The Hugging Face repository briefly carried a Flash-tier configuration under the Pro name before the weights were corrected. And independent scoring of what was being served under that name landed barely above the much smaller DeepSeek V4 Flash, against official charts showing near-flagship results — on the current artificial-analysis index the two sit a single point apart, 36 against 35. Independent write-ups have blamed different causes — reasoning behaviour overfit to DeepSeek's own evaluation harness, a deployment and weights mixup, or, as the leak claims, a pre-training that genuinely misfired. The rerouting does not settle which, and DeepSeek has since called it off; what survives is a vendor pricing its newest model at a quarter of the flagship's cache-miss rate and putting it ahead of that flagship on its own benchmarks, which companies do not usually do because everything went to plan.

Flash, Pro, Ultra: what DeepSeek has said, and what is only a guess

DeepSeek's own documentation is explicit that this is the bottom of something. The changelog calls DeepSeek V4.1 Flash “the smallest model in our new architecture family” and says the architecture “is designed for a higher capability ceiling, faster inference, higher throughput, and scaling to larger models.” The technical report closes the same loop in stronger language: the model “serves as a new starting point for our continued scaling efforts,” and the company says it “will pursue the joint scaling of model architecture, pre-training, and post-training to further explore the frontier of model intelligence.” Both sentences are first-party, both were published on September 10, and neither is a product announcement. They commit DeepSeek to building bigger models on this design; they do not name one, size one or date one.

Everything past that line is speculation. On September 25 the tracker @teortaxesTex — the same account whose September 9 post on the V4 Pro pre-training this piece already carries — read the pattern as a full three-tier line: “DeepSeek is pretty clear that they're not going to stop here… This sounds like they intend to make a whole lineup, Flash-Pro-Ultra. Maybe 522B-2T-8T?” The sizes are labelled a guess by the person offering them, and the hedge is doing real work: nothing in DeepSeek's changelog, model card, technical report, Hugging Face organisation, pricing page or model listing names an Ultra tier, and nothing above 552B. The guessed ladder is also shakier arithmetic than it looks. Its bottom rung, 522B, is not the 552B model that shipped — either the figure is a slip for a number DeepSeek has already published, or it points at a checkpoint nobody has seen, and there is no way from outside to tell which. Its top rung, 8T, is five times the 1.6T flagship whose repository DeepSeek opened in April, in a year when the company's most recent release was engineered to activate 8B parameters per token because inference cost, not parameter count, was the constraint it set out to solve.

The same account has separately floated a 3-trillion-parameter DeepSeek model as something the lab was working on but was unsure it could serve economically — a different claim about a different thing, and equally unconfirmed. Neither has to be reconciled with the other, because neither has a second source. What can be checked is the direction: a lab that calls its newest model the smallest in a family, and its architecture one that scales to larger models, is a lab planning to ship above this rung. What it will call the rungs, and how big they will be, is not in any document a reader can open today.

For anyone choosing a model rather than following a roadmap, that distinction is the whole of it. If the family does extend upward, the decision in front of most teams is still whether to move onto the rung that exists — and the cheapest way to hold that decision open is not to wait. DeepSeek V4.1 Flash is on OrcaRouter at DeepSeek's own rates with 0% markup, so if a Pro-tier successor arrives at a different price, the change lands in the rate card rather than in a contract. DeepSeek V4 Pro sits on the same key behind it, which makes a third tier arriving later a routing decision rather than a migration.

MIT weights change what you can do with it

DeepSeek V4.1 Flash ships under the MIT licence, and the weights went up in the deepseek-ai organisation on Hugging Face on September 10 — the same day as the API, not weeks later. The repository is deepseek-ai/DeepSeek-V4.1-Flash: 48 safetensors shards totalling about 510 GB, the technical report as a PDF beside them, and an inference folder holding a reference implementation plus a conversion script that splits the checkpoint across tensor-parallel ranks. That repository is the September checkpoint; the live one since October 17 is deepseek-ai/DeepSeek-V4.1-Flash-1017, which carries the same MIT licence, the same 48 shards and the same roughly 510 GB, but which replaces every shard and drops the report, the chat template and the evaluation folder.

It is worth being precise about what that download is, because it is not a full-precision release. The safetensors hold roughly 204B parameters in FP8 and 557B in INT8 against about 2B in BF16, and the config declares fp8 quantisation — the checkpoint you pull is already compressed, and that is how a 763B-parameter model fits into about 510 GB. The largest single block inside it is the Engram table: two FP8 tables holding about 189 GiB of the download, which every decode step reads only a few rows from.

For a model with a 552B backbone, the licence is the part that changes decisions. MIT is permissive with no revenue gate and no acceptable-use rider worth a legal review, and the activation profile — 8B per token on prefill, 16B on decode, with an 890-byte-per-token cache — is what makes serving it plausible outside a hyperscaler even though the parameter count reads large. That last figure is a property of the full cache stack rather than of the weights, though, so a self-hosted engine that implements the quantized format and not the rest of the design will land well above it.

A permissive licence is not an export clearance, and for six days in October the difference looked as though it might matter. On October 16 China's Ministry of Commerce and Ministry of Science and Technology published Announcement No. 48 of 2026, a draft revision of the catalogue of technologies prohibited or restricted from export that reaches AI model weights and source code for the first time. It proposes 40 additions across AI, biotech and solar, 23 of them AI-related, with public comment running to November 15. Two carve-outs in the draft do most of the work for a model like this one: technology already in the public domain through open-source release or academic publication is not to be controlled, and API, app, SaaS and lightweight on-device access for overseas users is not treated as an export of model technology. The thresholds reported across the trade press combine a parameter floor of two trillion, a place in the global top ten on performance and safety benchmarks, and training on core or important national data. A 552B model clears the first; whether the other two catch it is not something a reader can determine from outside, because the draft does not publish the definitions — which makes the public-domain carve-out, not the size test, the clause that matters for weights already on Hugging Face.

What changed on October 22 was not the text but the compliance record. YuyuantanTan reported that DeepSeek and MiniMax had completed the registration procedures and finished open-sourcing and overseas licensing. The report does not say which releases it counts as the open-sourcing, it names no model, checkpoint or date, and it announced no new weights; the open-source releases visible in that window are the DeepInfer engine and the deepseek-recipe toolkit covered above. The build-level version of the claim is narrower and later: on October 23 an X account with a long record of tracking DeepSeek posted that DeepSeek and MiniMax had “obtained permissions for open sourcing V4.1F-1017 and M3.1-Flash” respectively. That attribution is the poster's, neither company has published a statement confirming it, and no regulator has published a notice naming either company's registration. The checkpoint the post names had been on Hugging Face under MIT since October 17, six days earlier. Whatever permission was granted, it did not gate the download: the repository came first.

For a reader, the practical content is narrower than the headlines around it, and it runs in two directions. Nothing about the October 17 checkpoint, the MIT licence or the repository changed on October 22; the download, the shards and the hash differences described above are exactly as they were. What changed is the answer to whether a Chinese lab can keep publishing weights like these while the catalogue is still in consultation: the state-media account says yes for DeepSeek and MiniMax, under a draft that excludes already-public technology and leaves API access outside the export definition. The limit is in the tense. The exemption is for technology already in the public domain, which describes the September and October checkpoints and would not automatically describe a release made after the catalogue is finalised — and the interim registration duty said to have taken effect on October 16 has been reported rather than published in full. Anyone planning to download whatever DeepSeek ships next is planning against a rule that does not exist yet. Anyone calling V4.1 Flash today, or running the 1017 weights, is relying on a carve-out that the draft states and that neither account of the interim measure contradicts.

Serving support arrived the same day, and it sets the practical floor. vLLM published a day-0 recipe validated on NVIDIA and AMD hardware, and SGLang shipped day-0 inference and RL support in the same window through its Miles training stack. Both shipped as preview images rather than stable packages — the vLLM container carried a September 9 tag, a day ahead of the model's own GA. That side of the story moved on September 22, when vLLM released v0.30.0: the first stable vLLM version to carry this architecture, with DeepSeek V4.1 Flash listed under its new-model support, the model's own vLLM recipe now requiring 0.30.0 or later, and the launch-day image tag retired. The release notes are the project's own account of its work rather than a measured result, and should be read that way. They credit the version with holding the model's whole KV cache in MXFP8 through the FlashMLA V4.1 record on SM100, and with asynchronous prefetch for CPU-offloaded Engram lookups plus Engram data-parallel sharding — the two changes that matter most for a model whose Engram table is the single largest block in the download. Neither of those two changes carries a number outside the project, and the release notes attach none — but the project published a before-and-after on the model as a whole on October 7, three weeks after release: 1.9× faster at low concurrency and 5.3× the throughput under a 150 TPS constraint against its own day-0 build, with the merged pull request behind each optimisation listed. The figures and their limits are in the speed section above. What does not exist is an outside replication — every number in that post is the project measuring itself. What the release does settle is packaging: 762 commits from 315 contributors, 104 of them first-time, in a tagged version rather than a preview image. The vLLM recipe's own arithmetic still puts the minimum at roughly 614 GB of VRAM for the 510 GB checkpoint plus headroom — an eight-GPU H200 node or a GB200 NVL4 tray — and warns that a 1M-token context wants to be capped in practice rather than assumed. A narrower KV cache changes how much memory the running engine needs, not how large the checkpoint is, so the node floor stands. SGLang's write-up adds a lever specific to this architecture: moving the Engram table into host memory with a single environment flag raised KV cache capacity by about 36% on a four-GB300 test at comparable decode throughput and time to first token, and its decoder-side SWA bounded replay lifted prefill throughput 1.56× on eight H200s. Two limits travel with that. The reference implementation in the repository describes itself as a readable example rather than a production serving engine, and the consumer runtimes lagged: the quantization path that would put this on a laptop or a Mac Studio was not open at launch. The short version is that the weights are genuinely open and the serving stack genuinely exists — on hardware counted in nodes rather than GPUs, which is the honest reason a permissive licence does not automatically mean a local build. The 1017 repository changes nothing about that floor — the checkpoint is the same 510 GB across the same 48 shards, and the runtime notes that carry it are the ones published for September's weights.

What open weights do not give you, on their own, is a quality signal — but that gap has now partly closed, and it closed further on October 18. Four independent instruments now exist, one of them run twice: Artificial Analysis's Intelligence Index, which scores the September checkpoint at 39 and the 1017 checkpoint at 45; the Exploit Bench study above, a cyber benchmark run under seven agent harnesses; the community kernel board in the section below; and, since October 14, Artificial Analysis's own AA-AgentPerf results for this model, which measure the hardware it is served on rather than how good it is. The vLLM project's October 7 before-and-after, above, measures a different thing again — what the model costs to serve rather than how good it is — and is the runtime's own account of itself. None is a reasoning score of the kind ARC Prize is building, three of the four still describe the September checkpoint, and for most of the specific rows in this piece the model card remains the only source — but the composite no longer belongs on that list: the 45, and the 33.8 under it, were produced against the weights DeepSeek serves today. That is not an accusation; it is the state of the evidence, and it is why this article keeps the two kinds of number apart. Open weights do mean the model will not stay confined to DeepSeek's endpoint, which matters for anyone whose blocker was data residency rather than price.

How to adopt it without betting production on it

One thing changed on our side since the release, and it makes this section simpler than it would have been last week: DeepSeek V4.1 Flash is on OrcaRouter now. It answers to the model id deepseek/deepseek-v4.1-flash through the same OpenAI-compatible endpoint as the rest of the line, at DeepSeek's own rate — $0.15 per 1M input tokens, $0.60 per 1M output and $0.003 per 1M cache reads at off-peak rates, doubling inside the weekday peak windows — passed through with 0% markup. That last part is the one worth spelling out: the figure you are billed is the provider's figure rather than a resale price, so a vendor price cut is live here the same day instead of whenever a contract is renegotiated. DeepSeek V4 Flash and DeepSeek V4 Pro sit on the same key, which makes the migration below a routing change rather than a re-platforming. The October 17 checkpoint moves none of that: DeepSeek kept both the API model name and the rate card, so the update changes neither the id nor the price on this side, which is what a pass-through looks like when a vendor refreshes a model without touching either.

That is also the argument for not rushing the migration. The September 14 rerouting would have been a vendor changing what a model ID means underneath you, had DeepSeek not cancelled it under pressure, and the episode is the cleanest recent reminder that a model string is a contract a provider can rewrite — which is also the right frame for the line-up talk above, since a three-tier family is a plan and this one has already changed once. For a model whose only outside scores so far are a composite index, a noisy cyber table and a community kernel board — and which has no production record at all — the safer shape is the one a router is built for: send a slice of production-shaped traffic to the new model, hold a proven model behind it as an automatic failover so a quality regression costs a retry instead of an incident, and let the routing DSL decide which calls are worth the unproven model and which should stay on the workhorse. The migration to V4.1 Flash is probably the right destination. It is not a migration to run on the announcement.

Open questions

• Independent benchmarks — the count has gone from zero to four instruments, and none of them measures the model's reasoning the way ARC Prize intends to. Artificial Analysis's score of 39 is a composite of ten evaluations at maximum reasoning effort, and its 45 — published October 18 — is the same composite pointed at the newer weights. The Exploit Bench study above is a cyber-exploitation score inside a fixed token budget, and it rates DeepSeek V4.1 Flash below GLM-5.3-Flash. The community kernel board on kernelbench.com is a kernel-engineering table. Artificial Analysis's AA-AgentPerf results, published October 14, are a hardware table: how many tokens per second per megawatt each accelerator system serves this model at, and nothing about quality. Nobody has replicated DeepSeek's individual benchmark rows, and no independent measurement at production effort settings, or at the far end of a 1M-token window, has been published. The October 17 checkpoint is no longer unmeasured: on October 18 Artificial Analysis added a 1017 row at 45 on its index and 33.8 on Terminal-Bench 4.0, and the bench figure sits eight and a half points under what the vendor table claims for the same weights. What is missing now is a second opinion on that figure — one evaluator, one harness, one run — and any independent score at all for the four measurements that predate the swap. The one evaluation built to answer the reasoning question is still under construction — ARC Prize has a DeepSeek V4.1 Flash profile in its benchmarking harness in an open pull request, with no result attached — and ARC-AGI has never scored this checkpoint at all: the 61.4% on ARC-AGI-2 that the adapter's arrival revived belongs to DeepSeek V4 Flash 0731, the model V4.1 Flash retires. The newest number attached to this model, the 77.0 on DeepSWE v1.1, is the weakest-sourced row in the piece: it is DeepSeek's own chart, read off an image attached to the vendor's announcement, and no outside run of DeepSWE v1.1 on the 1017 checkpoint exists — Artificial Analysis's October 18 result is for the same weights but for a different benchmark. The two independent boards that publish the benchmark put this model's name at 71.7% and 74.2%, which is enough to place it beside Opus 5 and not enough to confirm the vendor's figure — and neither of them says which checkpoint it measured.

• Self-hosting below the node floor — vLLM's day-0 support became a stable release on September 22 with v0.30.0, which adds an MXFP8 KV path and asynchronous Engram offload; SGLang's day-0 support still ships as a preview image. Neither moves the hardware floor, which sits around an eight-GPU node because the 510 GB checkpoint is what sets it — and DeepSeek's own deployment notes, published with DeepInfer, put a finer point on it: one prefill node beside one decode node is deployable, but the recommended decode configuration is expert parallelism of 64 or above, which makes the smallest efficient unit 64 GPUs of prefill beside 64 of decode. The vLLM project's October 7 post is the fullest measured optimisation ledger published on this model — 1.9× at low concurrency and 5.3× under a 150 TPS constraint against its own day-0 build, alongside the SGLang figures above — and its October 17 follow-up adds a tokens-per-dollar curve that does span H100, MI300X and B200 configurations beside the rack-scale parts. Both are the project's own accounting of its own runtime. Neither moves the floor: a cheaper token on a GB300 or an H100 still does not fit a 510 GB checkpoint onto a desktop, so it is a faster path to the same floor rather than a lower one. Whether later releases and community quantizations bring this onto smaller machines is the open question for anyone who wants the weights rather than the endpoint, and it is the one that decides whether a permissive licence is a practical licence.

• What V4.1 Pro is — DeepSeek names it as the successor to V4 Pro but has published no date, no specification and no price, and the announced rerouting of existing Pro traffic to a Flash-tier model was withdrawn before it took effect. What sits above Flash is described by the company only as the architecture scaling to larger models; the Flash, Pro and Ultra ladder and its 522B, 2T and 8T sizes are one observer's speculation, not DeepSeek's.

• Per-task cost — Artificial Analysis now carries a per-task figure for both checkpoints: $0.49 per Intelligence Index task for the September weights, restated from the $0.27 this piece first carried, and $0.26 for 1017. That is the first outside evidence for any part of DeepSeek's Pareto claim, and it is narrower than the claim. The same rows show the 1017 checkpoint generating 210M output tokens across the index against 250M for September — shorter outputs in aggregate — but 89,495 output tokens per task against 88,574, which is not shorter at all, and 288.8 seconds per task against 289.9, which is not faster. The site's own cost breakdown puts the whole of the saving on the input side: the output line is flat, $0.106 per task against $0.107, while input falls from $0.379 to $0.155 and cache writes from $0.322 to $0.095. Whether a task finishes on fewer dollars depends on how many tokens it takes, and that is a property of the workload rather than of the rate card. DeepSeek's own account of the update points the other way: the changelog claims the new checkpoint reduces task runtime and output length, and its October 17 post repeats it as “faster task completion, and shorter outputs.” Neither carries a number, and the outside measurement behind this bullet has now met them: on the two quantities DeepSeek named, the 1017 weights moved by about one per cent, in opposite directions, from a starting point of five weeks earlier. A third figure sits on the other side of the same ledger: the vLLM project's October 17 chart puts the model at 1.3B tokens per dollar of total cost of ownership on SemiAnalysis AgentX, at a cost tier that assumes large-hyperscaler volume. Cheaper serving does not settle this bullet either — a lower cost per token leaves the tokens-per-task figure, which is what a caller actually pays for, exactly where the September measurement found it.

• Runaway verification — hands-on testers report occasional repeat loops in the chain of thought, and twelve-minute, six-figure-token deliberations on problems that resolve in seconds at a lower effort setting. No independent benchmark measures how often either happens or what it costs in production, and the mitigation reported so far is client-side token caps rather than anything the model does for itself. The Exploit Bench study above documents the same failure mode from the other direction: the repeated-report loop it shows in the ReAct transcripts is produced by the harness's compaction prompt rather than by the model's own reasoning, which is a reminder that a loop in a transcript is not automatically a model defect.

• Kernel engineering — kernelbench.com's community CUDA kernel board (RTX PRO 6000, roofline-scaled) has DeepSeek V4.1 Flash at 50.19% of the dense-equivalent roofline on its own sparse-attention kernel, fourth overall, against 4.45% for GLM-5.3 Flash on the same row. The board is community-run and not peer-reviewed; no second GPU generation or replication has been published.

• Long context at the far end — sparse attention was trained at 64K and extended to 1M at the 34T-token mark. How quality holds near the end of a full 1M window is precisely what an independent long-context evaluation would settle.

• Cache reconstruction at the edges — SWA Bounded Replay rebuilds dropped sliding-window state approximately rather than exactly, and DeepSeek says the result can vary depending on where a cache hit lands in a session. The report notes little observed quality impact; extreme or untested conditions are exactly where an approximation like that would surface, and nobody outside DeepSeek has looked.

• Whether Pro workloads actually move — the forced rerouting was withdrawn, so nothing moves unless a team chooses to move, and the teams that paid Pro prices for reasoning depth are the ones most likely to notice a capability difference on Terminal-Bench 3.0-shaped work, where V4.1 Flash trails Opus-5.0 by a wide margin.

• The free tier's terms and behaviour — OpenCode added a no-charge entry for this model on October 15, on a 200,000-token window and a 32,000-token output ceiling, described on its own pages as available for a limited time. Whether the arrangement outlives that phrase, how the endpoint holds up under load, and whether DeepSeek has any say in it are all unsaid: the platform's own model list, documentation and price table are the only source, there is no end date to hold anyone to, and nobody has published a measurement of the free route.

• Safety and refusals — DeepSeek publishes no refusal rate, red-team result or safety evaluation for either checkpoint, and no independent lab has scored this model on a jailbreak benchmark. The figures in this piece come from people building uncensored derivatives — 97 of 100 harmful prompts refused in chat mode, 98 in think mode, on one prompt set and one grader — and from a single agent-session screenshot in which the model declined a jailbroken persona. Whether that behaviour holds at low reasoning effort, in languages other than English, against automated attacks rather than a persona prompt, and under a harness that rewrites the system prompt, is unmeasured by anyone.

• The next checkpoint's paperwork — the October 22 report settles the registration question for weights that are already public, because the draft catalogue excludes technology already in the public domain. It does not settle the release after this one. The catalogue is a draft open for comment until November 15, its thresholds are reported rather than published in the text, and the interim registration duty said to have taken effect on October 16 has not been published in full. V4.1F-1017 itself is out, MIT-licensed and ungated; what a future DeepSeek checkpoint has to clear before it can be downloaded is a rule that does not exist yet.

The beta was a two-day question about whether a Flash-tier model could carry Pro duty. The release is DeepSeek answering it with a rate card and a routing plan — and then withdrawing the routing plan within two days when developers objected to having a production model swapped underneath them. That is a weaker statement than the announcement implied and a more honest one: the quality evidence for the move is DeepSeek's own benchmarks plus outside measurements that mostly point the same way. The newest of them, a cyber benchmark run under seven agent harnesses, points the other way on the one comparison it makes, and the company has left the choice with its customers rather than making it for them. Since the release the weights have gone from a promise to a 510 GB download, the model has gone from a vendor endpoint to something you can route to, and the serving stack has gone from a day-0 recipe to a measured one — vLLM reporting itself 1.9× faster at low concurrency three weeks in, then publishing, the day the checkpoint changed, a cost curve that prices the model at 1.3B tokens per dollar of total cost of ownership on SemiAnalysis AgentX. This week the layer under all of that opened as well: DeepSeek published DeepInfer, the engine its own service runs, with a decode curve for this checkpoint, the production figures behind that curve, and an unpublished September benchmark that puts Huawei's 950DT five to seven times behind NVIDIA per chip at the speed DeepSeek actually serves at. Five weeks in, the checkpoint itself moved once: October 17 brought new weights behind the same name and the same price, with a vendor table that is better on every row it publishes and a different harness under one of them. Two days later the outside measurement arrived, and it is the most useful number in this piece: Artificial Analysis put the 1017 weights at 45 on its index — level with GLM-5.3 for second among open-weights models, a point behind MiMo-V2.6-Pro — and 33.8 on Terminal-Bench 4.0, against the vendor's 42.3 on the same benchmark — so the harness that flatters the model in DeepSeek's own table is not the harness the number survives. If you are choosing today, the honest position is that V4.1 Flash looks like the best value in the DeepSeek line, has four independent instruments to its name — none of them a reasoning score, one of them now run against the checkpoint DeepSeek has served since October 17 — a fifth evaluation under construction, no production track record, a serving stack whose two strongest numbers — a speed delta and a cost curve — both come from the project that wrote the runtime, and an outside cyber result that already disagrees with itself depending on which harness you wrap around the model, a free 200,000-token tier that appeared on one platform on October 15, and a first round of hands-on reports describing a model that checks its own work further than most callers will ask it to — which is a reason to point a slice of traffic at it, not a reason to migrate on the announcement. The update DeepSeek announced on October 17 changes the weights and adds a vendor claim — faster task completion, shorter outputs — and the first outside measurement of those weights supports half of it at best: cost per index task cut by 46%, while time per task and output tokens per task barely moved. A day on, the widest-read claim about that checkpoint was an executive's: 77 on DeepSWE v1.1 at 83× lower cost, from a Databricks staffer who also says the checkpoint is coming to that platform. Half of it survives contact with the independent boards, which now put this model's name above Opus 5 on that benchmark. The other half does not yet: the 77 is DeepSeek's own row, unreproduced, and the 83× is arithmetic with no published per-task cost behind it. Databricks' own documentation confirms the model is on its platform and that the two DeepSeek models below it are scheduled to leave; it does not confirm the checkpoint is arriving. That claim is now the second-most-interesting one about the checkpoint rather than the most. On October 19 a tracker account that has called several of these releases early declared itself “dead certain” of the 42.3 on Terminal-Bench 4.0, on the grounds that it beats GLM-5.3, and asked Artificial Analysis to run the model in a native harness. The site had already done it. On its own harness the same weights score 33.8 — below GLM-5.3's 41.9, not above it. The vendor row is real and it is DeepSeek's; the inference drawn from it does not survive being run by somebody else.

If the version of this you want is the one that keeps your options open, all three are one key away and priced at D​eepSeek's own rates with 0% markup added. The release itself: DeepSeek V4.1 Flash on OrcaRouter — 1M-token context, a 384K output ceiling, image input, at $0.15 per 1M input and $0.60 per 1M output off-peak. The model it retires: DeepSeek V4 Flash on OrcaRouter. And the flagship D​eepSeek decided to keep serving: DeepSeek V4 Pro on OrcaRouter. Point a slice of traffic at the new one, keep a proven model behind it as failover, and let the routing decide.

A model choice is also a question of what has gone wrong before: the documented AI incidents and agent failures for models of this class are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.