Snapshot date: August 2, 2026. DeepSeek prices below come from the official DeepSeek API documentation checked during this run. Recent market discussion from Axios frames the same move as part of a broader price race, but production budgets should still reference official provider pages and exact model IDs.
Why route coding traffic
Many teams first adopt a Chinese AI API for one reason: a developer asks whether a DeepSeek, Qwen, Kimi or GLM model can reduce the cost of code generation. The better question is more specific. Which requests are simple enough to send to a low-cost default model, which requests need a stronger fallback, and which requests should not be retried because the workflow is already mutating production state?
DeepSeek V4 Flash is a good anchor for that conversation because the official API page lists a 1M context window, OpenAI-format and Anthropic-format base URLs, JSON output, tool calls and separate cache-hit and cache-miss input prices. Those features map directly to common developer workflows: repository summarization, issue triage, test generation, structured extraction and short code review comments. A router turns those features into a controlled production surface.
The router approach also protects your team from headline-driven buying. In the last week, coverage around Chinese AI models has focused on falling prices, open-weight releases and the pressure on US model providers. That context matters for procurement, but it is not an engineering control. Your application still needs request caps, exact model IDs, retries, fallback rules and observability. AIWave's API docs, pricing page and cost-aware router guide are built around that practical layer.
For US, UK, German and Singapore teams, the most valuable framing is not "lowest possible price." It is predictable cost per completed job. A request that costs less per million tokens can still be expensive if it returns invalid JSON, ignores tool contracts or forces three retries. A more expensive fallback can be economical when it saves a human review cycle. Route by job outcome, not by model reputation.
Verified pricing inputs
DeepSeek's official pricing page lists deepseek-v4-flash at $0.0028 per 1M cache-hit input tokens, $0.14 per 1M cache-miss input tokens and $0.28 per 1M output tokens. The same page lists deepseek-v4-pro at $0.003625 cache-hit input, $0.435 cache-miss input and $0.87 output. It also says product prices may vary and recommends checking the page regularly. Treat that note as a requirement for your own pricing metadata.
Two operational details are easy to miss. First, cached input and uncached input are different budget lines. A 60,000-token repository prefix is a very different product cost when it hits cache than when it misses cache. Second, the legacy deepseek-chat and deepseek-reasoner compatibility names were documented as mapping to V4 Flash modes around the July 2026 transition. New integrations should prefer the current V4 model identifiers so logs, budgets and customer-facing documentation stay clear.
Here is the cost-control view you should maintain internally:
| Route | Use it for | Budget risk | Control |
|---|---|---|---|
| DeepSeek V4 Flash | Short coding help, extraction, issue triage, cached repository context | Broken cache or verbose output | Stable prefix, max output, JSON validation |
| DeepSeek V4 Pro | Harder reasoning fallback and review of failed Flash attempts | Higher output spend when used as default | Fallback only after validation failure or explicit task class |
| GLM or Kimi family | Long-horizon agent jobs after benchmark approval | Higher list rates and different billing behavior | Separate route, source-checked rates, task fixtures |
| Qwen family | Alibaba Cloud deployments and region-specific workloads | Tiered pricing by model and request length | Rate table keyed by model, region and context tier |
Routing policy
A production policy should start with workload labels. Do not route by vague user text alone. Label jobs as extract, short_code, repo_summary, agent_plan or fallback_review. Each label should have a primary model, maximum output, retry policy and validation rule. This is boring, but it is what stops a support chatbot from using a long-context coding route by accident.
The second policy layer is cache eligibility. If the prompt has a stable prefix such as coding standards, API docs, a repository map or a product policy, mark the request as cache eligible. Keep timestamps, trace IDs and user-specific fields out of that prefix. If your provider returns cached token counts, store them. If your provider does not expose them in a normalized way, store expected eligibility and reconcile against invoices. Cache-hit ratio is a production metric, not a prompt-engineering curiosity.
The third policy layer is fallback discipline. Retry a timeout or 5xx response if the operation is idempotent. Retry a JSON validation failure once with a stricter repair instruction. Use a stronger model only after the primary route fails a measurable rule. Never retry a request that has already sent an email, charged a card or changed a database unless your workflow has idempotency keys. This matters for GDPR-facing and enterprise workflows because auditability is part of reliability.
Runnable Python router
The following script is runnable with the OpenAI Python SDK. It keeps prices as dated configuration, separates cached and uncached estimates, and validates JSON when the job requires it. Set AIWAVE_API_KEY and optionally AIWAVE_BASE_URL.
# pip install openai
import json
import os
from dataclasses import dataclass
from openai import OpenAI
client = OpenAI(
api_key=os.environ["AIWAVE_API_KEY"],
base_url=os.getenv("AIWAVE_BASE_URL", "https://api.aiwave.live/v1"),
)
RATES = {
"deepseek-v4-flash": {
"input_per_m": 0.14,
"cached_input_per_m": 0.0028,
"output_per_m": 0.28,
"source": "https://api-docs.deepseek.com/quick_start/pricing/",
"checked_at": "2026-08-02",
},
"deepseek-v4-pro": {
"input_per_m": 0.435,
"cached_input_per_m": 0.003625,
"output_per_m": 0.87,
"source": "https://api-docs.deepseek.com/quick_start/pricing/",
"checked_at": "2026-08-02",
},
}
@dataclass
class Job:
kind: str
prompt: str
require_json: bool = False
stable_prefix_tokens: int = 0
max_output: int = 900
def estimate_tokens(text: str) -> int:
return max(1, len(text) // 4)
def choose(job: Job) -> str:
if job.kind in {"fallback_review", "hard_reasoning"}:
return "deepseek-v4-pro"
return "deepseek-v4-flash"
def estimate_cost(model: str, job: Job) -> float:
total_input = estimate_tokens(job.prompt)
cached = min(job.stable_prefix_tokens, total_input)
uncached = total_input - cached
rate = RATES[model]
return (
cached / 1_000_000 * rate["cached_input_per_m"]
+ uncached / 1_000_000 * rate["input_per_m"]
+ job.max_output / 1_000_000 * rate["output_per_m"]
)
def complete(job: Job) -> dict:
model = choose(job)
response = client.chat.completions.create(
model=model,
messages=[
{"role": "system", "content": "Return valid JSON only." if job.require_json else "Be concise and verify claims."},
{"role": "user", "content": job.prompt},
],
temperature=0.1,
max_tokens=job.max_output,
)
text = response.choices[0].message.content or ""
parsed = json.loads(text) if job.require_json else None
return {"model": model, "estimated_usd": estimate_cost(model, job), "text": text, "json": parsed}
if __name__ == "__main__":
job = Job(
kind="extract",
prompt="Return JSON with language, risk and suggested test from this ticket: Python migration broke OAuth callback parsing.",
require_json=True,
stable_prefix_tokens=0,
max_output=300,
)
print(json.dumps(complete(job), indent=2))
Production controls
After the router works locally, move the rate table into a small database table or configuration service. Include model ID, provider, region, input price, cached input price, output price, currency, source URL and checked date. If an engineer updates a price without a source URL, reject the change. If a model ID changes, keep the old row so historical cost reports still make sense.
Log at least seven fields for every request: customer project, task label, selected model, estimated input tokens, cached input tokens when available, output tokens, validation result and fallback reason. These fields are enough to answer the questions finance and security teams will ask later: why did spend rise, why did a fallback trigger, and did the model touch regulated data? For GDPR-conscious teams, also log data residency assumptions and retention mode at the gateway layer. Do not put sensitive prompt content into analytics unless the customer has explicitly opted in.
Finally, test the router with fixtures. A fixture is a prompt, expected validation behavior, approximate token shape and accepted route. Keep fixtures for short tickets, long repository maps, JSON extraction, policy refusal and fallback review. Run them when you change models, prompts or provider credentials. A router is only as good as the boring tests that catch silent drift.
A useful first fixture set can be small. Create ten real tickets from your backlog after removing secrets and customer identifiers. For each ticket, write the expected output shape: a JSON object, a patch plan, a migration checklist or a short answer with citations. Run the same fixture against V4 Flash, V4 Pro and your fallback family. Record the accepted result, whether the output needed repair and the estimated cost. Do not average everything into one score; keep a per-task table so the router can learn that extraction, code review and long planning have different winners.
Once the fixtures are stable, expose a dry-run endpoint to your application team. A dry run should return the selected model, expected token range, estimated maximum cost and fallback policy without calling the model. Product managers can use it to price features before launch, while engineers can add alerts when a prompt suddenly grows. This is especially valuable for coding tools because repository size, generated diffs and test output can grow quickly after a minor feature change.
The last production habit is to make routing changes reversible. Store each policy version with a name, author, timestamp and reason. When a model behaves differently after an upstream update, you should be able to restore the previous policy without editing application code. A disciplined rollback path is part of cost control: it stops a temporary provider issue from becoming an extended incident across every customer project.