DeepSeek API pricing looks exceptionally low on a per-token basis, but the headline rate is not enough to predict a production bill. The amount you actually pay depends on the model, the proportion of input served from cache, how much reasoning and final output the model generates, and how often your application retries or sends growing conversation history.

This guide explains the current V4 Flash and V4 Pro rates, what happened to the older R1 pricing model, and how to calculate realistic monthly costs for support bots, coding agents, document processing and bulk extraction. The worked examples use stated assumptions rather than claiming access to a private DIY AI invoice. For cross-provider capability and value comparisons, use our AI model comparison; this page stays focused on DeepSeek billing and cost control.

---

---

R1 pricing in 2026 is mostly a model-name trap

Many DeepSeek pricing pages still quote the original R1 API rates of $0.14 per million cache-hit input tokens, $0.55 per million cache-miss input tokens and $2.19 per million output tokens. Those figures were valid for the R1 release, but they are not the right basis for a new DeepSeek integration in July 2026.

The older deepseek-reasoner model name now routes to the thinking mode of V4 Flash. The deepseek-chat alias routes to V4 Flash with thinking disabled. DeepSeek says both aliases will be retired on 24 July 2026 at 15:59 UTC, so new code should call deepseek-v4-flash or deepseek-v4-pro directly.

This creates more than a housekeeping problem. A budget spreadsheet labelled “R1” can silently combine an old rate card, a new underlying model and a soon-to-break model identifier. Pin the current model name, record the pricing date next to every forecast, and treat any alias as migration debt.

The billing formula developers should actually use

A useful DeepSeek cost model separates tokens into three buckets. Do not multiply the total tokens by a single blended rate unless you have already measured your cache mix and output share.

Request cost =
(cache-hit input tokens / 1,000,000 × cache-hit rate)
+ (cache-miss input tokens / 1,000,000 × cache-miss rate)
+ (output tokens / 1,000,000 × output rate)

Cache-hit input is cheap, but only repeated prefixes qualify

DeepSeek context caching is automatic. Repeated content can receive the lower cache-hit rate when a later request shares the same prefix from the beginning of the prompt. Static system instructions, tool definitions, few-shot examples and repeated document context should therefore appear before variable user content.

Small prompt changes near the beginning can turn an expected hit into a miss. Timestamps, request IDs, shuffled tool schemas, changes to whitespace, or middleware that rewrites the system message can all reduce prefix reuse. DeepSeek persists cache-prefix units at request boundaries, when it detects a reusable common prefix and at fixed intervals in long inputs. The service still works on a best-effort basis, does not guarantee a 100% hit rate and clears unused entries after a period.

A recurring operational complaint from developers is that a design which looks cache-friendly on paper can produce a much lower hit rate in production. The usual cause is not the price table. It is a wrapper, agent framework, or prompt builder that changes the prefix between requests. Track prompt_cache_hit_tokens and prompt_cache_miss_tokens from every response instead of assuming the cache worked.

Reasoning tokens belong in the output budget

Thinking mode does not need a separate surcharge to become expensive. Reasoning tokens are part of completion usage, so a task that produces a long hidden reasoning trace can cost more than a concise non-thinking response even when both return the same 300-word answer.

Set an output limit that matches the task, choose the lowest reasoning effort that meets your accuracy target and log completion_tokens_details.reasoning_tokens where the client exposes it. Output control is especially important in autonomous agents because each long answer can trigger another tool call and another full round of context.

Conversation history grows the input bill on every turn

A chat application often resends the full message history. The first few turns are cheap, but the twentieth request may include the system prompt, tool definitions and every earlier exchange. Caching can reduce the rate applied to repeated history, yet the application still depends on the prefix matching correctly.

For long-running sessions, summarise older turns into a stable memory block, keep recent messages verbatim and remove tool results that no longer affect the task. This is usually a better cost-and-quality strategy than filling the context window simply because it is available.

Worked DeepSeek API cost examples

The following estimates show how changes in workload shape affect the bill. They are calculator examples, not measured DIY AI production usage. Each assumes the current listed rates and excludes taxes, currency conversion, router mark-ups and application infrastructure.

Workload	Monthly assumption	Cache-hit share	V4 Flash	V4 Pro
Support bot	100,000 replies, 4,000 input tokens and 500 output tokens each	70%	$31.58	$96.72
Coding agent	10,000 tasks, 60,000 input tokens and 8,000 output tokens each	80%	$40.54	$123.54
Document extraction	100,000 documents, 15,000 input tokens and 800 output tokens each	5%	$222.11	$689.75
Bulk classification	1,000,000 records, 1,000 input tokens and 100 output tokens each	20%	$140.56	$435.73

The support and coding examples benefit from repeated instructions, tool schemas and shared project context. The document example does not: most of its input is unique, so caching saves little. This is why quoting one universal “cost per request” is misleading.

Support bot calculation

At 100,000 replies per month, the support workload sends 400 million input tokens and produces 50 million output tokens. With a 70% cache-hit share, V4 Flash charges for 280 million cached input tokens, 120 million uncached input tokens and 50 million output tokens. The result is about $31.58. With no cache hits, the same workload would cost about $70.

Coding agent calculation

The coding example looks cheap because most of the 60,000-token input is assumed to be repeated repository context and instructions. Its $40.54 Flash estimate rises to $106.40 if every input token misses the cache. It also excludes retries, test runs and tool-loop failures, which are often a larger cost multiplier than the initial prompt.

Cost per successful task is the metric that prevents false savings

Per-million-token pricing measures inference, not business value. A cheaper model can cost more if it needs repeated prompts, produces unusable structured output or creates extra human review. The useful metric is:

Cost per successful task =
(total API cost + retry cost + validation cost + human remediation cost)
/ number of accepted results

Consider the coding-agent assumptions above. One V4 Flash attempt costs roughly $0.0041 and one V4 Pro attempt costs roughly $0.0124. On API cost alone, Flash wins comfortably. Now add a hypothetical acceptance rate of 70% for Flash and 90% for Pro, with each rejected result requiring 50 cents of developer time to inspect or repair.

Model	API cost per attempt	Assumed rejection rate	Expected remediation cost	Expected total per attempt
V4 Flash	$0.0041	30%	$0.15	$0.1541
V4 Pro	$0.0124	10%	$0.05	$0.0624

Those acceptance rates are an illustration, not a DeepSeek benchmark. The decision rule is still useful: in this example, Pro becomes cheaper overall when each extra Flash failure costs more than about four cents to fix. Measure the break-even point for your own task set rather than choosing a model based on token price alone.

The six cost leaks that rate cards rarely show

1. Dynamic text placed before reusable context

Putting a timestamp, user ID, or changing instruction at the start of the prompt can prevent the long static section after it from matching the cache. Keep stable content first and variables last. Confirm the result from usage telemetry.

2. Full history resent without pruning

Conversation history expands until each new turn carries a large input payload. Summarise old turns, retain only active facts and set session budgets based on tokens rather than message count.

3. Automatic retries without idempotency

A timeout does not prove that no inference occurred. If the client immediately retries, the application may pay for work that produced no usable response and then pay again for the replacement call. Use exponential backoff, request IDs, bounded retries and logs that distinguish validation errors, rate limits and provider failures.

4. Output limits set for the model maximum

A generous maximum can hide prompt problems. Classification may need 20 tokens, extraction a few hundred and a code patch a few thousand. Set task-specific limits and stop sequences rather than allowing every endpoint to produce a long response.

5. Agent loops that repeat the same failure

An agent may call a tool, receive an invalid result, revise its plan and repeat. Each step adds output, tool data and conversation history. Cap tool calls, detect repeated arguments and stop after a defined failure pattern rather than relying on the model to recognise a loop.

6. Forecasts based on average prompts instead of percentiles

Average token use can conceal expensive long-tail requests. Budget with median, 90th-percentile and 99th-percentile input and output sizes. A small number of large repository, document, or conversation requests can dominate the bill, even when the typical call is tiny.

Direct DeepSeek billing versus a third-party model router

A model router can simplify multi-provider access, failover and consolidated billing. It can also make the DeepSeek rate card less predictable because the router may use different providers, add a margin, expose different caching behaviour or map a friendly model name to a changing backend.

Decision area	Direct DeepSeek API	Third-party router
Price transparency	Closest match to DeepSeek’s published token categories	May include a mark-up or provider-specific rate
Cache visibility	Native cache-hit and cache-miss usage fields	Depends on the router and underlying provider
Failover	You build and test it	Often available through one integration
Model consistency	Direct model identifiers and provider behaviour	Aliases or provider routing may change behaviour
Data path	One primary API provider	Additional processor and possibly multiple inference providers
Procurement	Separate account, balance and contract	Consolidated billing may be easier for multi-model teams

Use direct billing when the lowest listed price, native cache telemetry and model consistency matter most. Use a router for provider failover; a single API surface or consolidated billing saves more engineering time than any potential price difference. Compare the invoice rate, not the model name alone. Our Grok pricing guide shows how another provider-specific rate card can differ from the cost of accessing a model through an intermediary.

Governance can outweigh a cheap token price

DeepSeek can be financially attractive and still be unsuitable for a particular workload. Before sending customer conversations, source code, legal documents or regulated records, review the provider’s contractual terms, data handling, retention, support route, audit requirements and the jurisdictions your organisation allows.

Include migration cost in the decision. Model aliases can retire, output behaviour can change, and an organisation may later require a different hosting region or vendor. A portable prompt layer, model-level evaluation suite and provider-neutral logging make a low-cost trial easier to reverse.

For a hobby project, those controls may be excessive. For a client-facing product, the absence of an approved data-processing route or dependable support can cost far more than the tokens. Cheap inference is only a saving when the workload is permitted to use it.

A practical DeepSeek cost-control implementation

1. Start with V4 Flash and a representative evaluation set rather than production traffic.
2. Route only failed, high-value or demonstrably difficult tasks to V4 Pro.
3. Place static prompts, tool schemas and shared context before variable request data.
4. Log cache-hit input, cache-miss input, output and reasoning tokens for every call.
5. Set per-task output limits, retry limits, tool-call limits and total token budgets.
6. Measure accepted results, retries and human remediation alongside API spend.
7. Alert on daily spend, cache-hit collapse and sudden changes in tokens per successful task.
8. Re-run the evaluation when the model version, alias, rate or hosting route changes.

A small calculator you can put into a budget script

const DEEPSEEK_RATES = {
  "deepseek-v4-flash": { cacheHit: 0.0028, cacheMiss: 0.14, output: 0.28 },
  "deepseek-v4-pro": { cacheHit: 0.003625, cacheMiss: 0.435, output: 0.87 }
};

function calculateDeepSeekCost({
  model,
  cacheHitInputTokens,
  cacheMissInputTokens,
  outputTokens
}) {
  const rate = DEEPSEEK_RATES[model];

  if (!rate) {
    throw new Error(`Unsupported DeepSeek model: ${model}`);
  }

  const cost =
    (cacheHitInputTokens / 1_000_000) * rate.cacheHit +
    (cacheMissInputTokens / 1_000_000) * rate.cacheMiss +
    (outputTokens / 1_000_000) * rate.output;

  return Number(cost.toFixed(6));
}

Keep the rates in configuration rather than hard-coding them throughout the application. Add an effective date and update alert so a future price change cannot leave forecasts silently wrong.

DeepSeek API pricing FAQ

How much does the DeepSeek API cost per one million tokens?

V4 Flash costs $0.0028 per million tokens for cache-hit input, $0.14 for cache-miss input, and $0.28 for output. V4 Pro costs $0.003625, $0.435 and $0.87, respectively.

Is the DeepSeek API free?

No. Free access to the consumer chat product should not be confused with API billing. API usage consumes the account balance based on token usage. Promotional or granted credit may appear on some accounts, but it should not be used as the basis for a production forecast.

Does DeepSeek thinking mode cost extra?

There is no separate line-item surcharge in the current table, but thinking can generate additional reasoning tokens. Those tokens contribute to completion usage, so deeper reasoning can still increase a request’s cost.

Is DeepSeek R1 still available through the API?

The legacy deepseek-reasoner name currently maps to V4 Flash thinking mode rather than a separately priced R1 endpoint. It is scheduled for retirement on 24 July 2026, so new integrations should use a V4 model name.

Can I guarantee cache-hit pricing?

No. Caching is automatic and depends on repeated prompt prefixes. Design for prefix stability, then verify the actual hit-and-miss tokens in the response. Do not build a budget around an assumed 100% hit rate.

Which DeepSeek model is cheapest for most applications?

V4 Flash is the sensible default for high-volume and cost-sensitive work. Move selected tasks to V4 Pro only after a controlled evaluation shows that the quality gain reduces retries, rejected outputs or human remediation enough to justify the higher rate.

The practical verdict

DeepSeek V4 Flash can make large text workloads remarkably inexpensive, especially when the application repeats a stable prompt prefix. The main forecasting mistake is treating the cache-hit figure as the normal input price without measuring whether requests actually hit it.

Start with Flash, instrument every token category and calculate cost per accepted task. Reserve Pro for work where a better result prevents retries or human repair. Most importantly, remove the old R1 aliases before 24 July 2026 and keep pricing, model identity and governance checks versioned together. That produces a budget you can trust rather than a spreadsheet built around the cheapest number on the page.