DeepSeek V4 Flash API Pricing: Cache Costs and a Practical Budget

Short answer: DeepSeek’s official pricing page lists V4 Flash at $0.0028 per one million cached input tokens, $0.14 per one million uncached input tokens, and $0.28 per one million output tokens. Those figures are the starting point for a budget, not a promise that every gateway or reseller will show the same price. Check the official pricing table on the day you deploy.

DeepSeek V4 Flash rates: cache hit, cache miss, and output

DeepSeek separates input tokens that match a previously cached prefix from tokens that must be processed for the first time. A repeated system prompt, tool schema, or long retrieval instruction can therefore have a very different marginal cost from a new prompt. Output is billed separately, so a short prompt can still become expensive when the model writes a long answer.

The practical lesson is to model at least two scenarios. A cold-start estimate uses the cache-miss rate for every input token. A warm estimate applies the cache-hit rate only to the prefix you can keep stable. Do not label the warm scenario guaranteed savings until production telemetry shows the provider is actually returning cache hits.

A simple cost calculator you can audit

Suppose a service sends 1,000,000 input tokens and receives 250,000 output tokens in a month. If every input token is a cache miss, the calculation is 1 × 0.14 + 0.25 × 0.28 = $0.21. If the same workload is a full cache hit, it is 1 × 0.0028 + 0.25 × 0.28 = $0.0728. The second number is a scenario, not a guarantee: it assumes the entire input is eligible for a hit.

Keep the arithmetic in a small script so a pricing-page change cannot silently invalidate a spreadsheet. The script below takes token counts in millions and prints both cold and warm scenarios.

from dataclasses import dataclass

@dataclass
class Rates:
    cache_hit: float = 0.0028
    cache_miss: float = 0.14
    output: float = 0.28

def estimate(input_millions: float, output_millions: float, rates=Rates()):
    cold = input_millions * rates.cache_miss + output_millions * rates.output
    warm = input_millions * rates.cache_hit + output_millions * rates.output
    return cold, warm

cold, warm = estimate(input_millions=1.0, output_millions=0.25)
print("all-miss: $", round(cold, 4))
print("all-hit:  $", round(warm, 4))

Direct DeepSeek access versus a gateway

There is no universally correct route. Direct access can minimize moving parts. A gateway earns its place when your application needs one OpenAI-compatible client, several model families, consolidated billing, or a fallback route. Compare the total operating cost, not just the input line item: key management, observability, retries, model switching, and the time spent maintaining provider-specific clients matter in production.

The table is intentionally explicit about what was and was not observed. A missing row on a public page is not evidence that a provider cannot serve a model; it only means the row was not part of this comparison. Re-check the live pages before making a purchasing decision.

Call V4 Flash with the OpenAI Python SDK

The request shape below follows the provider’s Python example. AIWave exposes the same OpenAI-compatible pattern; only the base URL, key, and model identifier change.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AIWAVE_API_KEY"],
    base_url="https://aiwave.live/v1",
)

response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[
        {"role": "system", "content": "Answer with concise, testable steps."},
        {"role": "user", "content": "Give me a three-step API health check."},
    ],
    temperature=0.2,
)

print(response.choices[0].message.content)

Keep the model ID in configuration rather than hard-coding it throughout your application. That makes it easier to move between V4 Flash and another model page in AIWave’s model catalog, or to test a provider route without rewriting business logic. For JSON output and tool calls, follow the model-specific constraints in the JSON mode guide and tool-calling guide.

How to make cache economics measurable

Prompt caching is a workload-design problem. Put stable material first: the system instruction, policy text, tool schema, and long examples. Append the user-specific question and volatile retrieval snippets afterward. This layout gives the provider a chance to reuse the prefix while keeping the request useful.

1. Log input and output token counts for every request.
2. Record cache-hit and cache-miss counts when the API returns them.
3. Compare the observed hit ratio with the estimate from the calculator.
4. Set a budget alert on total output tokens, which are not reduced by input caching.
5. Re-test after changing system prompts, tool schemas, or retrieval chunking.

Do not optimize for the smallest theoretical number if it makes prompts brittle. A stable, observable request that costs a few extra cents can be safer than a perfectly cached prompt that breaks whenever a developer edits one line.

A practical migration checklist

Start with one endpoint and a fixed evaluation set. Send the same 50–100 representative prompts through your current provider and through V4 Flash, then compare correctness, latency, output length, and cost. Keep the evaluation prompts in version control. When the scores are acceptable, put the model behind a feature flag and watch spend and error rates for one week.

If your code already uses the OpenAI SDK, the migration is usually a configuration change: set the base URL, use the model ID, and retain your existing retry and timeout policy. Review authentication, rate limits, content handling, and data-retention terms separately; API compatibility does not make provider policies identical.

Budgeting should also include the parts that token tables do not capture. Measure request retries, failed generations, moderation or validation passes, and any fallback model calls. A service that retries a timed-out response twice can spend more than a clean first response even when its nominal token price is lower. Track cost per successful user task, not only cost per request, and keep a small sample of prompts for every pricing review. This is especially useful when you change output limits: a higher limit does not force the model to generate more, but it can make long-tail spend harder to predict.

For a broader model decision, pair this article with the DeepSeek V4 Flash implementation guide, the V4 Flash versus GPT-4o Mini comparison, and the AI API cost comparison.