DeepSeek V4.1 Flash: Pro Routing, Prices and Early Tests

DeepSeek V4.1 Flash is an announced change to the model behind Pro requests, as well as a cheaper option to evaluate. A September 9 customer email supplied to Digital Applied says DeepSeek plans to release it around September 10, Beijing time, and temporarily route Pro requests to Flash. For a team already using Pro, the immediate job is to save a comparison of its current results before that transition.

There is an early public design evaluation worth examining, but we have not found a V4.1 technical report or official numerical benchmark suite in DeepSeek’s public release documentation. This article separates the customer notice, the published evaluation and our recommendations. It does not establish that the final model has launched or that it improves every workload.

The email gives the following USD rates per million tokens, effective September 10 at 04:00 UTC, or noon in Beijing. Cached input means input billed at the cache-hit rate; uncached input uses the cache-miss rate. These are announced future prices, not a claim that the public price list has already changed.

Peak hours are Monday through Friday, 01:00–04:00 and 06:00–10:00 UTC. All other hours are off-peak. The existing DeepSeek pricing documentation confirms those windows, but still displayed the previous rates at our September 9 check. Do not substitute local clock time for UTC when estimating a scheduled job.

A lower token rate is only one part of a lower bill. A replacement that takes more attempts, writes longer answers or needs additional review can erase some savings. For the broader scheduling issue, our off-peak LLM pricing analysis explains why the cheaper window and the cheaper completed task are different comparisons.

According to the notice, after V4.1 Flash launches and before V4.1 Pro arrives, Pro requests will be served by V4.1 Flash and charged at Flash rates. The notice supplies no V4.1 Pro launch date. It also does not establish the final callable V4.1 identifier, so there is no new configuration string to copy from this article.

DeepSeek’s current API introduction still maps the Pro alias to V4-Pro-0813. That is the existing documented arrangement; the email describes a forthcoming one. Our coverage of V4 Pro’s earlier general release provides the dated background.

The practical consequence is reproducibility. A saved prompt and the same model label may no longer reproduce the same underlying conditions. Record the request date, requested model and returned version information where available. If retaining the old model is essential, seek explicit confirmation of that option; neither the notice nor the public documentation we inspected establishes one.

OpenDesign Arena publishes these results for prototype-design tasks. They are the evaluator’s reported measurements, not tests run by Digital Applied or confirmation of the final production checkpoint.

The dashboard subset reverses the overall DeepSeek ranking: V4.1 Flash scores 76.1 against Pro’s 83.0. A favorable average therefore does not mean every scenario improves.

DeepSeek’s customer notice makes a broader superiority claim, including performance, speed and task completion time. We have not found the accompanying numerical suite in its public changelog. Older V4 scores cannot fill that gap: they describe different releases. Treat the notice as the company’s claim and the design evaluation as one reason to investigate it.

Our recommendation is a small comparison using work you can judge. Choose examples with a known acceptance condition: an existing test suite, a required output format, a document answer checked against its source, or a prototype with specified interactions. Include a troublesome example alongside routine work. Attractive output alone is a weak acceptance test.

1. Save the current conditions. Keep prompts, input files, tool versions, permissions and model settings with the results. Record failures as well as successes.
2. Repeat after the change is confirmed. Keep the surrounding workflow consistent. If you change tools or instructions too, report that as a different experiment.
3. Count accepted outcomes. Record elapsed time, billed usage, retries and necessary human corrections. Compare total spend with the number of results you would actually use.

For example, a generated dashboard can render successfully while showing the wrong totals or dropping a filter state. Write those checks before looking at the new output. This makes the comparison useful even when the replacement produces a more polished first impression. Our Astra and Fable comparison develops the same distinction between advertised prices and the work needed to reach an accepted result.

Evidence checked September 9, 2026: the supplied customer email, DeepSeek’s public API documentation and OpenDesign’s evaluation. The routing notice was not independently retrieved from the sign-in-only platform. Final V4.1 specifications, weights and general benchmark results remain unverified here.