DeepSeek v4 vs v4.1 Flash: Performance & Cost Guide

TL;DR: As of September 11, 2026, DeepSeek lists deepseek-flash as V4.1 Flash and deepseek-v4-pro as V4 Pro 0813, both with 1M context. Flash has lower listed token rates; compare cache hits, cache misses, output, and UTC pricing periods separately. No independent speed or accuracy benchmark was run for this guide.

Key Takeaways

• The current comparison is V4.1 Flash versus V4 Pro 0813, not the original V4 previews or the retired V4 Flash model.
• The official pricing table lists 1M context and a maximum 384K output for both models. A limit is not a guarantee of useful output at that length.
• Flash supports native vision; the current Pro row lists vision as unsupported. Both list tool calls and thinking/non-thinking modes.
• Token rates depend on cache status and peak/off-peak hours. The cost examples below use stated token volumes and do not assume equivalent answer quality.
• September 10 pricing is already effective. The original September 14 Pro rerouting announcement is future-dated and conflicts with the current notice that Pro service and billing will continue.
• The previous article's precise benchmark, latency, throughput, parameter-estimate, competitor-price, and uptime tables lacked adequate supporting evidence and are not used here.

Which DeepSeek models does this comparison cover?

The official Models & Pricing page and API quickstart were checked on September 11, 2026. Their current model mapping is:

Release dates come from the September 10 Flash announcement and August 13 Pro GA announcement. The model-family label “v4” alone is not enough to identify the backend version used in a comparison.

The current quickstart says the older aliases deepseek-v4-flash and deepseek-v4-flash-vision-exp are temporarily routed to V4.1 Flash because their previous models have been retired. Use the documented deepseek-flash identifier for a new integration. The old examples deepseek-chat-v4 and deepseek-chat-v4.1-flash are not the identifiers documented for these models.

The Flash release describes a new asymmetric MoE architecture. It does not support the previous article's description of an estimated 80–120B distilled Pro variant. This guide does not infer parameter counts from latency or use architecture labels to predict application accuracy.

What has already changed, and what does September 14 mean?

The distinction matters when a model alias can outlive the model it originally named.

Both notices remain readable in official sources: the original announcement and the current pricing page, changelog, and quickstart. This comparison uses the currently listed Pro model and Pro rates. Recheck the active notice before a September 14 cutover; do not automatically replace Pro rates with Flash rates in a forecast.

These are documentation observations. No API request was made to measure or independently verify backend routing for this article. Record the request model, response metadata, date, and applicable rate schedule in an actual deployment test.

What are the current token prices and billing periods?

The following rates are copied from the official pricing table checked September 11, 2026. Amounts are US dollars per one million tokens, separated by usage category.

Peak hours are 01:00–04:00 and 06:00–10:00 UTC, Monday through Friday. All other hours are off-peak. The official schedule makes each off-peak rate half of its corresponding peak rate. Use UTC when scheduling; a local business-hours assumption is insufficient.

Flash's listed rate is lower in each corresponding category. That does not establish one universal percentage reduction in a completed task's cost: input/output proportions, cache hits, generated reasoning, retries, and task completion can differ. The previous flat $0.14/$0.42 versus $0.36/$1.08 table is not the current schedule.

How should you calculate cost for a real workload?

Keep cache-hit input, cache-miss input, and billed output as separate quantities. For each model and tariff period:

Sum the applicable periods and models afterward. Do not multiply all input tokens by the cache-miss rate and then add cache-hit tokens again. DeepSeek's context-caching guide documents prompt_cache_hit_tokens and prompt_cache_miss_tokens in response usage and describes caching as best-effort, not a guaranteed hit rate.

What do the original workload examples cost at the corrected rates?

Illustrative arithmetic, not measured usage or a benchmark: each request below makes one model call, all input is a cache miss, and each scenario uses a single tariff period. Output counts mean billed output tokens, not just the visible final answer. There are no retries, extra model/tool calls, taxes, hosting charges, or volume discounts in these examples. Token volumes are deliberately held equal across models; actual outputs may differ.

For the support scenario, the off-peak calculations are:

The original code-completion example of 2M requests × 400 input and 100 output tokens has the same aggregate token volume as the support scenario, so it has the same modeled charge under these assumptions. That is an arithmetic equivalence, not evidence of identical application behavior.

How does caching change that example?

As a separate hypothetical case, suppose the support workload reports 600M cache-hit input tokens, 200M cache-miss input tokens, and 200M billed output tokens, all off-peak:

The assumed cache-hit share is not a promised production hit rate. Inspect actual usage fields and retain failed/retried calls when estimating the cost per completed task. For the wider distinction between cache-rate discounts and total application savings, see Context Engineering.

What can the official performance claims establish?

The September 10 announcement claims improvements over V4 Pro in performance, cost, speed, and total runtime. The changelog also reports vendor benchmark results. These are DeepSeek-reported results, not experiments performed for this guide.

The previous MMLU, GPQA, HumanEval, GSM8K, MATH-500, WebArena, 87ms/201ms latency, and 142/78 tokens-per-second comparisons are removed because their exact values and evaluation conditions were not supported by the retrieved primary evidence. This guide does not replace them with guessed scores or turn the release's qualitative speed claim into a measured multiplier.

Do not construct a new head-to-head by matching benchmark names across announcements without checking versions, task sets, harnesses, tool access, reasoning effort, sampling settings, and scoring. For example, the current changelog names different generations of some agent benchmarks across releases. A result on one does not automatically measure improvement on another.

The old Qwen, ERNIE, and GLM price/score tables are also outside this verified comparison. The evidence here covers the two currently listed DeepSeek API offerings, not a ranking of all Chinese model providers.

What should you verify before migrating an agent?

Use the API quickstart for the documented endpoint and model names. This is an unexecuted request example; running it requires a valid key and incurs API usage:

For a Pro comparison, the documented request identifier is deepseek-v4-pro. Keep the task, mode, input evidence, and success criteria aligned. Changing a model string does not establish equivalent tool behavior, output quality, context use, or billing.

The thinking-mode guide documents thinking as enabled by default and describes mode/effort controls. It also requires retaining reasoning_content in subsequent requests carrying tools. Test your actual multi-turn tool transcript; do not assume an older integration preserves the required fields.

These are proposed checks; they were not run for this article. Use the observability guide to preserve evidence and the framework comparison to decide which component owns state and retries.

What limits and availability assumptions should you use?

The current rate-limit documentation lists default account-level concurrency limits of 2,500 for Flash and 500 for Pro. A request occupies a concurrent connection until its response completes, and exceeding concurrency produces HTTP 429. These are not requests-per-minute tiers or a throughput benchmark.

The earlier free/standard daily-token tiers and 99.7% measured uptime claim are removed. They were not substantiated by the official sources reviewed here. Configure bounded retries, cancellation, and fallback based on the actual errors and service contract rather than an invented availability percentage.

FAQ

Which model names should I use on September 11, 2026?

The official quickstart lists deepseek-flash for V4.1 Flash and deepseek-v4-pro for V4 Pro. The retired Flash aliases currently map to V4.1 Flash. The original future Pro-rerouting announcement conflicts with the current continuation notice, as explained above.

Do both models have a 64K context window?

No. The current official pricing table lists 1M context and maximum 384K output for both. Test the actual endpoint, request settings, and long-context task quality rather than assuming the advertised limit guarantees correct use of every token.

Is Flash always cheaper for a completed task?

Flash has lower published token rates in every corresponding category shown here. Completed-task cost also depends on token usage, cache hits, retries, reasoning, and success. The cost examples hold those quantities fixed and are not workload measurements.

Are the September 14 routing changes already effective?

No September 14 transition can be described as already effective on September 11. The original announcement scheduled Pro rerouting for September 14 at 04:00 UTC, while current pricing and changelog notices say Pro will continue afterward with billing unchanged. Recheck the active notice before making a cutover assumption.

Are general benchmark scores enough to choose a production model?

No. Vendor results need their task set, harness, model version, and evaluation settings to be interpretable. Evaluate your own representative prompts and tool workflows, record failures, and measure quality and completed-task cost together.

How should I compare model cost for my workload?

Use actual cache-hit input, cache-miss input, and billed output counts with the applicable peak/off-peak rates. Include retries and additional model calls. The worked examples are arithmetic under explicit assumptions, not measured bills or guaranteed savings.

What should I verify before changing an agent's model?

Check the current identifier and service notice, then validate the representative requests, structured outputs, streaming, tools, and state handling your application uses. Retain a tested fallback and inspect actual usage before rolling out broadly.

Sources

• DeepSeek current models, limits, and peak/off-peak prices
• DeepSeek API quickstart and current model aliases
• DeepSeek changelog and Pro continuation notice
• DeepSeek V4.1 Flash release and original September 14 schedule
• DeepSeek V4 Pro GA release
• DeepSeek concurrency limits and request handling
• DeepSeek context caching and usage fields
• DeepSeek thinking mode and tool-transcript requirements