DeepSeek V4.1 Pro, Unlabelled: A 180 tok/s Endpoint, a Four-Sample Result, and the Outage That Just Ended

Somewhere behind D​eepSeek's API there may be a new model, and nobody — including the person who noticed it — is willing to say for certain that it is D​eepSeek V4.1 Pro. The evidence is one post on X, published on the morning of October 15, 2026 by the tracker @teortaxesTex, and what it describes is a model that answers when called through the vendor's own endpoint, that finished a specific prompt the two known D​eepSeek flagship models could not, and that came back at roughly 180 tokens per second. The two known ones are named in the same breath: DeepSeek-V4-Pro-0813 "is helpless" at the task, and the V4.1 generation was too — which, in the poster's own words, is the part that makes a new model plausible rather than a routing accident. That is the whole case. There is no model card, no weights, no price, no endpoint name and no release note from D​eepSeek, and DeepSeek V4.1 Flash — the open-weights model from September 10 — is not a candidate, because Flash is a shipping product with a public price sheet rather than something that has to be discovered by behaviour.

What makes the signal worth writing down before it resolves either way is the shape of the evidence rather than its strength. This is not a benchmark leak, not a repo that appeared early, not a staff hint. It is a black-box observation: someone paid attention to what an endpoint did, noticed it had changed, and said so with the sample count attached. Those observations are how a stealth release gets caught at all, and they are also how a lot of false positives get started. The difference between the two is entirely in what can be checked afterwards, so the useful thing to do with this one is to lay out what was claimed, what D​eepSeek's own published material can corroborate today, and what would have to happen before anyone can call it a release.

What was actually claimed, and what it does not establish

The post is short and it separates its own claims better than most launch coverage does. Strip it down and there are four:

• A D​eepSeek service outage that had been running ended, and the model's behaviour changed around that point — the poster's framing, and the reason the observation exists at all.

• The endpoint passed "the cuckold joke" with what the poster calls the best results this side of C​laude, reproducing at N=4 — four samples, same outcome.

• DeepSeek-V4-Pro-0813 and the V4.1 generation both failed the same test, which the poster states flatly as "helpless."

• Speed came in around 180 tokens per second, and the conclusion offered is explicitly a guess: "Might be 4.1 Pro."

Three of those four are observations of a black box, and the fourth is a model name attached to them by inference. Nothing in the post claims an announcement, a price, a context window, a parameter count, or that D​eepSeek has said anything at all. The speed figure is the poster's own measurement of their own session, not a vendor number and not a leaderboard number. Treat it as a datapoint from one route at one moment, on one prompt, with an unknown amount of prompt caching behind it — which is exactly how it was presented, and roughly how much weight it should carry.

Where the name "V4.1 Pro" comes from

It is not invented. D​eepSeek named a Pro tier in the V4.1 line itself, in its own September 10 release note, and as of today that name still has nothing attached to it. The passage that put it into circulation said that requests to deepseek-v4-pro would be rerouted to the newly shipped Flash model and billed at Flash rates from 04:00 UTC on September 14, and that this would continue "until V4.1-Pro launches." Developers objected to a production model being swapped with no migration window, D​eepSeek reversed the plan, DeepSeek V4 Pro kept answering with billing unchanged — and the clause that survived the reversal was the one nobody was meant to notice, which is that a V4.1-Pro is planned.

Everything after that sentence is inference. The company has published no card, no date and no weight file. So the name in the post is the name a reader would reach for given a fourth model that behaves better than the three they know: the V4.1 family is the current generation, Flash is the small one, Pro is the tier D​eepSeek has already promised. Reaching for it is sensible. Reaching for it is not evidence.

That matters more than it sounds, because there is at least one other explanation that requires no new model at all. A silent point update to an existing build — a re-quantised or re-tuned serving configuration, a different backend path, a rollback after the outage — would show up for a black-box observer as a capability change with no announcement and no name. D​eepSeek's own changelog records exactly this kind of thing in the past: V4 Pro was updated in place on August 13 under a build-stamped name, and the Flash line has had an update entry with no ceremony attached. Stealth releases and silent rebuilds are indistinguishable from the outside, and the post does not claim to have distinguished them.

What D​eepSeek's own material says today

This is the part that can be checked, and it is short. D​eepSeek's changelog goes 2026-04-24 (V4), 2026-07-31 (a V4-Flash update), 2026-08-13 (the V4-Pro update), 2026-08-21 (V4-Flash-Vision-Exp) and 2026-09-10 (V4.1-Flash). There is no October entry of any kind, and no entry titled V4.1 Pro. The Models & Pricing page lists two usable names, deepseek-flash and deepseek-v4-pro, resolving to D​eepSeek-V4.1-Flash and DeepSeek-V4-Pro-0813.

• Context and output — both D​eepSeek-V4.1-Flash and DeepSeek-V4-Pro-0813 take 1M tokens in and return up to 384K, with concurrency caps of 2,500 and 500 respectively.

• Price — Flash runs $0.15 per million input tokens on a cache miss and $0.60 per million output off-peak; V4 Pro runs $0.66 in and $1.98 out off-peak, with peak hours priced at double.

• Vision — built into DeepSeek V4.1 Flash, listed as "Not supported" for DeepSeek V4 Pro.

• Weights — D​eepSeek-V4.1-Flash is open under MIT; there is no repository for anything called V4.1-Pro, which is the strongest single piece of negative evidence available.

On Hugging Face, the newest D​eepSeek model repo is deepseek-ai/D​eepSeek-V4.1-Flash, last touched October 12 — a performance commit about restoring indexer key caches on incomplete compression steps. That is engine work on a model that already exists, not a new flagship. Whatever the poster was talking to, it left no artefact in the places a shipped D​eepSeek model normally leaves one.

The speed number is the least surprising thing in the post

180 tokens per second reads as fast, and against the wrong baseline it would look like a giveaway. Against the right one it is unremarkable. Independent measurement has put DeepSeek V4.1 Flash near the top of its class on raw throughput, and third-party operators serving the same open weights advertise considerably higher figures than 180 with a warm cache. A number in that range is what a well-served D​eepSeek model looks like; it is not fast enough to prove a larger backbone and not slow enough to prove a smaller one. Anyone treating 180 t/s as the tell is reading the least diagnostic line in the post.

The more interesting asymmetry is the task result. A model that clears something both DeepSeek-V4-Pro-0813 and V4.1 fail, four times out of four, on a prompt deliberately built to be hard to fake, is a genuinely different capability profile — assuming the test itself is sound, which the post does not let a reader verify. That is the claim to watch, and it is the one that a benchmark table will eventually settle.

Why "the cuckold joke" is a real signal under a silly name

The phrase will read as a joke and it is not one. Relational-reasoning prompts of that family — nested beliefs, contested knowledge, who-knows-what-about-whom — are a long-standing probe for whether a model can hold several layers of a social situation at once without collapsing them. Frontier labs and independent evaluators both use variants of it, because it is short, cheap, resistant to memorisation, and disproportionately punishing to models that pattern-match the surface of a scene instead of tracking the state underneath it. It spreads across social media as a joke for the same reason it gets used as a test: it is memorable and it is hard.

It is also, by itself, weak evidence. No sample count on a single ad-hoc prompt distinguishes a new checkpoint from a new sampling configuration, a different reasoning-effort default, a change in which backend pool answers, or simply a prompt that sat near a decision boundary and happened to land differently after the service came back up. N=4 helps — the poster did the minimum diligence most viral capability claims skip — but four samples establish reproducibility on one route for one prompt. It is a reason to go and look. It is not a reason to conclude.

The practical question: can you try it, and how

Right now, no. There is no name to call. If the thing the poster was talking to is real and unnamed, it is reachable only as an accident of which model D​eepSeek's own routing happens to hand you, which is precisely the situation the September reroute reversal was about.

The models you can define today are the two the price sheet lists, and the honest way to test a change you cannot see is to pin your production traffic at the model you chose and move the experiment somewhere it cannot hurt. DeepSeek V4.1 Flash and DeepSeek V4 Pro are both available through OrcaRouter on one API key, so a side-by-side against a fixed prompt set costs a config change rather than a second contract — and where a route degrades, automatic failover drops the request to a healthy provider instead of returning an error, which is the failure mode that made the outage in the post visible in the first place. Since OrcaRouter passes provider list price through at 0% markup, any D​eepSeek price change lands on the same day it lands at the vendor, without a repricing exercise on your side.

What none of that gives you is the unlabelled model. If you think you have hit it — faster than expected, better on a probe your usual model fails — capture the raw responses with timestamps and the request IDs, because that is the material that turns a sighting into something the rest of the field can check. Reproduce it on a second day. Reproduce it after a redeploy. A stealth model that only exists in one window is a routing artefact until proven otherwise.

What would turn this into news

Four things, in rough order of likelihood. A model card or a weight repository appearing under a V4.1-Pro name would settle it outright and would be the first real artefact. A changelog entry or a new name on the Models & Pricing page would do the same from the vendor side. A first independent benchmark — Artificial Analysis or LMArena picking up an entry that does not match any listed D​eepSeek build — would corroborate the capability jump without confirming the name. And the quietest possibility of all: nothing. D​eepSeek updates models in place, and on the current timeline — V4 in April, Flash updates in July and August, a Pro update on August 13, V4.1 Flash in September — the near-term probability is a silent refresh of an existing name rather than a fourth tier.

Until one of those lands, the correct status of "D​eepSeek V4.1 Pro" is the one it has held since September 10: a name D​eepSeek itself put on a roadmap, with no model behind it. A single observer's 180 tok/s session is a reason to keep watching the endpoint, not a reason to plan around a flagship.

Laid out that way, the asymmetry is the story. One column of that card is documentation — a price sheet, a licence, a model name you can put in a request body — and the other is a sentence in a release note plus a mention on X. Everything in this article that can be checked sits on the left. Everything on the right is what people are hoping the 180 tok/s endpoint turns out to be, which is a reasonable hope and not yet a fact.

Who should do what

If you are choosing a model to build on this week, nothing here changes your decision. DeepSeek V4.1 Flash is available, priced and documented; DeepSeek V4 Pro is available, priced and documented; D​eepSeek V4.1 Pro is not a product. The one thing worth taking from the post is the failure mode rather than the model: a vendor endpoint changed behaviour after an outage and there was no notice, no version bump and no way to tell from the outside what you had been talking to. Pinning model versions explicitly, capturing response metadata, and putting a failover path behind any single provider is the mitigation, and it is the same mitigation whether or not a new flagship is hiding behind the endpoint.

If you are watching for the release, watch the changelog and the Hugging Face organisation rather than the capability chatter. Both have been the reliable tell for this lab. Neither has said a word since September 10.

A result like this is also a reminder that model mistakes are already documented: the AI incidents and agent failures behind models in this class are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.