Snapshot date: August 4, 2026 Asia/Shanghai. The required same-day server keyword report /var/www/html/reports/keyword-intel-2026-08-04.md was not present. The latest available report, generated August 4 for server date August 3, showed Tier 1 interest around kimi api, deepseek vs gpt-4o pricing, deepseek api access overseas and API documentation queries. Those are treated as historical context, not fresh August 4 data.
Keyword signal
DeepSeek V4 and Kimi K3 belong in the same planning conversation because both push developers toward long-context, cache-aware workflows. The value for a US, UK, German, Dutch, Japanese or Singapore team is not a generic claim that Chinese models cost less. The useful question is whether a coding agent can route planning, implementation and review steps across models while preserving an OpenAI-compatible SDK surface, USD budget controls and audit logs.
Recent market coverage makes that routing point explicit. Axios framed the newest DeepSeek model as part of a broader price war and pointed to intelligent routers as a likely buyer response. WIRED covered Chinese labs, including Z.AI, Moonshot, Alibaba and DeepSeek, as accessible alternatives that are now part of Silicon Valley's AI model discussion. Developer threads are more cautious: engineers talk about direct provider APIs, OpenRouter rate limits, privacy posture, cache behavior and whether cheaper models can handle real multi-file work.
For AIWave, the content cluster should therefore target production routing instead of bargain hunting. The right internal path is AIWave API docs for SDK compatibility, the model catalog for available routes, the pricing page for customer-facing rates and the DeepSeek Pro versus Flash routing guide for DeepSeek-specific escalation logic.
Cache economics
DeepSeek's official pricing page lists deepseek-v4-flash with $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 with $0.003625 cache-hit input, $0.435 cache-miss input and $0.87 output. Both model rows show 1M context and tool-call support. The page also warns that a peak/off-peak policy is planned, so production logs should retain request time and not only token totals.
Kimi's public K3 pricing page lists kimi-k3 at $0.30 per 1M cache-hit input tokens, $3.00 per 1M cache-miss input tokens and $15.00 per 1M output tokens, with a 1,048,576-token context window. It presents Kimi K3 as a long-horizon coding and knowledge-work model with automatic context caching, tool calls, JSON mode and structured outputs. That positioning can justify evaluation for whole-repository context, but the output rate makes strict caps and validation important.
Do not compare those rows by asking which model is cheaper in isolation. A coding agent has phases. It may load a large stable repository summary, ask many narrow questions, produce a patch, run tests, then ask for repair. Cache hit rates, retry counts and output length dominate the final bill. A model with a higher cache-miss price may be acceptable if it finishes a risky planning task in one pass. A model with an extremely low cached-input price may still overrun budget if it produces verbose output or fails validation repeatedly.
DeepSeek's caching documentation adds another important detail: cache hits are based on persisted prefixes and the API exposes prompt_cache_hit_tokens and prompt_cache_miss_tokens in usage. That is exactly the data a router needs. Estimate cost before a call, but reconcile estimates after the response. Without reconciliation, the team is only doing spreadsheet optimism.
Routing table
| Agent phase | Primary route | Why | Budget control |
|---|---|---|---|
| Repository map | DeepSeek V4 Flash | Stable prefixes and bounded summaries fit cache-heavy exploration | Cap output and store cache-hit tokens |
| Whole-codebase planning | Kimi K3 evaluation route | 1M context and long-horizon positioning can help large plans | Require task budget approval before long context |
| Implementation patch | DeepSeek V4 Flash | Most edits should be narrow after planning | Require tests and diff-size limits |
| Security or billing review | DeepSeek V4 Pro or human review | Higher-risk steps need stronger reasoning and traceability | No automatic retry after side effects |
| Failed validation repair | DeepSeek V4 Pro or Kimi K3 | Escalate only after a concrete failure signal | One repair attempt, then operator review |
This table is deliberately conservative. It does not treat Kimi K3 as the default just because it can hold a huge context. It does not route every DeepSeek call to Pro just because the task is important. The router should consider phase, risk, expected output, cache profile, validation contract, customer policy and allowed provider list.
Runnable router
The example below uses the OpenAI Python SDK against an OpenAI-compatible endpoint. It estimates an upper bound, applies a per-task budget and records the model route. Replace model IDs with the enabled names in your AIWave account.
# pip install openai
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": {"cached": 0.0028, "input": 0.14, "output": 0.28},
"deepseek-v4-pro": {"cached": 0.003625, "input": 0.435, "output": 0.87},
"kimi-k3": {"cached": 0.30, "input": 3.00, "output": 15.00},
}
@dataclass
class AgentStep:
phase: str
prompt: str
max_output: int
stable_prefix_tokens: int = 0
risk: str = "normal"
budget_usd: float = 0.05
def estimate_tokens(text: str) -> int:
return max(1, len(text) // 4)
def choose_model(step: AgentStep) -> str:
tokens = estimate_tokens(step.prompt)
if step.risk in {"security", "billing"}:
return "deepseek-v4-pro"
if step.phase == "whole_repo_plan" and tokens > 250_000:
return "kimi-k3"
return "deepseek-v4-flash"
def estimate_cost(model: str, step: AgentStep) -> float:
input_tokens = estimate_tokens(step.prompt)
cached = min(input_tokens, step.stable_prefix_tokens)
uncached = input_tokens - cached
rates = RATES[model]
return (
cached / 1_000_000 * rates["cached"]
+ uncached / 1_000_000 * rates["input"]
+ step.max_output / 1_000_000 * rates["output"]
)
def run_step(step: AgentStep) -> str:
model = choose_model(step)
estimate = estimate_cost(model, step)
if estimate > step.budget_usd:
raise ValueError(f"estimated ${estimate:.4f} exceeds budget for {step.phase}")
response = client.chat.completions.create(
model=model,
messages=[
{"role": "system", "content": "Act as a careful coding agent. Return concise, testable output."},
{"role": "user", "content": step.prompt},
],
temperature=0.1,
max_tokens=step.max_output,
)
print({"model": model, "estimated_usd": round(estimate, 6), "phase": step.phase})
return response.choices[0].message.content or ""
if __name__ == "__main__":
print(run_step(AgentStep("repo_map", "Summarize the auth module dependency graph.", 500)))
Operational controls
Production routing needs more than this file. Add fixture tests for each phase, store provider source URLs with pricing rows and alert when observed cost per accepted task moves outside a normal band. Capture cache-hit tokens, cache-miss tokens, output tokens, latency, status code, route, fallback reason and validation result. For enterprise accounts, store customer policy separately: allowed model families, data retention mode, region requirements, logging mode and whether fallbacks can cross provider families.
GDPR-aware teams should avoid silent model substitution. If a German customer allows DeepSeek but not Kimi for a given project, the router should block the Kimi route even when Kimi would be useful for long context. If a Japanese customer permits Kimi for internal code but not personal data, the classifier should enforce that before the request leaves the application. Model diversity is valuable only when policy boundaries are visible.
The rollout pattern is shadow mode. Continue serving users through the current route, but evaluate sampled non-sensitive tasks through the proposed DeepSeek or Kimi path. Compare accepted answer rate, test pass rate, human review score, total cost, cache hit rate and latency. Move only the phases that pass. That keeps the migration practical and avoids treating a price headline as production evidence.