DeepSeek V4 Pro vs Flash: API Pricing, Benchmarks, and Break-Even Cost

DeepSeek V4-Flash is the obvious winner if you compare only API prices. Under the prices DeepSeek published on August 14, 2026, Flash costs $0.14 per million uncached input tokens and $0.28 per million output tokens. V4-Pro costs $0.435 and $0.87 respectively—about 3.1× as much at identical token usage.

But an agent does not sell tokens. It sells completed work.

A model that writes the wrong patch, calls a tool with invalid arguments, or needs two retries can turn a cheap attempt into an expensive task. The useful comparison is therefore not cost per million tokens, but cost per successful agent task.

Model pricing alone does not determine agent-task cost. Tool execution, context management, retries, and session recovery are controlled by the surrounding harness. Our DeepSeek Harness guide explains how those layers work.

Bottom line: Flash should be the default for simple, bounded, high-volume work. Pro earns its premium only when its higher first-pass success rate—or fewer tool and planning failures—offsets roughly a 3× price gap. Without task-level measurements, “Flash is cheaper” and “Pro is better” are both incomplete answers.

This article is the decision and measurement companion to our DeepSeek V4 release overview. It does not repeat the launch guide. Instead, it shows how to evaluate the two models on three agent workloads and how to decide where each belongs in a production routing policy.

DeepSeek V4 Pro vs Flash: the fast decision

• Choose Flash for bounded transformations, classification, extraction, simple code edits, and high-volume jobs where retries are cheap.
• Choose Pro for longer planning chains, difficult repository changes, ambiguous requirements, or workflows where a failed attempt triggers expensive tools and human review.
• Do not compare token prices alone. Compare total tokens, tool calls, retries, latency, and accepted-task rate on the same task set.
• Break-even rule: if Pro costs about 3.1× more per identical token workload, it must deliver enough additional first-pass success—or reduce enough retries and tool waste—to overcome that multiplier.

For a clean benchmark, hold the harness, prompts, tools, context budget, stopping rules, and acceptance tests constant. Route tasks only after measuring cost per accepted result, not after comparing one polished demo from each model.

DeepSeek V4 Pro vs Flash at a glance

Question	V4-Flash	V4-Pro
Uncached input price¹	$0.14 / 1M tokens	$0.435 / 1M tokens
Output price¹	$0.28 / 1M tokens	$0.87 / 1M tokens
Cache-hit input price¹	$0.0028 / 1M tokens	$0.003625 / 1M tokens
Context window	1M tokens	1M tokens
Maximum output	384K tokens	384K tokens
Published concurrency limit	2,500	500
Active parameters²	13B	49B
Best default use	Simple, parallel, cost-sensitive tasks	Harder coding and long-horizon tasks
Real decision metric	Cost per successful task	Cost per successful task

¹ Current price displayed in the DeepSeek API documentation when this analysis was prepared on August 14, 2026. DeepSeek has announced new peak/off-peak prices effective August 16; see the pricing section below.
² Active and total parameter figures are from DeepSeek's V4 Preview announcement. Parameter count is architecture information—not a direct measurement of latency or accuracy.

DeepSeek positions Flash as the fast, economical model and says it is on par with Pro on simple agent tasks. It positions Pro for stronger agentic coding and complex reasoning. Those are first-party claims, not independent proof that the models have equal reliability on your repository and tools.

The price gap is real—but it is not the whole bill

Official GA pricing published by DeepSeek; peak and off-peak periods have different rates. Source: DeepSeek V4 Pro GA release.

At the prices displayed before the August 16 transition, a cold request with 100,000 input tokens and 10,000 output tokens costs approximately:

Model	Input cost	Output cost	Total attempt cost
V4-Flash	$0.0140	$0.0028	$0.0168
V4-Pro	$0.0435	$0.0087	$0.0522

That makes Pro 3.11× more expensive for this equal-token attempt.

Now change the unit from an attempt to a successful result. Suppose Flash completes 60 of 100 tasks on the first attempt and requires enough retries to consume 150 attempts in total. Suppose Pro completes 90 on the first attempt and consumes 110 attempts. With the same per-attempt token profile:

• Flash: 150 × $0.0168 ÷ 100 successes = $0.0252 per success
• Pro: 110 × $0.0522 ÷ 100 successes = $0.0574 per success

Pro improved reliability substantially, but Flash still won on cost. At a roughly 3.1× price premium, Pro needs an unusually large reduction in attempts or token usage to become the lower-cost option.

This is the break-even rule:

Pro is cheaper per success when:

(Pro attempt cost × Pro attempts per success)
<
(Flash attempt cost × Flash attempts per success)

If attempt costs keep the 3.1× ratio, Flash would need to consume more than 3.1× as many attempts per success before Pro wins. In practice, Pro can also reduce cost by choosing fewer tools, reading fewer irrelevant files, or producing shorter corrective turns. That is why every run needs token and tool telemetry—not just a pass/fail label.

DeepSeek's internal code-agent evaluation shows why success rate belongs in cost math; it is not a Pro-versus-Flash or Atoms benchmark. Source: DeepSeek V4 technical report, page 44.

The retry tax: where cheap models become expensive

An agent loop repeatedly feeds its own history back to the model:

1. The model reads the task, repository context, and tool definitions.
2. It chooses a tool and emits arguments.
3. The tool result enters the conversation.
4. The model reads the enlarged transcript and acts again.
5. A failed test or invalid call creates another round—or a complete retry.

Later calls can therefore be more expensive than the first. A bad early decision has a compounding cost: extra output, extra tool execution, and a larger input transcript on the recovery turn.

For each task, record:

actual task cost =
  uncached input tokens × uncached rate
+ cached input tokens × cache-hit rate
+ output tokens × output rate

Then include every attempt, including failures:

cost per successful task =
  total API cost across all attempts
  ÷ number of objectively successful tasks

A report that drops failed attempts makes an unreliable model look artificially cheap.

The three tests that reveal the difference

A useful comparison should contain work with different failure surfaces. One benchmark number cannot tell you how a model will behave in a debugging loop, a feature implementation, and a long-context planning task.

1. Fix a cross-file bug

Task: Correct a pricing defect whose behavior is split across an order module, discount module, and tests. The public API must stay stable.

Why it is revealing: The model has to trace data flow across files, distinguish the symptom from the cause, and avoid a local patch that breaks another customer type.

Objective evaluator: Hidden and visible regression tests.

Measure:

• First-pass test success
• Files read and modified
• Test runs before success
• Regressions introduced
• Invalid or unnecessary tool calls
• Total tokens and wall-clock time

A weak run often edits the most visible file without understanding the shared discount function. A strong run reads narrowly, changes the correct boundary, and passes the suite without repair turns.

2. Implement a small web feature

Task: Add server-side filtering by status and a case-insensitive query parameter while preserving the existing response shape and returning a specified 400 error for unsupported values.

Why it is revealing: Small features test instruction fidelity more than raw algorithmic ability. Models commonly miss one acceptance criterion, over-engineer the solution, or call tools with malformed arguments.

Objective evaluator: Contract tests for the old response, both filters independently, the combined filter, and the invalid-status response.

Measure:

• Acceptance criteria passed on the first attempt
• Scope of the patch
• Tool-call argument errors
• Duplicate reads or test calls
• Tokens per passing implementation
• Time to a passing suite

This is the task category where Flash has the strongest economic case. If both models pass reliably, Pro's additional capability has no opportunity to repay its price premium.

3. Read a long codebase and produce a refactor plan

Task: Inspect a notification service and write an incremental plan with concrete module boundaries, migration stages, compatibility risks, observability, tests, and rollback points. The plan must cite existing paths and must not change application files.

Why it is revealing: Planning quality depends on retrieval discipline. A model can produce polished prose while missing the actual coupling between storage, channels, worker orchestration, and API entry points.

Evaluator: A fixed rubric plus mechanical checks. Require at least five real path citations, identified boundaries, ordered migration stages, explicit risks, tests/observability, rollback points, and zero application-file changes.

Measure:

• Rubric score and pass rate
• Hallucinated paths or dependencies
• Fraction of relevant files inspected
• Premature plan generation
• Input and output tokens
• Time to an acceptable plan

Because both V4 variants support a 1M-token context window, this test should not ask only whether the repository fits. It should ask whether the model uses the context well.

These are vendor-published results; the matched-task protocol in this article is still required for a fair cost-per-success comparison. Source: DeepSeek V4 Pro GA release.

A reproducible benchmark harness

To make the comparison fair, hold these variables constant:

• Exact task prompt and repository snapshot
• System prompt and tool schemas
• Reasoning effort (high, unless testing effort as a separate variable)
• Temperature, maximum output, and timeout
• Tool implementation and execution environment
• Maximum number of agent turns and retries
• Evaluator and success threshold
• Cache condition: report cold and warm runs separately

DeepSeek's thinking-mode documentation matters here. medium, high, and xhigh do not represent three distinct actual levels in the current mapping: they resolve to high. Comparing mismatched effort settings would contaminate the model comparison.

Run each model at least three times per task; 10 or more repetitions gives a more useful reliability estimate. Preserve failed transcripts. For every run, write one structured record:

{
  "model": "deepseek-v4-flash",
  "task": "cross-file-bug",
  "success": true,
  "attempt": 1,
  "api_calls": 4,
  "tool_errors": 0,
  "latency_seconds": 18.4,
  "usage": {
    "prompt_tokens": 14230,
    "prompt_cache_hit_tokens": 8010,
    "completion_tokens": 2100
  }
}

We built a compact reference harness for these three scenarios. It creates isolated fixtures, exposes identical file and test tools to each model, saves per-run JSON, and uses tests or a fixed planning rubric as the judge. The harness validated locally; a live benchmark run could not be included because the configured DeepSeek credential returned HTTP 401. We therefore do not present fabricated “Atoms test results” in this article. The methodology and break-even analysis remain reproducible, and results should be added only after authenticated runs complete.

Metrics that matter—and the traps in each

First-pass success rate

Count a pass only when the objective evaluator succeeds before any full-task retry. Letting the model declare itself “done” is not an evaluator.

Final success rate

Apply the same retry budget to both models. Report success within one attempt and within the full budget separately; otherwise retries hide weak first-pass performance.

Tool-call error rate

Separate model errors from infrastructure failures:

• Invalid JSON arguments
• Unsupported parameter or wrong type
• Wrong tool selection
• Duplicate or unnecessary calls
• Path escape or missing-file attempts
• Tool timeout or service outage

Only the first five are clear model-behavior signals. A Git server outage should not be scored as a reasoning failure.

Task completion time

Report median and p95 wall-clock time. Token generation is only one component; tool round trips, test execution, retries, rate limits, and queues also matter. DeepSeek currently publishes a concurrency limit of 2,500 for Flash and 500 for Pro, so Flash can have an additional throughput advantage in highly parallel workloads.

Tokens per task

Split input into cache hits and misses. DeepSeek says disk context caching is enabled by default and requires matching prompt prefixes. Stable system prompts and tool schemas can make a large part of a multi-turn agent transcript much cheaper.

Cost per successful result

This is the headline metric, but never publish it without the underlying pass rate, attempts, token mix, and sample count. Two models can reach the same dollar figure for very different operational reasons.

Pricing changes on August 16, 2026

DeepSeek has announced peak/off-peak pricing effective 16:00 UTC on August 16, 2026. Peak hours are 01:00–04:00 and 06:00–10:00 UTC; other hours are off-peak.

Model	Period	Cache hit input	Cache miss input	Output
V4-Flash	Off-peak	$0.007	$0.22	$0.66
V4-Flash	Peak	$0.014	$0.44	$1.32
V4-Pro	Off-peak	$0.022	$0.66	$1.98
V4-Pro	Peak	$0.044	$1.32	$3.96

All values are per million tokens. Under the announced schedule, Pro's cache-miss input and output remain 3× Flash's. Time shifting therefore halves the bill but does not materially change the Pro-versus-Flash ratio. For asynchronous agents—code indexing, batch migrations, nightly research—scheduling may save as much money as model routing.

Five insights that token-price tables miss

1. Flash's concurrency can be an economic advantage

A 5× higher published concurrency limit can reduce queueing and increase utilization for fleets of small independent tasks. Cost models that ignore throughput can choose a “better” model that becomes the system bottleneck.

2. Output discipline matters more than most teams expect

Output is priced above input for both models. Verbose planning, repeated summaries, and oversized tool arguments inflate cost without improving success. Compare tokens to the first valid result, not tokens to the end of an unconstrained conversation.

3. Prompt-prefix engineering changes the cost curve

Put stable instructions and tool definitions first. Move request-specific timestamps, IDs, and volatile context later. This improves the chance that DeepSeek's prefix cache can reuse the expensive beginning of a multi-turn session.

4. Long context is not free retrieval quality

Both models accept 1M tokens, but “fits in context” is not the same as “finds the relevant dependency.” Track files inspected, relevant evidence cited, and hallucinated paths. More input can increase cost while making the answer less focused.

5. The optimal system may use both models

Start bounded tasks on Flash. Escalate to Pro only on observable signals such as:

• A failed deterministic test
• Repeated invalid tool calls
• A timeout or turn-budget exhaustion
• A repository size or dependency depth above a calibrated threshold
• A low-confidence or incomplete planning rubric score

This avoids paying the Pro premium on tasks Flash handles correctly while limiting the retry tax on harder work. The routing policy itself should be benchmarked: include the failed Flash attempt in the routed task's final cost.

Decision guide: which model should you choose?

Choose V4-Flash first when:

• Tasks are short, bounded, and objectively checkable
• Most work is independent and highly parallel
• A cheap retry is acceptable
• Tool schemas are simple and stable
• Latency and throughput matter more than edge-case reasoning

Choose V4-Pro first when:

• A failed attempt has a high external cost
• The task spans many modules or dependencies
• Recovery after a wrong action is difficult
• The agent must maintain a long plan across many tool calls
• Your own benchmark shows enough first-pass uplift to repay the premium

Use Flash → Pro escalation when:

• Success is mechanically detectable
• Task difficulty varies widely
• You can preserve or compact useful context during escalation
• You measure the combined cost, including failed Flash attempts

Final verdict

V4-Flash has the lower list price and will probably have the lower cost per successful task for simple, bounded agent work. It is about one-third the price of Pro on uncached input and output under both the current and announced pricing ratios, and it has a 5× higher published concurrency limit.

V4-Pro is not the economical choice by default. Its business case is reliability: fewer retries, fewer malformed tool calls, better cross-file reasoning, or a much higher pass rate on difficult tasks. Those benefits must be large enough to overcome roughly a 3× token-price premium.

The correct production decision is therefore empirical:

1. Test both models on your real task distribution.
2. Count failed attempts and tool errors.
3. Price cached and uncached tokens correctly.
4. Divide the entire bill by objectively successful results.
5. Route easy work to Flash and escalate only where measured failure patterns justify Pro.

That is the difference between buying cheap tokens and running a cost-efficient agent.

After choosing between Pro and Flash, see how to set up the official DeepSeek Harness and understand the agent runtime around the model.

Sources and methodology notes

• DeepSeek Models & Pricing — model IDs, context, output limit, features, prices, concurrency, and announced peak/off-peak schedule; accessed August 14, 2026.
• DeepSeek V4 Preview Release — parameter figures and first-party positioning of Pro and Flash; April 24, 2026.
• DeepSeek V4-Pro GA Release — GA timing and reasoning-effort positioning; August 13, 2026.
• DeepSeek Thinking Mode — effort mapping and configuration.
• DeepSeek Tool Calls and Context Caching — agent-loop and caching behavior.

Research cutoff: August 14, 2026. Developer benchmark statements are labeled as first-party claims. We did not verify an independent public benchmark that compares these exact V4-Pro and V4-Flash versions with a common agent harness while also reporting tokens, retries, tool errors, latency, and cost per success.