# DeepSeek's Pro Endpoint Will Stop Meaning Pro **Summary:** DeepSeek says every V4 Pro request will temporarily route to V4.1 Flash at Flash prices. I like the lower bill, but an API name that changes models is a weak contract for audits, evals, and rollback. - Canonical: https://markhuang.ai/news/deepseek-pro-endpoint-will-serve-flash - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-09-09 - Section: News - Tags: DeepSeek V4.1 Flash, DeepSeek V4 Pro, Model Routing, API Versioning, AI Evaluation - Source: [Hacker News](https://news.ycombinator.com/item?id=49624603) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![A stream of blue data passes through a hidden mechanical junction from a large compute core to a smaller core](https://cdn.markhuang.ai/news/deepseek-pro-endpoint-will-serve-flash/hero.webp) *A fixed API socket hides a model switch. Reproducing yesterday's result requires knowing which route the request took.* A [Hacker News submission reproduces a DeepSeek platform notice](https://news.ycombinator.com/item?id=49624603) that changes the meaning of an existing API name. DeepSeek plans to release V4.1 Flash around September 10, 2026, then route every request for V4 Pro to the new Flash model until V4.1 Pro arrives. Those requests will be billed at Flash prices. The same notice lists new off-peak rates of $0.003 per million cached input tokens, $0.15 per million uncached input tokens, and $0.60 per million output tokens. Peak rates will be twice as high. Cheaper and faster is welcome. My problem is the name: after the switch, asking for `deepseek-v4-pro` will no longer mean that DeepSeek served V4 Pro. I would treat this as a migration, even if DeepSeek presents V4.1 Flash as better across performance, cost, speed, and total task time. A broad vendor claim cannot tell me whether my parser or coding agent will behave the same. The bill may fall while the audit trail gets fuzzier. ## The discount comes with a different model There is a real customer benefit here. DeepSeek is not charging Pro rates while it sends traffic to a cheaper model. [ITHome reported the same platform notice](https://www.ithome.com/1/000/222.htm) and gave the new off-peak prices in renminbi: ¥0.02 for cached input, ¥1 for uncached input, and ¥4 for output per million tokens. Peak prices are double. Those figures line up with the dollar prices in the submitted post. DeepSeek also says V4.1 Flash has surpassed V4 Pro on every named dimension after internal and external testing. I am interested, but the notice does not publish the test set, harness, score breakdown, provider conditions, or failure cases. "Better" at the product level is therefore a reason to run an evaluation, not a guarantee that each existing Pro workload improves. There is an obvious objection to my caution. If Flash is cheaper, faster, and more capable, why make users opt into an inferior model? Because aggregate improvement and behavioral compatibility are different questions. A model can win more tasks overall while regressing on the narrow prompt, output shape, or tool sequence that pays a particular team's bills. > **Info:** > > Before September 10, I would save a small set of representative Pro requests and accepted outputs. After routing changes, I would replay them, record the served model revision if DeepSeek exposes it, compare failure modes and latency, and keep a rollback path through another pinned endpoint or provider. ## A stable alias can still wreck a comparison DeepSeek's [official pricing page](https://api-docs.deepseek.com/quick_start/pricing/) currently maps `deepseek-v4-flash` to DeepSeek-V4-Flash-0731 and `deepseek-v4-pro` to DeepSeek-V4-Pro-0813. Both accept a 1 million-token context and advertise a maximum output of 384,000 tokens. Those friendly API names already sit in front of dated revisions. The [official change log](https://api-docs.deepseek.com/updates/) makes that arrangement explicit. On August 13, DeepSeek said callers could keep using the same Pro model name to receive the new GA release. The July 31 Flash update similarly kept the Flash name while changing the version behind it. Aliases make upgrades easy, but the new plan goes further: a Pro alias will temporarily resolve to a model in a different tier. That matters whenever results need to be reproduced. A regression report that says "we used V4 Pro" becomes ambiguous across the cutover. So does an eval trend line, unless the test record captures the actual served revision. If the API response only echoes the requested alias, DeepSeek should add immutable revision metadata. If it already exposes that metadata, teams need to store it rather than logging only the request body and endpoint. I would not compare a V4.1 Flash result collected after the change with an older Pro result and call it an apples-to-apples retest. The model changed, and the surrounding service may have changed with it. The alias hides exactly the variable the experiment needs to preserve. ## The public test is still too young Public reaction is enthusiastic but thin. In the HN discussion, one commenter traced the notice to a banner on DeepSeek's usage page, while others focused on the novelty of a Flash release leapfrogging Pro. A [same-day Reddit thread](https://www.reddit.com/r/DeepSeek/comments/1wan8tr/is_deepseek_v41_flash_avaiable_on_web_thanks/) includes early API impressions and a report that the beta was available only through the official API. These are useful leads, not a substitute for a published evaluation. The release notice asks users to report problems found in comparative testing. That request makes sense, but it also tells me customer workloads are part of the validation process. DeepSeek is making the routing decision before those customers have had much time to publish what moved. I reached a similar conclusion when [V4 Pro 0813 reached general availability without a detailed technical diff](/news/deepseek-v4-pro-0813-ga-missing-diff): pin what can be pinned and make the new build earn traffic on the workload that matters. V4.1 Flash may well earn it. The forced route merely removes the option to learn at one's own pace. ## What I would want from DeepSeek DeepSeek should publish the comparison behind the "surpassed across all key metrics" claim. It does not need to prove universal superiority. A task list, harness configuration, latency definition, and known regressions would let customers decide where the evidence transfers. I also want the immutable model revision in every response and usage export. Billing can still follow the cheaper Flash rate. The requested alias and the served revision belong in separate fields because they answer separate questions. Production users should have a temporary opt-out or a dated Pro endpoint. Some will accept the new route immediately. Others have contractual tests, regulated records, or fragile integrations that make a controlled migration worth more than the token discount. I like the price cut, and I would put V4.1 Flash into a shadow test as soon as it is available. I would not pretend the endpoint stayed the same. DeepSeek is changing the model while preserving the name, which gives users a generous price and a weak versioning contract.