DeepSeek V4 Pro vs V4.1 Flash: Features and API Cost

As of September 23, 2026, the useful official-API comparison is V4.1 Flash versus V4 Pro, rather than the two original V4 preview models. Flash has moved to a newer generation; Pro remains available. The name “Pro” alone does not establish which model will do a particular job better.

For a new image-based integration, Flash is the candidate to evaluate because the current official model table lists vision support for Flash and not Pro. For an established text workflow, compare the cost of completed tasks and the outputs you can actually use before switching.

This guide is for developers and teams choosing a service. It uses official capability and pricing documentation checked on September 23. It contains a worked cost example and a suggested evaluation method, not fabricated latency measurements or a claim that we tested both models in a particular chat product.

Start with the current model mapping

The official model table identifies deepseek-flash as V4.1 Flash and deepseek-v4-pro as V4-Pro-0813. Both list a 1M context window, thinking and non-thinking modes, JSON output, tool calls, Responses API support, and Anthropic-compatible API support.

The legacy Flash names now route to V4.1 Flash. That matters when reading older comparisons: a recent test using deepseek-v4-flash may no longer involve the original V4 Flash. Look for the test date and service mapping before interpreting the result.

Shared features do not make the models interchangeable. An application may rely on a particular response structure, a tool-selection habit, or a prompt that has been tuned against one model. Keep those dependencies visible in the comparison instead of assuming the larger or newer name settles them.

Pro is still available despite the older announcement

The September 10 launch announcement described a plan to route Pro requests to Flash from September 14. The current change log instead says V4 Pro API service will continue after that date with its billing method unchanged.

The current price table also lists Pro separately. Those are the relevant documents for today's selection. The original announcement explains why users may have heard that Pro was going away, but it should not be repeated as the current service status.

If you already have a working Pro integration, use the continued availability to run a controlled comparison. Retaining it can be reasonable when changing a validated workflow would create more work than the immediate savings justify. That is a deployment decision, not evidence of superior model quality.

Start using deepseek-v4

The price difference is measurable

The following official API rates are in US dollars per one million tokens. They are a September 23 snapshot, not prices for a third-party chat subscription.

Token category	V4.1 Flash, peak	V4 Pro, peak	V4.1 Flash, off-peak	V4 Pro, off-peak
Input, cache hit	$0.006	$0.044	$0.003	$0.022
Input, cache miss	$0.30	$1.32	$0.15	$0.66
Output	$1.20	$3.96	$0.60	$1.98

Peak hours are 01:00–04:00 and 06:00–10:00 UTC on weekdays, excluding Chinese public holidays. All other hours are off-peak. In Beijing time, those windows are 09:00–12:00 and 14:00–18:00. See the live pricing page before budgeting a future workload.

Consider a hypothetical batch that uses 100,000 uncached input tokens and 10,000 billable output tokens. At peak rates, Flash costs 0.1 × $0.30 + 0.01 × $1.20 = $0.042. Pro costs 0.1 × $1.32 + 0.01 × $3.96 = $0.1716. The respective off-peak totals are $0.021 and $0.0858.

That calculation assumes identical token usage, no cache hits, and no retries. It is not a measured invoice. In real work, models may produce different amounts of output or need different numbers of attempts. Use actual usage records, including billable reasoning output where applicable, rather than estimating cost from the length of the final paragraph alone.

Vision and file handling are separate layers

For screenshots and charts sent directly to the official API, Flash supports image input. The Vision documentation describes the accepted formats and request shapes. Pro's current official API entry does not include vision.

A web product may still let a user attach a document while using a text model. It could extract text first, route the attachment to another service, or restrict the accepted files. That behavior belongs to the product. It cannot be inferred from the model's name or from an upload button alone.

When evaluating a document workflow, ask what reaches the model. Is it page images, extracted text, or both? A table that loses its columns during extraction may produce a poor answer even if the model handles clean text well. Test the complete path from original file to final answer.

Use a task sheet instead of a general ranking

Choose several representative tasks and write an acceptance condition for each. For support-ticket extraction, all required fields must match the source. For a code edit, the requested behavior and relevant tests must pass. For a summary, key statements should be traceable to the supplied document.

Keep the provider, prompt, tool access, and output budget consistent. Set thinking behavior explicitly rather than relying on defaults. For each result, record whether it passed, how much manual correction it needed, and the total cost including retries. Measure speed with the same definition, such as time to a usable final answer.

Avoid declaring a winner after a single easy question. Include missing information, awkward formatting, and a task where the correct response is to ask for clarification. These cases often reveal the amount of supervision your application will need more clearly than a polished answer to a familiar prompt.

For an agent, inspect the actions as well as the final prose. A convincing explanation cannot repair an incorrect file change. Tool permission, session memory, and task scheduling also depend on the host, so a model comparison should not credit or blame the model for every host-level behavior.

A practical choice for each situation

Start by evaluating Flash when building a new image workflow or reducing the cost of a repeated task. Its documented feature set and lower token rates make it a useful baseline. Keep Pro in the comparison if it already meets your acceptance criteria or produces outputs your team prefers after a controlled review.

For browser chat, confirm the exact models and features offered by the service you use. Official API limits and prices do not automatically apply to that interface. For API code, follow the migration guide before changing an alias or thinking setting.

Keep the resulting decision small and specific: which model, on which service, for which task, with what evidence. That record remains useful when the next release changes the available choices.