DeepSeek V4.1 Pro Turned Up in a Coding Agent's Source Code. It Is a Test Fixture.

At 18:50 UTC on 11 November 2026, a commit landed in an open-source coding agent's model-picker code. Among the strings it added was deepseek/deepseek-v4.1-pro. Within a day the id had travelled from a code diff into a quote-tweet reading "DeepSeek-v4.1-pro might be coming soon", and from there into the timeline of the tracker who replied that a new whale was not something to expect any time soon, "maybe it'll take until Feb (I hope not)". The id is real and the commit is public, so the sighting is checkable — but the thing it points at is not. The string appears exactly twice in the whole repository, both times inside a single unit test, as a fixture row in a table of invented model entries. D​eepSeek V4.1 Pro has not been released. D​eepSeek's own documentation still sells exactly two chat models: DeepSeek V4.1 Flash, now on the 1017 checkpoint, and DeepSeek V4 Pro, still on the 0813 build.

This is a what-we-know-so-far piece about an unreleased model, so nothing below should be read as a launch, a date, a spec sheet or a price. What follows is the document that started it, the mechanism inside that document that explains why a Pro-tier D​eepSeek id had to be there, and the checks that separate a fixture from a listing — each of which anyone can rerun in a browser.

What the commit actually added, line by line

The change is small and its purpose is mundane: it makes the four models a paid plan covers sit at the top of the model picker instead of somewhere below it, and stops those same models from taking a second slot through the picker's per-family highlight logic. Two source files change. One introduces the list of four ids; the other rewrites the projection function and adds a test.

The test is named picker lists Token Pass models first without a second slot for their families. It builds eight fake catalogue rows and asserts the order the picker should produce. Four of the eight are the ids that plan pays for. The D​eepSeek fixture is written as deepseek/deepseek-v4.1-pro with released = 260 and has_tool_use = true, sitting next to deepseek/deepseek-v4.1-flash at released = 255. Those numbers are not dates, timestamps or anything a catalogue would return; they are ordinal sort keys the fixtures use so the assertions do not depend on a live feed. Every row in that table — including Claude, G​PT and K​imi entries — is hand-written for the test.

And the assertion itself is the part that matters. The expected order puts the D​eepSeek Pro id seventh out of eight, behind the Flash model that the paid plan lists, behind two Z.ai models and behind both a Claude and an O​penAI id. In a real catalogue projection, a Pro id with a higher recency key than the Flash id would normally win the family's single highlight slot. The test exists to prove that it does not, because the paid-plan model already occupies that slot. A fixture written to lose is a strange thing to read as an announcement.

Why a Pro id had to be in the fixture at all

This is the one piece of the story that is mechanism rather than speculation, and it is also the piece that makes the sighting feel more meaningful than it is.

The picker's highlight list gives the D​eepSeek family a count of one: one D​eepSeek model gets promoted into the curated section. A model the paid plan covers is pushed to the very top first. If that top model belongs to the D​eepSeek family, the family's slot counts as filled, and the highlight loop is skipped for it. That is the whole behaviour under test, and it is implemented as a subtraction: the slot count minus the number of models already selected for that family.

To demonstrate that subtraction doing anything, the fixture needs a second D​eepSeek id that would otherwise have been chosen — and it needs to be the strongest possible candidate, or the test proves nothing. The picker's family comparator prefers the newest model by recency key, and at equal recency it applies a DeepSeek-specific rank in which a -pro suffix sorts ahead of a thinking variant, which sorts ahead of everything else, with -flash last. A -pro fixture with a higher recency key than the Flash model is therefore the exact row that would steal the slot if the new subtraction were removed. The test is written so that the fixture has to be a Pro id and has to be newer than Flash.

That gets you a D​eepSeek Pro id in the diff without anyone knowing anything. It does not, on its own, explain the version. D​eepSeek's live Pro tier is DeepSeek V4 Pro, and the obvious fixture would have been the id of a model that exists. Whoever wrote the row reached for v4.1-pro instead — which is either a natural guess at the next name in the line, or a copy of a real string from somewhere else. The file gives no way to tell which, and that ambiguity is the entire content of the leak. Everything posted after 11 November is downstream of it.

The four checks that separate a fixture from a listing

If D​eepSeek had actually readied a Pro tier, the id would appear somewhere that a customer can hit, not only in a test table. Each of the following was checked on 13 November 2026 and each is a one-page load.

• D​eepSeek's changelog — newest entry is 17 October 2026, the Flash 1017 update and the opening of the search API. There has never been a V4.1 Pro entry. Every V4 release D​eepSeek has made was announced on this page first.

• D​eepSeek's model list and price sheet — two model names, deepseek-flash and deepseek-v4-pro, with the version strings DeepSeek-V4.1-Flash-1017 and DeepSeek-V4-Pro-0813 attached. No third row, no Pro-tier V4.1 row, no placeholder.

• The deepseek-ai organisation on Hugging Face — newest repository is DeepSeek-V4.1-Flash-1017, created 17 October, last touched 10 November with a chat-template commit. There is no V4.1 Pro repository, no gated one, nothing private-adjacent.

• Our own catalogue — 215 model ids, eleven of them D​eepSeek, and none matching any spelling of v4.1-pro. The D​eepSeek entries top out at DeepSeek V4.1 Flash on 1017 and DeepSeek V4 Pro on 0813.

Gateway catalogues that mirror D​eepSeek's API, including the one the agent in question reads at runtime, list fourteen D​eepSeek ids and none of them is V4.1 Pro. That is the sharpest single contrast in this story: the same project ships a picker that fetches a live catalogue, and the string is absent from the catalogue while present in the test that runs against a fake one.

The name is not new, and its paper trail is one sentence

D​eepSeek V4.1 Pro entered circulation on 10 September 2026, in the release note that shipped DeepSeek V4.1 Flash. The note announced a 552-billion-parameter mixture of experts on a new Causal Encoder-Decoder architecture — 8 billion parameters active on input, 16 billion on output, native image understanding, a KV cache a quarter the size of the previous generation's — and then, in the same bullet list, said that from 04:00 UTC on 14 September all deepseek-v4-pro requests would route to V4.1 Flash at Flash rates, and that this would continue "until V4.1-Pro launches".

The reroute did not survive contact with developers, and D​eepSeek restored DeepSeek V4 Pro at unchanged billing. The parenthetical survived. In the nine weeks since, it has been the only documentary evidence that a Pro tier of the V4.1 line is planned at all: no card, no checkpoint, no price, no date, and — as of this week — no second mention anywhere in D​eepSeek's own material.

What the September note does establish is the shape a V4.1 Pro would have to fit. D​eepSeek described Flash as the smallest model in a new architecture family, built so that it can be scaled up, and claimed it beat V4 Pro on capability, cost, speed and total runtime. A Pro tier in that family is the natural next step and a reasonable thing to expect. Expectation is not evidence, and the fixture is not a schedule.

What is callable today, and the comparison a V4.1 Pro would have to win

Two D​eepSeek models answer requests, and they are further apart than the naming suggests. DeepSeek V4.1 Flash, on the 1017 checkpoint, is a 1M-context multimodal model with vision input, 384K maximum output, thinking on by default with three effort levels, and an MIT licence on the weights. Off-peak it costs $0.15 per million input tokens on a cache miss, $0.003 on a cache hit, and $0.60 per million output; peak hours — 01:00–04:00 and 06:00–10:00 UTC on weekdays — are double. DeepSeek V4 Pro, on the 0813 build, is the 1.6-trillion-parameter flagship from the previous generation: text only, no vision, the same 1M context, and $0.66 input / $1.98 output off-peak, or roughly four and a half times the Flash price for a model D​eepSeek's own benchmarks put behind it.

On the independent harness, the gap is not close either. Artificial Analysis scores DeepSeek V4.1 Flash 1017 at 33 on its Intelligence Index, at 14.8 minutes and $0.60 per index task, generating 174 million tokens to get there — verbose, and slower than the median model per task. The same index puts Kimi K3.1 Pro, the top open-weights entry, at 46. That is the number a V4.1 Pro would be built to move, and it is the reason the name keeps attracting attention: the gap between D​eepSeek's cheap tier and the open-weights frontier is thirteen points of index, which is exactly the kind of gap a flagship is supposed to close.

If you want to find out whether the 1017 checkpoint closes any of that on your own workload, the practical question is not which D​eepSeek tier to standardise on but whether you can afford to be wrong about it. Both models sit behind a single endpoint on OrcaRouter at the provider's list price with no markup, which means the Flash and Pro rate cards above are the same numbers you pay, and the off-peak window is the same window. That matters more than usual here: the two models differ by 4.5x on output price and by an unknown amount on quality for your specific task, so the cheap way to settle it is to route a slice of real traffic at one and a slice at the other, and let automatic failover absorb the experiment if the model you tried turns out to be the wrong pick.

The eleven hours that turned a fixture into a rumour

The timeline is short enough to state exactly, and it is the best evidence that nobody involved had new information.

• 11 November, 18:50 UTC — the commit adds the picker test. The id is in the diff and the diff is public.

• 12 November, 13:35 UTC — a poster notices the diff, links straight to the line in the source file, and writes that D​eepSeek V4.1 Pro "might be coming soon", adding the alternative that it might just be another checkpoint update to Flash. The post is honest about the uncertainty and reads the file correctly as evidence of intent.

• 12 November, 23:08 UTC — the tracker account best known for D​eepSeek coverage replies with the reading that the file does not support: the test only checks that a paid-plan model at the top fills its family's slot, so it needs more than one D​eepSeek id. The reply adds that D​eepSeek's API has nothing new, that a new flagship is not something to expect soon, and that February is the pessimistic guess.

Nothing in that sequence is a vendor statement, and no party to it claims to have one. The second poster's analysis of the mechanism is correct as far as the source goes — the slot subtraction is exactly what the test is for — and the conclusion drawn is the conservative one: the fixture is a fixture.

What would move this from a fixture to a fact

Four things would, and only one of them is a rumour. A changelog entry on D​eepSeek's API documentation naming a Pro tier, since that is where every V4 release has been announced and its newest entry is still 17 October. A repository in the deepseek-ai organisation with V4.1 Pro in the name, since both V4 and V4.1 shipped as open weights under MIT within a day of their API launch. A third row on the price sheet — D​eepSeek has never sold a model it did not list there. Or an id that resolves on the API, which is the check that would have settled this in one request and instead settles it the other way.

Until one of those lands, the honest summary is narrower than the posts suggest and more useful than a date. A working engineer typed deepseek-v4.1-pro into a test table on 11 November, most likely because it is the obvious next name in a line the author was already handling, and possibly because it had been seen somewhere. The string is worth knowing about for exactly that reason — it is a small, weak, real signal that people close to the tooling expect the name — and worth nothing at all as a schedule. The tracker's February is a guess, the quote-tweet's "coming soon" is a guess, and the only thing either of them has that a reader does not is the same public commit.