DeepSeek API pricing is not one flat dollar amount per request. The official October 2026 rate card separates model choice, input cache hits, input cache misses, generated output and time-of-day pricing. This is easy to overlook when an old article quotes one “per million tokens” headline without distinguishing what those tokens do.
This article translates the published US-dollar rate table into arithmetic you can inspect yourself. The usage examples are hypothetical calculations, not measured traffic or published benchmarks. Recheck the official pricing page before deploying because DeepSeek reserves the right to change rates and products.
Know which two models the current rate card lists
DeepSeek’s official pricing page currently names `deepseek-flash` and `deepseek-v4-pro`. Flash maps to a V4.1 Flash model and supports general-purpose tasks at the lower listed rates. Pro is the more expensive option on the same published schedule. Do not reuse retired alias names from an outdated tutorial without confirming they still resolve to the intended model.
The card describes prices per one million tokens, not per one million messages or characters. A token is a billing unit; the count depends on the actual text and output. Long histories, tool inputs and verbose responses change consumption. Your application should log reported usage rather than estimate all requests from word counts alone.
Read the off-peak rates by token category
As checked October 26, Flash off-peak rates are $0.15 per million input cache-miss tokens, $0.003 for input cache hits and $0.60 for generated output. Pro lists $0.66, $0.022 and $1.98 respectively. These are separate charges; do not add cache-hit and cache-miss prices to the same individual token.
The official card shows peak rates at twice the off-peak figures. DeepSeek defines peak windows as 01:00–04:00 and 06:00–10:00 UTC on weekdays, excluding Chinese public holidays. All other hours, including weekends, are currently off-peak. If your application operates globally, label schedules in UTC; a user’s local clock may cross a pricing window unnoticed.
Calculate a transparent sample request
Assume a hypothetical off-peak Flash request with 12,000 input cache-miss tokens and 2,000 output tokens. The input cost is 12,000 ÷ 1,000,000 × $0.15 = $0.0018. Output is 2,000 ÷ 1,000,000 × $0.60 = $0.0012. Together that is $0.003 per request before other billable services, taxes or infrastructure.
Now consider 10,000 identical requests under those assumptions: the model-token estimate is $30. If they all occur in the documented peak windows, the same hypothetical token mix would be $60. Real traffic rarely has identical prompt lengths and response sizes, so this is a formula demonstration, not a budget guarantee. Record actual input, output, cache and time distribution before purchasing capacity.
Model the cache-hit scenario correctly
Repeated prompt prefixes can qualify for the lower input cache-hit price, but never assume a fixed percentage of your requests will hit cache. Suppose 12,000 input tokens include 9,000 billed as cache hits and 3,000 as misses. The illustrative Flash off-peak input cost is 9,000 ÷ 1,000,000 × $0.003 plus 3,000 ÷ 1,000,000 × $0.15, or $0.000477.
With the same 2,000 output tokens, that hypothetical request totals $0.001677. Compare this with the noncached example only if the responses and other work are otherwise equivalent. Actual cacheability depends on the request pattern and provider rules. Keep a stable reusable prefix when helpful, but never insert redundant content simply to chase a cheap cache rate.
Separate search, fetch and other request fees
The current official table also shows standalone Search and Fetch APIs billed per successful request, separately from model tokens. That means a research agent can generate both token charges and per-call tool charges. Pricing pages may include introductory exceptions; for example, the documentation describes a future start date for certain harness-triggered search and fetch billing.
To estimate a workload, list each component: model tokens, tool calls, retries, output generation and storage or infrastructure outside the DeepSeek service. Never assume an integration is free simply because the model-only calculation is small. Conversely, do not count a prospective tool fee before its published effective date and applicability have been verified.
Plan monthly costs without false precision
For a defensible forecast, collect a sample of real traffic, calculate median and high-percentile input/output volume, and group requests by model and UTC pricing window. Include a cache-hit measurement from provider usage records if available. Multiply each category by its documented rate, then apply a sensible contingency margin for workload variation. This approach scales better than copying a one-line price comparison.
If you have no production data yet, plan three scenarios: a low case with brief answers, a typical case with known prompt templates, and a stress case with long outputs and minimal caching. Make the assumptions visible to a reviewer. Update the estimate whenever you add tools, document retrieval, parallel requests or a different reasoning mode.
Keep consumer subscriptions and API bills separate
The DeepSeek chat website and the developer API serve different buying tasks. A consumer interface may be accessible without the same billing workflow as an API used by a product or automation. Do not infer API credit, throughput or model access from a consumer subscription or free website experience. The developer dashboard and official API documentation define the relevant charges.
Before integrating, decide who owns the billing account, where the key will be stored, how spend is monitored and what happens if the quota or balance is exhausted. Review current limits and error handling as operational risks as well as financial risks. A low per-token rate is attractive only when the application can manage service behavior safely.
How We Research
Rates and time windows were transcribed from the official DeepSeek Models & Pricing table and model names cross-checked with its first-API-call documentation on October 26, 2026. All arithmetic examples explicitly assume invented token counts for illustration; we did not send billable test requests or claim observed cache performance, taxes or final account charges.
Frequently Asked Questions
Yes. The official API rate card lists input cache-hit, input cache-miss and output prices separately for each current model.
No. The published windows are expressed in UTC and include weekday exceptions. Convert them to the timezone relevant to your jobs.
No. Only qualifying cached input tokens receive the cache-hit rate. Output tokens and cache-miss input are billed according to their own categories.
Only if its capabilities improve your actual evaluated task enough to justify the cost. Compare on your own acceptance tests rather than assuming the higher-priced model always wins.
Do not assume so. Check the separate developer API billing account, balance and official usage documentation.