DeepSeek V4.1 Flash vs V4 Pro: What Actually Changed?

Which versions are you actually comparing?

The hosted API comparison is V4.1 Flash against V4-Pro-0813. DeepSeek's change log recommends deepseek-flash; the older deepseek-v4-flash and deepseek-v4-flash-vision-exp names now route to V4.1 Flash. Neither alias gives you the previous Flash model for a before-and-after test.

The September 10 announcement originally described a September 14 Pro phase-out. The change log contains a subsequent decision to continue Pro, and the operational pricing table still lists deepseek-v4-pro separately. Checked October 7, 2026: there is no documented requirement to move an existing Pro route to Flash.

Record the provider, requested model name, response model field, configuration, and test date. A response that repeats an alias does not independently prove the underlying weights. If your gateway overrides model names or settings, retain its effective configuration too. This prevents a test labeled "old Flash versus new Flash" from unknowingly calling the same service twice.

These are the limits and features in the official API table, not measured speed or reliability. The shared context limit does not establish equal retrieval accuracy; the concurrency allowance does not establish requests per second. The prices below apply to DeepSeek's own API, not a reseller or the consumer chat interface.

What changed in the architecture?

DeepSeek's model card describes V4.1 Flash as a 552B-backbone mixture-of-experts model with a Causal Encoder-Decoder architecture. Its 40 layers split into a 20-layer encoder and a 20-layer decoder, with 8B parameters active per input token during prefill and 16B during generation. The original V4 Pro specification is 1.6T total parameters and 49B active per token.

The launch material reports a global KV-cache footprint about one quarter of the previous V4 Flash and persistent cache storage about one eighth. Those ratios compare generations of Flash; they are not a measured Flash-versus-Pro hardware requirement. They help explain the emphasis on serving long inputs economically. They do not give an API user a latency guarantee or imply that a 552B model fits on a laptop.

For a repository agent, input processing and answer generation are different parts of the bill and waiting time. A request can read a large codebase and return a short patch, or read a short question and spend heavily on reasoning. Record input and output usage separately before deciding whether the architectural change benefits your workload.

Where Flash leads, and where Pro still leads

The official V4.1 model card reports the following results for the models that respond to user instructions. These are DeepSeek's measurements; Grow AI Skills has not run a live comparison of the two models.

Pass@1 estimates success on a single attempt; "resolved" records repository tasks completed under the benchmark's checks. NL2Repo uses its own score. Compare the two models within a row. The model card uses maximum reasoning effort for V4.1 and names the agent software and environment surrounding the model, often called its scaffold. DeepSWE is 74.2 with mini-SWE and 65.6 with Codex, so the surrounding software can affect the result. The change log lists NL2Repo at 65.4; this table uses the model card's 64.0 consistently.

A repository repair involves finding files, running commands, inspecting failures, and finishing the change. A difficult question answered from text alone exercises a different workflow. The reported agent leads justify starting a coding-agent trial with Flash; the reasoning leads justify retaining Pro for hard text questions. Check the work your users need completed before transferring either conclusion to your application.

Do not average these rows into one overall winner. They use different datasets and metrics, and the HLE text-only subset must stay separate from the full multimodal set. A small numerical lead also lacks an uncertainty estimate here. Use the rows to choose relevant tests, then judge the outputs against your own expected answers.

Choose by the work you need to finish

The following are suggested evaluation cases, not observed results from our model runs. Pick the cases that resemble your application; a short JSON classifier does not need the same trial as an autonomous repository agent.

Repository fixes and terminal agents

Start with Flash for a new coding agent because the reported repository and terminal results favor it. Compare complete runs from the same clean repository snapshot, with identical tools, dependencies, permissions, and effort. A model that writes a plausible patch but never runs the required command has not completed the task.

Include a bug with an existing regression test, a change that touches two modules, and a task where a requested dependency is unavailable. Check that the agent reads the relevant implementation, changes only allowed files, preserves existing behavior, and reports a failed test accurately. Inspect the final diff and test output rather than grading the explanation alone.

Keep Pro on a narrow route if repeated paired runs show it solves a costly class of failures that Flash misses. A security-themed benchmark lead is insufficient evidence to let either model approve a security fix without review. If the trouble is missing repository access or a broken tool, changing models will not repair the environment.

Difficult reasoning from text

Retain Pro in the comparison for multi-step reasoning where an incorrect conclusion creates substantial review work. Its GPQA and text-only HLE leads are relevant reasons to test it, not proof that it is better at every analytical task. Run both models with the same explicit effort and check the answer against a known solution or a qualified reviewer.

Useful cases include a calculation with a unit conversion, a decision that depends on an exception clause, and a question whose supplied information is insufficient. Require the final answer to preserve the unit, apply the exception, or identify the missing input. A long explanation should not receive extra credit when its conclusion is wrong.

If both models pass, compare cost and waiting time. If only Pro passes, check that the result repeats on related cases before paying the premium across all traffic. If neither passes, narrow the task or add a deterministic calculation and source check; max effort is not evidence that an answer is correct.

Writing, editing, and translation

For text work that a person reviews before publishing, Flash is a reasonable first candidate because its token prices are lower. The reasoning and coding benchmarks do not establish a winner for English style, Chinese-to-English translation, or preserving a particular writer's voice. Compare both models on the language pair and kind of document you actually use. Keep Pro only if its drafts save enough editing work to justify the extra cost.

For example, ask both models to shorten a support message that promises a refund only before dispatch. Require the rewritten text to keep that condition, the order number, and the refund amount. For translation, supply a terminology list and include a sentence with a negation or exception. Have a reader of the target language check meaning and natural phrasing. Record factual changes separately from awkward prose: an elegant translation that reverses "not eligible" is unusable.

Screenshots, charts, and scanned pages

Flash is the direct option when the request includes images. Pro needs a separate OCR or vision stage followed by text input. Compare those complete pipelines when deciding whether to replace an existing OCR-plus-Pro workflow: include preprocessing cost, lost layout information, and any review step.

For Chat Completions, the vision guide places an image_url block inside a user message alongside text. It accepts public URLs, inline base64, or uploaded file references. Image input in system or assistant messages produces a 400 error. Inline request bodies are limited to 48 MiB. For image URL inputs, detail: low downsizes to 512 by 512; use original when small labels matter, while still checking the returned reading.

A useful screenshot trial asks for the exact error text and the control associated with it. A chart trial asks for the axis units and a value from a labeled series. Include an unreadable crop and require an explicit "cannot read" response. Guessing a blurred account number or chart label is a failure even if the prose sounds confident.

When a full-page scan hides small text, try a labeled crop that preserves the surrounding heading and page number. Compare the crop and full page against a human transcription. Avoid judging Flash's reading against a Pro response that received a cleaner transcription: that would also test the preprocessing difference.

Invoice extraction and other structured output

Start with Flash for a trial that turns text or page images into structured records. Both API models support JSON output; Flash also accepts the source image directly. Include a missing invoice number, an ambiguous date, a credit note with a negative amount, and a page with two currencies. Define whether each missing field must be null or trigger review before generating.

DeepSeek's JSON guide requires response_format: {"type": "json_object"}, an instruction containing "json", and a suitable output budget. It documents occasional empty content. JSON parsing is only the first check: validate field types, required keys, allowed values, and agreement with the source. Valid JSON containing the wrong total is a failed extraction.

Keep retries visible. An empty answer, a truncated object, and a wrong currency need different handling. Retry an empty response under a capped policy, adjust a budget that is demonstrably too small, and send unresolved source ambiguity to review. Pro is a possible alternative for difficult text extraction if paired results support it; it cannot inspect the original image directly.

Add a missing-value case to the example request below: "Credit note CN-7. Credit EUR 27.50. No USD total is supplied." Tell the model to return null when no USD total is stated. The required fields are invoice_id: "CN-7" and total_usd: null; converting the EUR credit to USD without a supplied exchange rate fails the check. This is a proposed test input and expected answer, not an observed model result.

Long documents and retrieval

Both models advertise 1M context, so choose on retrieval and evidence use at the length you actually send. Build a document case with a current rule near the beginning, an obsolete rule in the middle, and an exception near the end. Ask which rule applies and require the relevant section IDs. Add a question the document does not answer.

Check whether the model chooses the current rule, preserves the exception, and distinguishes absence from contradiction. Repeat with the passages in different positions. These checks expose failures that a successful one-line lookup can miss. A polished summary that drops the exception may be unusable even when it fits the output schema.

For repeated questions over the same documents, Flash's prices make it an attractive first trial, but inspect actual cache usage. If the full-context approach repeatedly overlooks evidence, compare a smaller retrieved passage set with the same acceptance rules. More input is useful only when the model uses it correctly; retrieval design can matter more than the Flash-versus-Pro choice.

Interactive chat and large batches

For simple classification, rewriting, or routing tasks, compare non-thinking mode or low effort before defaulting to max. Decide what the user is waiting for: the first final-answer text, a validated JSON object, or a completed tool action. Reasoning tokens appearing on a stream do not satisfy a user who still lacks the answer.

For batch workloads, measure completed, accepted jobs per unit of time. DeepSeek's rate-limit guide counts concurrency across an account's API keys, with a connection occupying capacity until its response completes. Exceeding the limit returns HTTP 429. Creating another key in the same account does not increase the allowance.

Use a bounded worker queue, record throttled requests, and cap retries with backoff. Compare cold requests separately from repeated-prefix requests. If Flash finishes more jobs cheaply but misses your completion deadline on a difficult category, keep that category separate in the decision. An average over easy batch jobs can hide the category your users depend on.

Price the request mix you actually send

The pricing table, checked October 7, quotes US dollars per million tokens. On a narrow screen, scroll the table sideways to see every column.

Peak hours are 01:00 to 04:00 and 06:00 to 10:00 UTC, Monday through Friday, excluding Chinese public holidays. Weekends and those holidays are off-peak throughout. In China Standard Time, the windows are 09:00 to 12:00 and 14:00 to 18:00. Recheck the linked pricing table before scheduling a batch.

These illustrative token mixes use off-peak rates, identical usage for both models, and no measured acceptance-rate assumption:

request_cost = (cache_hit_tokens * hit_rate
              + cache_miss_tokens * miss_rate
              + output_tokens * output_rate) / 1_000_000

model_cost_per_accepted_task = total_model_spend / accepted_tasks

An accepted task is one whose completed output passes the checks you wrote for it. Include unsuccessful attempts and retries in total spend. If your trial contains 100 jobs but only 80 pass, divide by 80. For an agent job, first add the costs of every model call needed to finish that job.

The large agent example makes Flash about 72.1% cheaper at equal usage. Peak prices double both totals. Actual model runs can use different output lengths, tool turns, or retries; recalculate from returned usage rather than assuming that percentage applies to your application.

For an illustrative acceptance adjustment, suppose that example's mean attempt cost stayed fixed and Flash accepted 80% of attempts while Pro accepted 95%. The model costs per accepted task would be $0.09525 and about $0.28716. Those acceptance rates are assumptions, not benchmark results. A task with no accepted outputs has no meaningful finite cost per accepted task.

To decide whether Pro's premium pays for itself, add the review and repair work that the API bill excludes. In the same illustrative case, the extra Pro attempt costs $0.1966. If it really prevented 0.15 more failures per attempt, the break-even cost per avoided failure would be about $1.31. Measure that quality difference and failure cost in your workflow before using this threshold. Count escalation calls and repeated work in the route's total spend.

Why an expected cache discount may not appear

The context-caching guide says caching is automatic but best effort. A hit requires a full match to a persisted prefix unit. Reusing a document somewhere in a prompt is insufficient if the earlier content changes. With requests shaped as A+B and A+C, the shared A prefix may only be persisted after detection, so the second request need not receive the discount you expected.

Put stable instructions and source content before the changing question where the task permits it. Avoid inserting a fresh timestamp ahead of a reusable prefix. Preserve the content order and version in your test log. Confirm the result with usage.prompt_cache_hit_tokens and usage.prompt_cache_miss_tokens; report the observed hit fraction rather than labeling every repeated document "cached".

Separate the first run from warm runs when reporting latency and cost. An application that sees a document once may receive little benefit from a warm-cache benchmark. A support workflow that repeatedly uses the same policy may benefit much more, provided its requests preserve the reusable prefix.

Configure a comparison without hidden defaults

The thinking-mode guide defaults to enabled thinking at high effort. For hosted Chat Completions, use low, high, or max explicitly. Compatibility values medium and xhigh map to high. The open-weight model card's numeric 1 to 100 effort scale is a separate interface.

In thinking mode, temperature, presence_penalty, and frequency_penalty have no effect. top_p does affect thinking-mode sampling in the 0.95 to 1.0 range; lower values map to 0.95. In non-thinking mode it is fixed at 1.0. Setting temperature to zero therefore does not make a thinking-mode comparison deterministic.

Save the following body as request.json to check a text extraction request. It gives both models the same source and output instructions. This simple case checks whether the integration works; include the missing-value case above before judging extraction quality.

{
  "model": "deepseek-flash",
  "thinking": {"type": "enabled"},
  "reasoning_effort": "high",
  "top_p": 0.95,
  "max_tokens": 4096,
  "response_format": {"type": "json_object"},
  "messages": [
    {
      "role": "system",
      "content": "Return only JSON with keys invoice_id and total_usd. Preserve the supplied ID and USD total. If no USD total is explicitly stated, set total_usd to null. Do not convert currencies. Example: {\"invoice_id\":\"INV-1\",\"total_usd\":12.5}."
    },
    {
      "role": "user",
      "content": "Invoice INV-42. Total USD 125.50."
    }
  ]
}

With your API key set in the DEEPSEEK_API_KEY environment variable, send the request from a terminal. This makes a billed API call and saves the response locally:

curl --silent --show-error --fail-with-body --max-time 120 \
  https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \
  --data-binary @request.json \
  --output flash-response.json

Check that the key is set before running it. For the Pro comparison, change only the model in request.json to deepseek-v4-pro and save the second response as pro-response.json. Keep the first response. If curl reports a timeout or HTTP error, record that outcome separately; a failed request is not a generated answer. The 120-second timeout is a limit for this example, not a promise about either model's speed.

The saved file contains the complete API response. Read choices[0].message.content, then parse that text as JSON; the invoice fields are not at the top level of the saved file. The expected fields are invoice_id: "INV-42" and numeric total_usd: 125.5. Check exact values and types, and record an empty content field as an empty-output failure before parsing. Keep usage and finish_reason from the surrounding response for the cost and truncation checks below.

For a non-thinking comparison, set thinking.type to disabled and omit reasoning_effort for both models; hold that condition separate from high or max trials. With the OpenAI Python SDK, DeepSeek's custom thinking field belongs inside extra_body.

Keep the same messages, tool schemas, permissions, output budget, and request format for each paired condition. First compare models at the same effort. You can then compare a low-effort Flash route against a high-effort Pro route as two production configurations, reporting the settings and outcomes together.

Allow room for the answer when budgeting a long request. The API reference limits input plus generated tokens to the context length: a 1M context and 384K output ceiling do not let you send 1M input tokens and then append 384K output tokens. Check the actual input usage and reserve an output budget suited to the task.

What to retain from each response

The Chat Completions reference returns the model, request ID, finish reason, and token usage, including completion_tokens and optional reasoning-token detail. Retain the raw usage object and calculate output charges from the total completion usage, without adding its reasoning-token detail a second time. For multi-call agents, sum usage across every model request.

Record wall time, time to first final-answer content, retry count, tool calls, and the acceptance result alongside those fields. Treat finish_reason: "length" as a signal to inspect truncation, not a complete answer. A tool-call response also requires the tool execution and subsequent completion before you can score the user's task.

For thinking-mode Chat Completions carrying tools, preserve the assistant's reasoning_content in subsequent requests. DeepSeek documents a 400 error when required reasoning history is omitted. A wrapper that strips that field can break the loop on either model; diagnose the integration before calling it a model-quality regression.

Move an existing Pro application in stages

Start with a small representative set, perhaps 20 to 50 tasks, to expose obvious incompatibilities. That is an initial screen, not evidence about rare failures. Include your known Pro failures, previously fixed regressions, long inputs, ambiguous sources, and tasks where the correct outcome is to stop or request missing information. Repeat important cases because one generation can be misleading.

1. Write acceptance rules before the trial. For the invoice example, require exact ID, amount, currency, and schema. For a repository task, require the expected behavior, passing regression tests, and an allowed diff. Decide which errors block release regardless of the average.
2. Alternate Flash and Pro runs using separate clean task state. Reset tool environments so one model cannot benefit from the other's patch. Keep image tasks separate from matched text tasks; if Pro uses OCR, label and measure that complete pipeline.
3. Record failures by cause: request configuration, retrieval, source reading, reasoning, tool action, truncation, and throttling. A lower score caused by a missing reasoning field needs an integration fix; a wrong answer on an identical valid request belongs in the quality comparison.
4. Compare acceptance, latency distribution, model spend, and review work by task category. Define the maximum wait, retry allowance, and review capacity from your application requirements. Keep blocked cases visible even when their category has a good average.
5. Run Flash on copies of real requests while Pro continues to handle users, and prevent the copied runs from taking real tool actions. Once their outputs pass your checks, send a small share of live requests to Flash with a switch back to Pro. Increase that share only when the same difficult cases still pass and waiting time stays within your requirements.

You can also send routine requests to Flash and keep Pro for a defined group of text tasks. Trigger a second attempt because a schema check failed, the source contains an unresolved contradiction, or your saved cases show that Pro handles this task better. A model's own confidence does not prove its answer is correct.

Keep escalation bounded. Permit a limited number of attempts, preserve the original source and failure reason, and avoid repeating a completed tool action. An image-reading failure needs a clearer image, OCR, or human review before text-only Pro can help. Count the Flash attempt, Pro escalation, and any preprocessing in the combined cost.

Diagnose these failures before changing models

For a fuller regression-set design, use the AI evaluation-set guide. If you want to evaluate through DeepSeek Harness, follow the separate Harness installation guide; installing an agent environment adds its own setup and permission decisions to the model comparison.

Questions the API comparison does not settle

Will switching the model make my agent faster?

It may, but the parameter counts and concurrency allowances cannot tell you how long your complete task will take. Time the same valid task with matched effort, separate queue waiting from useful output where your client exposes it, and retain slow runs. A lower per-token price can coexist with more generated tokens or more tool turns.

Does this describe the DeepSeek app or a third-party provider?

The model IDs, settings, and dollar estimates here describe DeepSeek's hosted API. A chat interface or reseller can use different routing, features, limits, and billing. Confirm the provider's actual endpoint and model mapping before applying this comparison to it.

Can I self-host V4.1 Flash?

The official weights use the MIT License and have inference guidance, but this is still a 552B-backbone model. Sparse activation reduces work per token; it does not remove the need to store and serve the weights. Obtain a deployment estimate for your quantization, hardware, context length, and throughput before comparing self-hosting cost with these API rates.

Does choosing Pro change how my data is handled?

Both model names in this comparison call DeepSeek's hosted API. A quality or price advantage does not establish a different retention, training-use, or hosting policy. For sensitive documents, check the Open Platform terms, the policy applying to your account and region, and whether your organization permits that service. The MIT license for downloadable weights does not describe how a hosted provider handles uploaded data. Treat an approved provider and an acceptable model output as separate requirements.

When should I keep Pro?

Keep it for a defined text workload when repeated paired tests show that the extra accepted work or avoided review cost exceeds the premium. Save the failing Flash cases and the acceptance rule that Pro satisfies. Re-run those cases when the provider changes versions or routing so the decision remains attached to the behavior you need.