As of 2026-07-31, the official DeepSeek API prices DeepSeek V4 Flash at $0.0028 per million cache-hit input tokens, $0.14 per million cache-miss input tokens, and $0.28 per million output tokens, per the official Models & Pricing page. Those three numbers are real, but none of them alone is your cost. A real task mixes cached and uncached input, generates reasoning tokens, and sometimes needs retries, so your effective rate lands somewhere between the headline cache-hit price and several times the output price. This page shows the current rates with their source and date, walks through the billing formula, computes three worked examples, and explains the announced-but-not-yet-active peak pricing. We are an independent fan site, not DeepSeek, so every dynamic number below carries a date and a link.
Current DeepSeek V4 Flash Prices
Price per million tokens
The official pricing page lists these rates for the deepseek-v4-flash model ID as of 2026-07-31:
| Meter | Price per 1M tokens | What it covers |
|---|---|---|
| Input, cache hit | $0.0028 | Input tokens matched against DeepSeek's context cache |
| Input, cache miss | $0.14 | Input tokens processed fresh |
| Output | $0.28 | All generated tokens returned to you |
In prose: uncached input costs 50 times more than cached input, and output costs twice as much as uncached input. That 50x spread between the two input meters is why two workloads with identical token totals can produce bills that differ by an order of magnitude. The same page lists the current model version as DeepSeek-V4-Flash-0731 with a context window of up to 1M tokens and a maximum output of 384K tokens; the version story is covered on our 0731 release page. Note that these are DeepSeek first-party API prices. Third-party hosts set their own rates and may serve older checkpoints: on 2026-07-31, OpenRouter's plain deepseek/deepseek-v4-flash alias still listed the April checkpoint at $0.09/$0.18, while the new deepseek-v4-flash-0731 slug matched the official $0.14/$0.28.
Last-verified date and official source
Every price on this page was read from the DeepSeek Models & Pricing page on 2026-07-31, launch day of the 0731 release, and cross-checked against the official changelog. These are dynamic commercial values: DeepSeek changed model lineups and prices earlier in 2026, and the pricing page already pre-announces a peak-hour multiplier with no effective date. Treat any DeepSeek V4 Flash price you see without a date as suspect, including ours if you are reading this long after July 2026 - check the official page before you budget. One known trap: an official Pi integration example elsewhere in DeepSeek's docs showed a cache-read figure of $0.028/M, ten times the pricing page's $0.0028/M. The pricing page is the canonical source; we treat the Pi example as a stale snippet, and we flag the conflict rather than average it.
How DeepSeek V4 Flash Billing Works
The cost formula
DeepSeek bills per token, in three meters, and the token usage guide defines the token as the billing unit. The whole formula is:
cost = (cache_hit_tokens / 1,000,000) x $0.0028
+ (cache_miss_tokens / 1,000,000) x $0.14
+ (output_tokens / 1,000,000) x $0.28
Three practical consequences follow. First, you do not choose the cache split; DeepSeek's servers decide which prefix of your input matches the cache, so the first two terms are only knowable from the usage data returned with each response. Second, output includes everything the model generates, and with thinking mode enabled that means reasoning content too - the docs list no separate reasoning-token price as of 2026-07-31, so plan for reasoning at the $0.28/M output rate. Third, there is no request fee, no context-size surcharge, and no subscription on the pay-as-you-go API: a 500K-token prompt costs more than a 5K-token prompt only because it contains more tokens, a point we expand on the context window page.
Which usage fields appear on the bill
Every API response includes a usage object, and the context caching guide documents how input tokens are reported split into cache-hit and cache-miss counts alongside the output token count. This is the ground truth for the formula above: multiply each reported count by its rate and you have reconstructed the charge for that request. If you log nothing else, log these per-request numbers, because they answer the two questions that dominate real bills - what share of input actually hit the cache, and how many tokens the model generated including reasoning. Aggregates in the platform console tell you what you spent; the per-request usage fields tell you why. When integrating through the DeepSeek V4 Flash API, wire these fields into your own metrics from day one rather than discovering your cache-hit rate from an invoice.
Worked DeepSeek V4 Flash Cost Examples
A small uncached request
Take a one-off request with no cacheable history: 2,000 input tokens (all cache miss, since nothing was cached) and 800 output tokens.
input: 2,000 / 1,000,000 x $0.14 = $0.000280
output: 800 / 1,000,000 x $0.28 = $0.000224
total: $0.000504
About five hundredths of a cent. At this rate you could run roughly 1,980 such requests for one dollar. This is the scenario where per-token pricing genuinely is as cheap as it sounds, because there is no reasoning burn, no long prefix, and no retry loop. It is also the least representative scenario for agent work, which is exactly why headline comparisons built from small one-shot prompts underestimate real project costs.
A request with a reusable cached prefix
Now a chat-with-context pattern: a 50,000-token system prompt plus repository context that was sent before and hits the cache, 3,000 fresh input tokens, and 1,500 output tokens.
cached prefix: 50,000 / 1,000,000 x $0.0028 = $0.000140
fresh input: 3,000 / 1,000,000 x $0.14 = $0.000420
output: 1,500 / 1,000,000 x $0.28 = $0.000420
total: $0.000980
Under a tenth of a cent, even though the request carried 53,000 input tokens. Run the same request fully uncached and the input alone costs 53,000 / 1,000,000 x $0.14 = $0.00742, for a total of $0.00784 - eight times more. The entire difference is the cache: the 50,000-token prefix cost $0.000140 cached versus $0.00700 uncached. This is why prompt structure matters more than prompt length with DeepSeek V4 Flash. Keep stable content (instructions, schemas, project context) at the front and identical across requests, and the cache can absorb most of your input bill.
A long coding-agent turn
Agent harnesses such as the setups on our Claude Code page send big contexts every turn. Take one turn with 400,000 input tokens - 300,000 hitting cache from earlier turns, 100,000 fresh (new diffs, tool results) - and 30,000 generated tokens including reasoning:
cache hit: 300,000 / 1,000,000 x $0.0028 = $0.000840
cache miss: 100,000 / 1,000,000 x $0.14 = $0.014000
output: 30,000 / 1,000,000 x $0.28 = $0.008400
total: $0.023240
About 2.3 cents per turn, and a 50-turn session comes to roughly $1.16. Notice the shape: the 300,000 cached tokens - three quarters of the input - contribute under 4% of the cost, while the 100,000 fresh tokens and 30,000 output tokens carry 96% of it. If the cache had missed entirely, this single turn would cost 400,000 / 1,000,000 x $0.14 + $0.0084 = $0.0644, nearly triple. Agent economics on DeepSeek V4 Flash are therefore mostly a story about cache behavior and output verbosity, not about the input meter's list price.
How Context Caching Changes the Price
Cache hit versus cache miss
DeepSeek's context caching is automatic: the server checks whether the beginning of your input matches content it recently processed, bills the matched prefix at $0.0028/M, and bills the rest at $0.14/M. You do not configure it, pay a storage fee for it, or opt in. The mechanism rewards prefix stability - caching works on the front of the request, so a byte that changes early in your prompt (a timestamp, a random ID, a reordered file list) can push everything after it to the cache-miss meter. The practical rules: put immutable content first, append rather than rewrite conversation history, and avoid injecting volatile values into the system prompt. Nothing about the cache changes what the model sees; it only changes which meter the input lands on.
Why you must measure your own hit rate
Any cost projection needs an assumed cache-hit rate, and that rate is a property of your workload, not of the model. A multi-turn agent that faithfully replays history can see most input tokens hit the cache; a stateless batch job that sends unique documents can sit near zero. Community reports cut both ways: a widely shared launch-era Reddit post described an 11M-token project run costing about $0.033 (r/DeepSeek, 2026-07-26) - arithmetic that only works with a very high hit rate - while other users report bills far above what the cache-hit price implies. Both are individual, unaudited data points, not specifications. The only reliable method is to run a day of your real traffic, read the cache-hit and cache-miss token counts from the usage fields, and compute the observed rate. Budget from that number, and re-measure whenever you change your prompt structure, because a refactor that breaks prefix stability can multiply your input bill silently.
Reasoning Tokens, Retries, and Failed Tasks
Why higher effort can cost more
DeepSeek V4 Flash supports thinking mode with low, high, and max reasoning effort, per the thinking mode guide as of 2026-07-31. Higher effort tends to produce more reasoning tokens, and those are generated tokens on the output meter. The model is also verbose by default: in Artificial Analysis's independent 2026-07-31 evaluation, DeepSeek V4 Flash 0731 consumed about 210M output tokens across their benchmark suite versus a roughly 62M median for comparable models (Artificial Analysis), even after a reported ~12% verbosity reduction versus the previous version. Roughly triple the tokens at the same per-token price means the effective cost gap versus a terser competitor is smaller than the price sheet suggests. Effort choice is a real cost lever: if low passes your tests, max is pure spend. Benchmark scores at max effort - discussed on our benchmarks page - were bought with tokens someone has to pay for.
Cost per accepted result versus cost per request
The number that belongs in your budget is dollars per accepted result, not dollars per request. A coding task that succeeds on the first attempt costs one turn; a task that takes three attempts, a revert, and a review pass costs the sum of all of them, including every failed run. If a cheaper model doubles your retry count, it is not cheaper - a point community users make repeatedly in launch-window discussions (r/hermesagent pricing thread, community observations). To compare models honestly, hold the task set constant and record total tokens across all attempts, wall time, and how many outputs you actually accepted, then divide spend by acceptances. On that metric DeepSeek V4 Flash often still looks strong because its per-token base is low, but the margin is workload-specific and only your own logs can establish it.
Estimating Monthly API Cost
Inputs needed for a useful estimate
A monthly estimate needs five numbers: requests per day, average cache-miss input tokens per request, average cache-hit input tokens per request, average output tokens per request (including reasoning), and a retry multiplier. Then: monthly cost = 30 x requests/day x per-request cost x retry multiplier, with per-request cost from the formula above. Worked quickly: an agent doing 200 turns a day shaped like our long-turn example (2.324 cents each) with a 1.3x retry multiplier runs 30 x 200 x $0.02324 x 1.3 = about $181 per month. A light assistant doing 500 small uncached requests a day ($0.000504 each, no retries) runs about $7.56. Same model, same prices, 24x apart. Get the five inputs from a one-week measurement window rather than guesses, and your estimate will usually land within a few tens of percent.
Why community monthly bills vary so widely
Launch-window community reports span two orders of magnitude: roughly $1.25 a day from one user, over $100 a month from another, $50 in four days from a third, and a Hacker News commenter reporting $4.55 for 323M tokens across 3,467 requests. All of these appear in dated community threads (r/hermesagent, 2026-05-22; Hacker News launch thread, 2026-07-31) and none is wrong - they simply encode different cache-hit rates, effort settings, harnesses, retry behavior, and task sizes. The 50x gap between input meters plus a free-range output meter means "what does it cost per month" has no model-level answer. Treat community bills as evidence of the variance, not as data points to average into a forecast.
DeepSeek Peak Pricing
The announced Beijing-time windows
The official pricing page, as read on 2026-07-31, announces that peak-hour prices will be 2x the regular prices during 09:00-12:00 and 14:00-18:00 Beijing time (UTC+8) daily (Models & Pricing). Converted, those windows are 01:00-04:00 and 06:00-10:00 UTC, which overlaps the European morning and brackets the US East Coast's early hours. If and when this takes effect, off-peak scheduling becomes a real optimization: a batch workload shifted outside those seven hours would keep today's rates, while an interactive product serving Chinese or European business hours would absorb a doubling on much of its traffic. Doubled rates would make the cache-miss meter $0.28/M and output $0.56/M during peak windows, assuming the multiplier applies uniformly - the page does not yet break that down.
Why announced does not mean active
Peak pricing is not in effect. The pricing page states the effective date "will be subject to the official announcement," and as of 2026-07-31 no date has been published - our launch-day recheck of the official page confirmed this explicitly. Every calculation on this page therefore uses the flat rates. This is a classic pre-announcement: the policy and windows are documented, the start date is not, and any third-party page telling you peak pricing "is live" is ahead of the official source. Before you commit to a cost model that depends on time-of-day arbitrage, check the official pricing page for an effective date, and expect the flat-rate examples above to need a peak/off-peak split once it lands.
Hosted API Cost Versus Open Weights
MIT weights do not make the API free
DeepSeek published the official DeepSeek-V4-Flash-0731 weights on Hugging Face under the MIT license on release day. That means you may download, modify, and redistribute the weights - it does not mean the hosted API is free, and it never has. The API is a metered service running on DeepSeek's infrastructure at the prices above; the license covers the model files, not the serving. "Open weights" and "free API" get conflated constantly in launch commentary, so to be plain: there is no official free tier documented on the pricing page as of 2026-07-31, and third-party "free" endpoints are separate offers with their own terms, limits, and - as noted earlier - possibly older checkpoints. The MIT license also grants no rights to DeepSeek's trademarks or domains, which is one reason this site is explicitly an unofficial fan project.
What local inference adds to total cost
Running the weights yourself replaces the per-token bill with hardware, electricity, and operations. The scale is substantial: Unsloth's GGUF conversions of the 0731 build list a near-lossless Q4 around 155GB and a Q8 around 162GB, with Unsloth recommending roughly 110GB to 169GB+ of RAM depending on quantization (Unsloth docs, vendor-published figures for their specific artifacts, retrieved 2026-07-31). Those numbers attach to those exact community conversions on capable machines - there is no universal minimum spec for this 284B-total/13B-activated model, and throughput varies wildly with quant, runtime, and hardware. A realistic local total cost includes the machine (or its depreciation), power, cooling, storage, your time keeping runtimes current, and quality risk from aggressive quantization. Local wins on privacy and control; at July 2026 API rates it rarely wins on pure dollars unless the hardware already exists and runs near capacity. For most cost-driven users, the hosted API with good cache discipline is the cheaper path, with the comparison to V4 Pro relevant only if you need a bigger model.
DeepSeek V4 Flash Pricing FAQ
How much is DeepSeek V4 Flash per million tokens?
As of 2026-07-31, the official DeepSeek API charges $0.0028 per million cache-hit input tokens, $0.14 per million cache-miss input tokens, and $0.28 per million output tokens (official pricing page). There is no request fee or subscription on the pay-as-you-go API. Because the cache split is decided server-side per request, your blended input rate falls somewhere between $0.0028 and $0.14 depending on workload.
Is the DeepSeek V4 Flash API free?
No. The hosted API is usage-priced at the rates above, and the official pricing page documents no free tier as of 2026-07-31. The model weights are separately available under the MIT license, which makes the files free to download and use but does not discount the hosted service. Third-party "free" endpoints exist in aggregator catalogs, but on launch day at least one such listing had no working provider behind it, so verify any free offer directly before depending on it.
Why is my bill higher than the cache-hit price?
Because $0.0028/M only applies to input tokens that hit the context cache. Fresh input costs 50x more, output costs 100x more, and reasoning tokens land on the output meter. A request with a low cache-hit rate and verbose generation can cost two orders of magnitude more than a naive cache-hit-only estimate. Read the cache-hit and cache-miss token counts in the API's usage fields to see exactly where your money went.
Does reasoning effort affect the price?
The per-token rates do not change with effort, but higher effort typically generates more reasoning tokens, and those bill at the $0.28/M output rate. Independent launch-day measurement found the 0731 model markedly more verbose than comparable models, so effort and verbosity are the dominant controllable cost factors after cache behavior. If a task passes at low effort, running it at max only adds cost.
Does the 1M context window have a separate fee?
No. There is no surcharge for using long context - you simply pay per token for whatever you send, so large contexts cost more only because they contain more tokens. A fully uncached 1M-token prompt would cost 1,000,000 / 1,000,000 x $0.14 = $0.14 of input before any output; the same prompt fully cache-hit would cost $0.0028. Long-context work is therefore extremely sensitive to cache behavior, as explained on our context window page.
Is peak pricing active now?
No. As of 2026-07-31, DeepSeek has announced 2x pricing for the 09:00-12:00 and 14:00-18:00 Beijing-time windows but has not published an effective date; the official page says the date will follow in a separate announcement. All current bills use the flat rates. Recheck the official pricing page before building time-of-day assumptions into a budget.