Snapshot date: August 1, 2026. Prices and model availability can change quickly, so this guide uses official pages where possible and labels recent coverage as discussion context. The practical takeaway is architectural: route by workload instead of betting everything on one model ID.
Why a router beats one default model
The Chinese model market is no longer a single "cheap alternative" bucket. DeepSeek, Kimi, GLM and Qwen now expose different trade-offs around context windows, cached input, long-horizon coding, regional availability and tool support. If your application uses one default model for every request, you are probably overpaying for simple tasks and under-testing the expensive tasks that actually affect user trust.
A production API gateway should separate three concerns. First, normalize the transport so developers can keep using OpenAI-compatible SDKs. Second, classify the workload before the call: short chat, long document reasoning, agentic coding, structured extraction, or fallback recovery. Third, attach a budget policy that knows how to price input, cached input and output tokens. AIWave's developer docs, pricing page and OpenAI migration guide are built around that pattern.
The reason this matters in August 2026 is that the official rate cards are diverging. DeepSeek's pricing page lists V4 Flash and V4 Pro with 1M context and separate cache-hit, cache-miss and output rates. Z.AI lists GLM-5.2 and GLM-5.1 at higher headline prices, but also lists cached input discounts and long-horizon coding positioning. Alibaba's Model Studio pricing page shows Qwen models with regional prices, tiered context ranges and cache notes. Kimi's platform docs expose Moonshot V1 prices and model-list APIs, while the last week of industry coverage has focused on Kimi K3 and open-weight economics. Those are not interchangeable signals.
Current pricing and capability signals
DeepSeek is the cleanest current example of cache economics. Its official docs list 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 cached input, $0.435 uncached input and $0.87 output. It also warns that peak/off-peak pricing is planned, which means production budgets should record request time as well as token counts.
Z.AI's pricing page lists GLM-5.2 at $1.4 input, $0.26 cached input and $4.4 output per 1M tokens, with cached storage marked as limited-time free. Its GLM-5.2 overview positions the model around 1M-token project-scale engineering context, function calling, structured output, MCP integration and long-horizon development tasks. That combination makes it a candidate for complex agent work, not a default choice for every short support reply.
Qwen pricing is more region-sensitive. Alibaba Model Studio lists Qwen3.7 and Qwen3.x families with regional deployment options, context tiers and cache/batch notes. A cost-aware router should not store a single global Qwen price unless your traffic really uses one region and one exact model. For developer tooling, Qwen remains attractive because it sits inside a broad cloud platform and can be paired with Model Studio workflows, but the cost model needs more metadata than "qwen is cheap."
Kimi requires a split view. Official Kimi platform docs list Moonshot V1 rates in dollars for the international site and provide a model-list endpoint that reports available models. Recent coverage from Tom's Hardware, Tom's Guide and other industry sites has centered on Kimi K3, open weights and the economics of large-context coding. That is valuable discussion context, but production API code should still verify the exact model ID and live platform billing page before presenting a hard budget to customers.
Decision table
| Workload | Primary route | Why | Fallback |
|---|---|---|---|
| Short support chat | DeepSeek V4 Flash or Qwen Plus tier | Low output cost and simple OpenAI-compatible integration | GLM lower-cost tier if policy requires Z.AI |
| Repeated long system prompt | DeepSeek V4 Flash | Official cache-hit price is extremely low when prefixes repeat | GLM-5.2 when engineering context quality matters more |
| Long-horizon coding agent | GLM-5.2 or Kimi-family model after evaluation | Both are positioned around long context and agentic coding; test tool adherence | DeepSeek V4 Pro for hard reasoning fallback |
| Regional Alibaba stack | Qwen through Model Studio | Cloud-native billing, deployment region choices and existing Alibaba workflows | AIWave multi-model endpoint for portability |
| Price-sensitive extraction | DeepSeek V4 Flash with strict max output | Extraction usually has bounded output and benefits from stable instructions | Qwen Plus if your schema tests pass |
The table intentionally uses routes instead of absolute winners. A model that looks cheapest per 1M input tokens can become expensive if it produces verbose reasoning tokens, misses cache, fails schema validation or requires multiple retries. A model with a higher headline rate can be cheaper for an agent if it completes a task in one pass. The router should therefore log task type, selected model, input tokens, cached input tokens, output tokens, retry count and validation result.
Runnable router code
The example below works with any OpenAI-compatible gateway. Set AIWAVE_API_KEY and optionally AIWAVE_BASE_URL. The router is deliberately small: classification remains explicit, prices are configuration data, and the request path is the standard OpenAI SDK.
# 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"),
)
@dataclass
class Route:
model: str
max_tokens: int
reason: str
def choose_route(task: str, estimated_input_tokens: int, stable_prefix: bool) -> Route:
task = task.lower()
if "refactor" in task or "agent" in task or estimated_input_tokens > 180_000:
return Route("glm-5.2", 4096, "long-horizon engineering context")
if stable_prefix and estimated_input_tokens > 20_000:
return Route("deepseek-v4-flash", 2048, "cache-heavy prompt")
if "schema" in task or "extract" in task:
return Route("deepseek-v4-flash", 1200, "bounded extraction")
return Route("qwen3.7-plus", 1600, "general chat fallback")
def ask(task: str, prompt: str, stable_prefix: bool = False) -> str:
route = choose_route(task, len(prompt) // 4, stable_prefix)
response = client.chat.completions.create(
model=route.model,
messages=[
{"role": "system", "content": "Return concise, verifiable answers."},
{"role": "user", "content": prompt},
],
max_tokens=route.max_tokens,
temperature=0.2,
)
print(f"model={route.model} reason={route.reason}")
return response.choices[0].message.content
print(ask("extract schema", "Extract vendor, price and model names from this invoice text."))
Do not hard-code rates into this function. Keep rates in a small database table with source URL, checked date, currency, region and model ID. When a provider changes pricing or renames a model, you should update data and tests without shipping a router rewrite. The companion AIWave guides on DeepSeek cache pricing, GLM integration and Qwen setup provide deeper per-model notes.
Evaluation workflow
A useful router evaluation has four layers. The first layer is syntax: does the model return valid JSON, respect tool-call shape and stream correctly through your SDK? The second layer is task quality: does it solve the actual ticket, extract the right fields or complete the code change? The third layer is cost: how many total, cached and output tokens were billed after retries? The fourth layer is operational behavior: latency, HTTP errors, rate limits and regional availability.
For agentic coding, run repository-shaped tasks instead of isolated prompts. Give each model the same task statement, the same tests and the same maximum spend. Score pass rate, files touched, test output, and whether the model followed constraints. For extraction, build a fixture set with messy PDFs, invoices and support messages; score parse validity and field-level accuracy. For chat, measure answer usefulness and refusal boundaries, but also enforce maximum output because cheap input is not helpful if output expands without control.
The final production pattern is simple. Use the cheapest model that passes the job-specific test, keep a stronger model as fallback, and make every fallback visible in analytics. When fallback rate rises, it is a product signal: prompts changed, documents changed, a provider changed behavior, or your primary model no longer fits the workload.