DeepSeek V4.1 Flash vs V4 Pro: Which Should You Use?

You can leave deepseek-v4-flash in a configuration file and still get a different model. DeepSeek V4.1 Flash vs V4 Pro therefore starts with a less obvious question than which one scores higher: which version is actually answering? DeepSeek’s official documentation, checked on September 10, 2026, says the old Flash models have retired. Their names still accept requests, but V4.1 Flash now serves them.

For developers maintaining document extraction, support assistants or coding tools, the new text-and-image model has a clear attraction: lower official token prices and image input that the currently listed V4 Pro lacks. The catch is that keeping an old API name no longer preserves an old baseline. An upgrade decision and a reproducible comparison are now two different problems.

DeepSeek V4.1 Flash vs V4 Pro: Key takeaway

• V4.1 Flash is the stronger candidate for a new integration on documented price and image support; this is not an independent benchmark verdict.
• At official peak rates, Flash costs $0.30 per million uncached input tokens and $1.20 per million output tokens, versus Pro’s $1.32 and $3.96.
• Both list a 1M-token context window and a maximum 384K-token output. Those limits do not distinguish them.
• DeepSeek plans to redirect V4 Pro requests to V4.1 Flash from September 14 at 12:00 Beijing time, until V4.1 Pro is released. The old Flash names already redirect.

The old Flash name no longer buys the old Flash

The most consequential part of the official pricing page is underneath the price table. Footnote 1 says the legacy Flash names remain accepted, but “the corresponding models have been retired.” This is backward compatibility for the request, not a promise to keep serving the same model.

Here is what the official API names mean in the September 10 documentation:

Name in the request	Documented model or status	What it means for a comparison
deepseek-flash	DeepSeek V4.1 Flash	Current recommended Flash name
deepseek-v4-flash	Retired model; routed to V4.1 Flash	Not a way to select the previous Flash
deepseek-v4-flash-vision-exp	Retired experimental model; routed to V4.1 Flash	Not a separate current vision baseline
deepseek-v4-pro	DeepSeek V4 Pro 0813	Scheduled to redirect on September 14 at noon Beijing time

The old Flash names already route to V4.1 Flash; Pro’s change is scheduled for September 14. The same footnotes define the peak-price windows.

That makes a simple “send the same prompt to both Flash IDs” test misleading. Two different answers could be variation between runs of the same model rather than a difference between generations. A meaningful historical comparison needs saved outputs from before the change, with dates and request settings, or a deployment whose exact version can be established.

Pro still has a dated comparison window under the published schedule. A result gathered in that window should not be presented as something readers can reproduce indefinitely with the same request name. Someone following it after the planned change could end up comparing Flash with Flash.

This is also why an older setup article should be read as a snapshot. The September 8 Flash preview and Harness article concerns earlier access information. The current official documentation now answers questions that were unsettled then, including the recommended model name and published context limit.

How much cheaper is V4.1 Flash?

On unit prices, the answer is unambiguous. V4.1 Flash is cheaper across cached input, uncached input and output. The calculation becomes more useful when those categories are put back together into an actual workload rather than treated as interchangeable discounts.

The following figures are official DeepSeek prices in USD per million tokens. Tokens are the units used to process and bill model input and output; they are not the same as words.

Peak-rate category	V4.1 Flash	V4 Pro 0813
Cached input	$0.006	$0.044
Uncached input	$0.30	$1.32
Output	$1.20	$3.96

The official table separates cached input, uncached input and output. Flash supports vision; both columns list the same context and maximum output limits.

Consider a hypothetical document-processing batch with one million uncached input tokens and 200,000 output tokens. Flash would cost $0.30 + 0.2 × $1.20 = $0.54. Pro would cost $1.32 + 0.2 × $3.96 = $2.112. At identical usage, Flash is about 74.4% cheaper. These are calculations from the price table, not measured bills or SandBase prices.

For a budget that repeats that batch every day for 30 days, the corresponding totals are $16.20 and $63.36. That is enough information to estimate this particular workload, but not enough to predict every application’s savings. A model that produces longer reasoning or requires more retries changes the token count; a task that ends correctly on its first attempt changes it in the other direction.

Caching changes the mix again. Suppose the same one-million-token input is entirely billed as a cache hit, with the output unchanged. The calculation becomes $0.246 for Flash and $0.836 for Pro. The saving is about 70.6%, not 74.4%. This is a deliberately simplified accounting example: an application should use its returned cache-hit usage, not assume that every repeated instruction qualifies.

Time matters too. The official off-peak rates are half the peak rates. Peak windows run Monday to Friday at 01:00–04:00 and 06:00–10:00 UTC, equivalent to 09:00–12:00 and 14:00–18:00 in Beijing. An overnight reporting job may have scheduling freedom; a support assistant answering a customer does not. Cheap capacity is useful only if the work can wait.

The price case for Flash is strong without overstating it. Its rates give a new integration more room to spend on long answers and repeated tasks. They do not establish how many correct tasks it completes per dollar. That second number needs task outcomes as well as billing data.

Image input changes the job, not just the specification

The visible capability difference is image input. V4.1 Flash supports it; V4 Pro 0813 does not in the current official table. Both list tool calls, JSON output, Responses API support and Anthropic API support. Those shared features are useful, but they should not be advertised as exclusive reasons to choose the new version.

A support engineer investigating a screenshot illustrates the difference. With a text-only model, the application might first extract the words through optical character recognition, or OCR, then pass that transcription to the model. Image input lets Flash receive the screenshot and the question together, including visual relationships that plain extracted text may omit. That creates a possible simpler path, not a demonstrated guarantee of accurate reading.

A financial table is a harder example. Reading “12.5” is not enough if the model attaches it to the wrong row or misses that the units are thousands. The vision documentation explains why merely uploading a larger screenshot is not a complete solution. With detail: low, the image is downscaled to 512 × 512 before inference.

Low detail reduces the image to 512 × 512. The later token-usage section also describes resizing for larger images and a 1,024-token upper bound per image.

Selecting original does not remove every processing limit. The same document says larger images are resized, preserving their aspect ratio, to a total pixel count roughly equivalent to 1300 × 1300. The upper bound is 1,024 image tokens per image. A long screenshot of an entire report can therefore lose small lettering even when its source file looks excellent on a monitor.

For dense tables, a reasonable evaluation should compare a full-page image with clear section crops that preserve column headings, units and relevant notes. More crops can preserve detail, but each image is counted separately; the extra context is not free. This is a testing recommendation, not a reported accuracy improvement. The documentation supports JPEG, PNG, GIF and WebP, so the first question is usually what the image preserves, not which common file extension it uses.

The benefit is most concrete for applications that currently split visual input and text analysis into separate stages. Flash may let them simplify that arrangement. For a text-only coding assistant, vision has little immediate value, and output correctness remains the more important comparison.

What still makes Pro worth keeping?

DeepSeek says its internal testing found V4.1 Flash ahead of V4 Pro in performance, cost, speed and total time. That is the provider’s stated reason for the planned retirement. The pricing page does not provide the task-by-task records needed to turn that statement into an independently reproducible benchmark, so it cannot settle whether Flash handles a particular codebase better.

There is nevertheless a defensible reason to preserve a confirmed older version for a while: an existing application may already have accepted outputs against it. A code-review tool might depend on a strict response schema. A document extractor may have a collection of invoices with known troublesome fields. Those previous results are useful comparison material, even when the old model is no longer the best choice for new work.

That is a case for a dated baseline, not for paying more out of habit. In the official hosted API, the announced retirement limits how long Pro can serve that role. An application that requires an immutable version should establish an explicit version commitment from its provider instead of treating an unversioned name as one.

For readers buying through another platform, check that platform separately. The DeepSeek V4 Pro listing on SandBase is the relevant model page to consult for that route; its existence does not prove that DeepSeek’s official switching schedule or prices apply there. This comparison does not claim a verified SandBase V4.1 Flash integration. The distinction matters most when an apparently identical model name is being used to compare invoices or reproduce a result.

For a new document application, Flash is the sensible model to evaluate first: the documented price advantage and visual input are concrete. For a working Pro-based application, preserve the troublesome examples and their accepted answers, then check them against Flash before changing assumptions about output. The practical question is whether the replacement still delivers the fields, code or decisions the application needs, not whether “Pro” sounds like a safer label.

FAQ

Is DeepSeek V4.1 Flash cheaper than V4 Pro?

Yes, at the official prices checked on September 10. Peak uncached input is $0.30 versus $1.32 per million tokens, and output is $1.20 versus $3.96. The percentage saving depends on the input/output/cache mix; the equal-usage document example above gives 74.4%, not a universal discount on every workload.

Can I still call the original V4 Flash model?

Not by retaining the legacy name on the official API. deepseek-v4-flash and deepseek-v4-flash-vision-exp remain accepted but now route to V4.1 Flash. Comparing those names with deepseek-flash does not establish a comparison between generations.

When will V4 Pro requests switch to V4.1 Flash?

DeepSeek’s published plan specifies September 14, 2026, at 12:00 Beijing time, until V4.1 Pro is released. That is 04:00 UTC. This is the official API schedule; third-party routes require separate confirmation.

Does V4.1 Flash have a larger context window than V4 Pro?

No difference is listed in the current table: both have 1M context and a maximum 384K output. These are published limits, not proof that either model reliably uses every detail in a million-token input. For screenshot-heavy work, the image-resizing rules can matter long before the text context window is full.

The useful lesson from this release is that a model comparison needs a date as well as two names. Flash’s lower prices and image support are reasons to move an evaluation forward now. Keeping an old identifier in the configuration is not a way to postpone the underlying change.