models

6 posts with the tag “models”

Qwen coding plans in 2026: what you actually get

Jul 9, 2026

Qwen3-Coder — Alibaba’s open-weights coder family — is one of the most capable coding models you can run over an API, and one of the most searched-for. If you want to run it as your daily coding model, you have a few realistic routes. As with Kimi and GLM, they differ less in headline price than in cost shape: what happens to your bill and your workflow when a heavy week hits.

Evaluating Qwen coding plans? Here’s how flat-rate unlimited access to comparable open-weights models stacks up. We don’t serve Qwen — but if what you’re really after is a fixed monthly bill for a capable open-weights coder, the same cost-shape question applies to models like Kimi K2.7, GLM 5.2, DeepSeek V4 Flash, MiMo v2.5, and MiniMax M3. Compare the flat-rate pools →

Route 1: the official Qwen Coding Plan

Alibaba Cloud sells a subscription Coding Plan on Model Studio aimed specifically at coding-tool usage of Qwen (plus a few third-party models). It’s first-party access, integrated with Qwen Code and compatible with Claude Code, Cline, and Cursor, and the Qwen coder models — qwen3-coder-plus, qwen3-coder-next, and the newer qwen3.x-plus line — arrive there first.

The trade-off is that the plan is quota-based: each tier grants a request allowance that resets on a schedule — with per-few-hours, weekly, and monthly request caps — and burning through it mid-refactor means waiting for the reset or moving up a tier. The tier lineup itself has already shifted once in 2026 (the entry-level Lite tier stopped accepting new orders), so any number printed here would go stale — check Alibaba’s Coding Plan page for the current tiers and quotas.

Good fit: you want first-party access to the newest Qwen coder models and your volume fits inside a tier’s request quota.

Route 2: per-token APIs

Qwen3-Coder is available per-token from Alibaba’s Model Studio / DashScope API and from several aggregators. No tiers, no resets — you pay for exactly the tokens you burn, which is ideal while you’re evaluating the model or your usage is light. New Model Studio accounts also get a time-limited free-token trial (region-restricted, expiring after a fixed window), useful for a first look — see Alibaba’s pricing page for the current allowance.

The catch is structural, not Qwen-specific: coding agents re-send their whole context on every tool call, so token volume compounds with every iteration. A capable coder will happily churn through long agent sessions — great for output, open-ended for the invoice. Per-token Qwen is cheap per request and unpredictable per month.

Good fit: a few million tokens a month, spiky schedules, or benchmarking before committing.

Route 3: unlimited time blocks on comparable open-weights models

The third shape is the one we sell, so apply the usual discount for self-interest — and note the honest caveat up front: we don’t serve Qwen. What we offer is the same cost shape for a lineup of comparable open-weights coders. You reserve one or more daily 8-hour time blocks and get unlimited usage during them: no token allowances, no request quotas, no resets — a monthly number that’s fixed the day you subscribe. Capacity is shaped by per-key concurrency instead of token or request budgets, so an agent that loops all afternoon changes nothing on the bill.

Two things matter if you’re weighing this against a Qwen plan:

Comparable models, one fee. A Frontier Pool block covers Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 (1M context); the Core Pool covers DeepSeek V4 Flash and MiMo v2.5 — all open-weights, switchable per request. If you were choosing Qwen for capability-per-dollar, these are in the same class.
It runs in the same tools. The API speaks both the Anthropic and OpenAI formats, so it drops into Claude Code, Cline, Roo Code, or Qwen Code — no wrapper, just a base-URL change.

Current block pricing is on the pools page.

Good fit: you want a fixed monthly bill for a capable open-weights coder and predictable working hours — and you’re not locked to the Qwen name specifically.

The three routes at a glance

Route	Cost shape	Limits	Models	Best for
Official Qwen Coding Plan	Fixed monthly subscription	Request quotas that reset (per-few-hours / weekly / monthly)	First-party Qwen coder models (plus some third-party)	First-party Qwen, volume inside quota
Per-token API	Pay per token used	None — spend scales with usage	Any Qwen model on Model Studio / aggregators	Light, spiky, or exploratory use
Flat-rate time blocks (us)	Fixed monthly, per block	Concurrency-shaped; no token or request caps	Comparable open-weights (Kimi, GLM, DeepSeek, MiMo, MiniMax) — not Qwen	Predictable hours, fixed bill, model-agnostic

When to use what

Official Qwen Coding Plan — first-party access, day-one Qwen coder updates, your volume fits the request quota. Per-token — light, spiky, or exploratory usage; pay only for what you burn. Flat-rate time blocks — heavy daily coding in predictable hours where you want a constant bill and you’re open to a comparable open-weights model rather than Qwen specifically.

All three answer the same underlying question. It isn’t “which Qwen tier is cheapest” — it’s which cost shape matches how you work, and whether you need the Qwen name or just a capable open-weights coder at a fixed price.

CheapestInference serves Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 (Frontier Pool) and DeepSeek V4 Flash and MiMo v2.5 (Core Pool) through one OpenAI- and Anthropic-compatible API on unlimited time-block subscriptions. We do not serve Qwen. See the pools or get started.

Kimi coding plans in 2026: K2.7, K2.6, and what you actually get

Jul 8, 2026

Kimi K2.7 — Moonshot AI’s open-weights flagship — is currently one of the most capable coding models you can run over an API, and its predecessor K2.6 remains a strong, cheaper-to-serve option. If you want Kimi as your daily coding model, you have three realistic routes. As with GLM, they differ less in headline price than in cost shape: what happens to your bill and your workflow when a heavy week hits.

Route 1: the official Kimi coding plan

Moonshot sells subscription plans aimed specifically at coding-tool usage of Kimi. It’s first-party access, tightly integrated with their own tooling, and the models arrive there first. The trade-off is that the plans are quota-based: each tier grants a usage allowance that resets on a schedule, and burning through it mid-refactor means waiting for the reset or moving up a tier. Tiers and allowances change often enough that any number printed here would go stale — check Moonshot’s pricing page for the current shape.

Good fit: you want first-party access and your coding volume fits comfortably inside a tier’s allowance.

Route 2: per-token APIs

Kimi K2.7 and K2.6 are available per-token from Moonshot’s open platform and from several aggregators. No tiers, no resets — you pay for exactly the tokens you burn, which is ideal while you’re evaluating the model or your usage is light.

The catch is structural, not Kimi-specific: coding agents re-send their whole context on every tool call, so token volume compounds with every iteration. A model as eager to work as K2.7 will happily churn through long agent sessions — great for output, open-ended for the invoice. Per-token Kimi is cheap per request and unpredictable per month.

Good fit: a few million tokens a month, spiky schedules, or benchmarking before committing.

Route 3: unlimited time blocks

The third shape is the one we sell, so apply the usual discount for self-interest — but the mechanics are easy to verify. You reserve one or more daily 8-hour time blocks and get unlimited Kimi usage during them: no token allowances, no resets, a monthly number that’s fixed the day you subscribe. Capacity is shaped by per-key concurrency instead of token budgets, so an agent that loops all afternoon changes nothing on the bill.

Three properties matter for coding specifically:

Both Kimis under one fee. A Frontier Pool block covers Kimi K2.7 and K2.6 (model ids kimi-k2.7, kimi-k2.6), switchable per request — use K2.7 for the hard problems and K2.6 where it’s already enough.
It runs inside Claude Code natively. The API speaks both the Anthropic and OpenAI formats, so Kimi drops into Claude Code, Cline, Roo Code, or whatever tool you already use — no wrapper, just a base-URL change.
The subscription isn’t Kimi-only. The same block also covers GLM 5.2 and MiniMax M3 (1M context). If Kimi is your main model but not your only one, that’s four coding plans for the price of one.

Current block pricing is on the pools page.

Good fit: Kimi is your daily driver, your working hours are roughly predictable, and you want the bill to be a constant instead of a variable.

When to use what

Official Moonshot plan — first-party access, day-one model updates, your volume fits the quota. Per-token — light, spiky, or exploratory usage; pay only for what you burn. Time-block unlimited — heavy daily coding or agent work in predictable hours; fixed cost, both K2 generations plus two more frontier models under one fee.

All three routes serve the same open-weights models. The question isn’t “which Kimi is better” — it’s which cost shape matches how you work.

GLM 5.2 coding plans in 2026: what you actually get

Jul 6, 2026

GLM 5.2 — Zhipu AI’s (Z.ai) frontier coding and reasoning model — has become one of the most searched-for open-weights models for coding work. If you’re trying to run it as your daily coding model, you have three realistic routes, and they differ less in price than in cost shape: what happens to your bill and your workflow when usage spikes.

Route 1: the official Z.ai coding plan

Z.ai sells subscription tiers aimed at coding-tool usage of GLM. You get first-party access and tight integration with their own tooling. The trade-off is that the plans are quota-based: each tier grants an amount of usage that resets on a schedule, and hitting the ceiling mid-task means waiting or upgrading. For usage details and current tiers, check Z.ai’s pricing page — quotas and tiers change often enough that any number printed here would go stale.

Good fit: you want first-party access and your usage fits comfortably inside a tier’s quota.

Route 2: per-token APIs

GLM 5.2 is available per-token from several inference providers and aggregators. No quotas, no tiers — you pay for exactly what you use, which is ideal for light or unpredictable usage.

The catch is the same one that applies to every agent workload: coding agents re-send their whole context on every tool call, so token volume scales with iterations. Per-token GLM is cheap per request and open-ended per month — the bill is a dependent variable of how hard your agent worked.

Good fit: a few million tokens a month, spiky schedules, or evaluation before committing to anything.

Route 3: unlimited time blocks

The third shape is the one we sell, so discount accordingly — but the mechanics are simple to verify. You reserve one or more daily 8-hour time blocks and get unlimited GLM 5.2 usage during them: no token caps, no quota resets, a fixed monthly number decided at subscription time. Capacity is shaped by per-key concurrency rather than token budgets, so a runaway agent loop changes nothing on the invoice.

Two properties matter for coding specifically:

It works as a drop-in coding plan. The API is Anthropic- and OpenAI-compatible, so GLM 5.2 runs inside Claude Code, Cline, Roo Code, or any tool you already use — model id glm-5.2.
The subscription isn’t GLM-only. A Frontier Pool block covers Kimi K2.7, Kimi K2.6, and MiniMax M3 (1M context) too, switchable per request. If GLM is your main model but not your only one, that’s four coding plans for the price of one.

Current block pricing is on the pools page.

Good fit: GLM is your daily-driver coding model, your hours are roughly predictable, and you want the bill to be a constant.

When to use what

Official Z.ai plan — first-party access, quota fits your volume, you use their tooling. Per-token — light, spiky, or exploratory usage; pay only for what you burn. Time-block unlimited — heavy daily coding or agent work in predictable hours; fixed cost, no quota anxiety, multiple frontier models under one fee.

All three serve the same open-weights model. The question isn’t “which GLM is better” — it’s which cost shape matches how you work.

CheapestInference serves GLM 5.2, Kimi K2.7, Kimi K2.6, and MiniMax M3 (Frontier Pool, from $44.20/mo billed annually) and DeepSeek V4 Flash and MiMo v2.5 (Core Pool) through one OpenAI- and Anthropic-compatible API on unlimited time-block subscriptions. See the pools or get started.

Unlimited DeepSeek: what a flat monthly subscription changes

Jul 6, 2026

DeepSeek has a well-earned reputation as the budget option among frontier-quality models. Per-token rates for DeepSeek V4 Flash run around $0.14 per million input tokens and $0.28 per million output — an order of magnitude below closed-source flagships.

So why would anyone pay a flat monthly fee for it?

Because per-token pricing has a property that doesn’t care how low the rate is: cost scales with tokens, and agent tokens scale with iterations, not value. Cheap per token is not the same as cheap per month.

The math nobody runs until the invoice arrives

A coding agent re-sends its growing context on every tool call. A typical task burns 300–500K tokens; an active developer runs dozens of tasks a day. Being conservative:

	Tokens/day	Tokens/month	Per-token cost (V4 Flash rates)
Light use	2M	60M	~$11/mo
Daily driver	15M	450M	~$80/mo
Heavy agent loops	50M	1.5B	~$270/mo

The rate is tiny. The bill is not — and it’s unpredictable, because next month’s iteration count is unknowable in advance.

A time-block subscription inverts this: you reserve a daily 8-hour window and usage inside it is unlimited. The number on your invoice is decided when you subscribe, not by how many times your agent loops. DeepSeek V4 Flash is served in the Core Pool — current pricing is on the pools page.

At “daily driver” volume, the flat block is cheaper than even DeepSeek’s per-token rates — and the gap only widens from there.

What you get with the subscription

DeepSeek V4 Flash with a 1M-token context window — whole codebases, long documents, extended agent runs in a single request.
No token caps during your blocks. The plan is unlimited in tokens; capacity is shaped by per-key concurrency instead, so one busy key never affects another.
MiMo v2.5 included. A Core Pool subscription covers every model in the pool — Xiaomi’s MiMo v2.5 shares the same 1M-context class.
Drop-in API. OpenAI-compatible (/v1/chat/completions) and Anthropic-compatible (/anthropic/v1/messages) — point your SDK, Cline, or Claude Code at it with model id deepseek-v4-flash.

from openai import OpenAI

client = OpenAI(
    base_url="https://api.cheapestinference.com/v1",
    api_key="sk-...",  # subscriber key
)
r = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[{"role": "user", "content": "Review this repo for race conditions: ..."}],
)

When per-token DeepSeek is still the right call

Honesty clause: if your usage is light or spiky — a few million tokens a month, unpredictable hours — per-token is cheaper and you should use it. The flat block wins when usage is heavy and concentrated in predictable hours: agent development, batch processing, a working day of assisted coding. That’s the break-even logic in one sentence; the full break-even analysis is here.

CheapestInference serves DeepSeek V4 Flash and MiMo v2.5 (Core Pool, from $5.94/mo billed annually) and Kimi K2.7, Kimi K2.6, GLM 5.2, and MiniMax M3 (Frontier Pool) through one OpenAI- and Anthropic-compatible API on unlimited time-block subscriptions. See the pools or get started.

Xiaomi's MiMo v2.5: the 1M-context model almost nobody is serving

Jul 6, 2026

First, a disambiguation for the search engines: this is about MiMo, Xiaomi’s open-weights large language model — not MIMO antenna technology. If you came here for multipath radio, wrong blog.

MiMo v2.5 is the model Xiaomi’s LLM lab ships as its fast, efficient workhorse: small enough to be quick and cheap to run, with a ~1M-token context window that puts it in a class usually reserved for much more expensive models. It’s open weights, and — unlike most of the open-weights catalog — very few providers serve it over an API at all.

What it’s actually good at

MiMo v2.5 is not a frontier reasoning model, and pretending otherwise helps nobody. Where it earns its keep:

Long-context work on a budget. Feed it an entire codebase, a contract stack, or weeks of chat logs in one request. Most tasks over long inputs are retrieval-and-synthesis, not deep reasoning — exactly the regime where a fast model with 1M context beats a smarter model with 128K.
High-volume agent plumbing. Sub-agents, summarizers, extractors, classifiers — the loops that run hundreds of times a day and quietly dominate token bills.
Drafting and iteration speed. It’s fast. For inner-loop coding assistance, latency often matters more than the last few points of benchmark quality.

For frontier-tier reasoning, use a frontier-tier model — that’s what the Frontier Pool is for. MiMo’s job is to make the other 80% of your token volume cost almost nothing.

The fastest way to try it

MiMo v2.5 is served in the Core Pool alongside DeepSeek V4 Flash, on unlimited time-block subscriptions — flat monthly fee, no per-token billing. One curl:

curl https://api.cheapestinference.com/v1/chat/completions \
  -H "Authorization: Bearer sk-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mimo-v2.5",
    "messages": [{"role": "user", "content": "Summarize the attached spec..."}]
  }'

It speaks both the OpenAI and Anthropic API shapes, so it also works as a model in Claude Code, Cline, or any OpenAI-compatible client — set model id mimo-v2.5. Full details on the MiMo v2.5 model page.

Why serve it at all?

Because the interesting frontier in 2026 isn’t only “smartest model” — it’s capability per dollar at volume. A subscription covers every model in its pool, so the practical pattern is: route the hard 20% to a frontier model, and everything else to a model like MiMo where unlimited usage costs a flat few dollars a month. Your effective blended cost drops without touching quality where quality matters.

Building a multi-model architecture: route requests to the right LLM

Mar 19, 2026

Using one model for everything is the simplest architecture. It’s also the most wasteful. A 685B-parameter reasoning model answering “what’s the weather?” is like hiring a PhD to sort mail.

This guide covers how to use a small, fast model to classify incoming requests and route them to the right specialist. The result: lower latency, lower cost, and often better quality — because each model handles what it’s actually good at.

The problem with single-model architectures

Most applications start with one model:

User request --> Large Model --> Response

This works, but every request — simple or complex — pays the same latency and cost penalty. When 60% of your traffic is simple classification, FAQ, or extraction, you’re burning expensive compute on tasks a small model handles equally well.

Llama 3.1 8B

~200 t/s

DeepSeek V3.2

~60 t/s

DeepSeek R1

~30 t/s

The gap between Llama 8B and R1 is nearly 7x in throughput. Routing simple requests to the small model saves that difference on every request.

The multi-model architecture

User request --> Router (GLM 5.2) --> classify intent
                                          |
                  +-----------+-----------+-----------+
                  |           |           |           |
           simple/general  reasoning    code        agent
                  |           |           |           |
               GLM 5.2    MiniMax M3  MiniMax M3  Kimi K2.7
                  |           |           |           |
                  +-----+-----+-----+-----+
                        |
                     Response

Two stages:

Classify — The router model reads the user’s message and outputs a category. A fast model returns this in a fraction of a second.
Route — Based on the category, forward the request to the appropriate specialist model.

The router adds minimal overhead (~200ms) but saves significant compute by keeping simple requests away from expensive models.

Step 1: Classify with a fast model

A fast, lightweight model makes a good router. With low TTFT and a short, single-word output, the classification step costs almost nothing and completes before the user notices. (On CheapestInference, DeepSeek V4 Flash or MiMo v2.5 in the Core pool are natural router models; the example below uses GLM 5.2 so everything runs on one Frontier subscription.)

The classification prompt is simple — you want a single-word category, not a conversation:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.cheapestinference.com/v1",
    api_key="your-api-key"
)

def classify_request(user_message: str) -> str:
    """Classify a user message into a routing category."""
    response = client.chat.completions.create(
        model="glm-5.2",
        messages=[
            {
                "role": "system",
                "content": (
                    "Classify the user's message into exactly one category. "
                    "Respond with only the category name, nothing else.\n\n"
                    "Categories:\n"
                    "- simple: greetings, FAQ, simple factual questions\n"
                    "- general: complex questions, analysis, writing, summarization\n"
                    "- reasoning: math, logic, multi-step problems, science\n"
                    "- code: code generation, debugging, refactoring, technical implementation\n"
                    "- agent: tasks requiring tool use, web search, or multi-step execution"
                )
            },
            {"role": "user", "content": user_message}
        ],
        max_tokens=10,
        temperature=0
    )
    category = response.choices[0].message.content.strip().lower()
    # Default to general if classification is unclear
    valid = {"simple", "general", "reasoning", "code", "agent"}
    return category if category in valid else "general"

The key details: max_tokens=10 because we only need one word. temperature=0 for deterministic routing. The system prompt is explicit about format — no preamble, just the category.

Step 2: Route to the specialist

Each category maps to a model optimized for that task:

# Model routing table
ROUTE_TABLE = {
    "simple":    "glm-5.2",
    "general":   "glm-5.2",
    "reasoning": "MiniMax-M3",
    "code":      "MiniMax-M3",
    "agent":     "kimi-k2.7",
}

def route_request(user_message: str, conversation_history: list) -> str:
    """Classify and route a request to the appropriate model."""
    category = classify_request(user_message)
    model = ROUTE_TABLE[category]

    response = client.chat.completions.create(
        model=model,
        messages=conversation_history + [
            {"role": "user", "content": user_message}
        ],
        stream=True
    )

    # Stream the response back
    full_response = ""
    for chunk in response:
        if chunk.choices[0].delta.content:
            content = chunk.choices[0].delta.content
            full_response += content
            print(content, end="", flush=True)

    return full_response

Notice that simple requests route back to GLM 5.2 — the same model that did the classification. For simple queries, the router overhead is effectively zero because the specialist is the same model and can reuse the warm connection.

Step 3: Handle edge cases

The basic router works for most traffic, but production systems need a few refinements:

def route_request_production(
    user_message: str,
    conversation_history: list,
    force_model: str = None
) -> tuple[str, str]:
    """Production router with overrides and fallback."""

    # Allow explicit model override (for power users or testing)
    if force_model:
        model = force_model
        category = "override"
    else:
        category = classify_request(user_message)
        model = ROUTE_TABLE[category]

    try:
        response = client.chat.completions.create(
            model=model,
            messages=conversation_history + [
                {"role": "user", "content": user_message}
            ]
        )
        return response.choices[0].message.content, category

    except Exception:
        # Fallback to GLM 5.2 if the specialist is unavailable
        fallback = "glm-5.2"
        response = client.chat.completions.create(
            model=fallback,
            messages=conversation_history + [
                {"role": "user", "content": user_message}
            ]
        )
        return response.choices[0].message.content, f"{category}->fallback"

Three patterns worth noting:

Force model — Let callers bypass routing when they know what they need.
Fallback — If a specialist model is down, fall back to GLM 5.2. It handles everything reasonably well.
Return the category — Log which route each request takes. You’ll need this data to tune the system.

Cost and latency comparison

Consider a workload of 1,000 requests with this distribution: 600 simple, 300 general, 70 reasoning, 30 code. Average 500 input tokens, 200 output tokens per request.

Single-model approach (everything on V3.2)

Avg latency

~4.5s

All 1000 reqs

V3.2 only

Every request waits for V3.2’s ~1.2s TTFT plus generation time at ~60 t/s. Simple questions get the same treatment as complex analysis.

Multi-model approach (routed)

Simple (600)

~1.2s (8B)

General (300)

~4.7s (V3.2)

Reasoning (70)

~9.0s (R1)

Code (30)

~3.5s (Coder)

The weighted average latency drops to approximately 2.7s — a 40% reduction. The 600 simple requests finish in ~1.2s instead of ~4.5s. That’s a 3.7x improvement for the majority of your traffic.

The 70 reasoning requests are slower individually (~9s vs ~4.5s) because R1 generates chain-of-thought tokens. But the quality on those specific requests is significantly better — R1 scores 50.2% on HLE versus V3.2’s 39.3%.

You get faster averages and better quality on the hard tail.

Real example: a support chatbot

A customer support chatbot receives three types of requests:

FAQ (60%) — “What are your business hours?” / “How do I reset my password?”
Complex support (30%) — “I was charged twice for order #12345, can you investigate?”
Technical issues (10%) — “Your API returns 500 when I send multipart form data with UTF-8 filenames”

Without routing

All requests go to DeepSeek V3.2. FAQs get correct answers but with unnecessary latency. Technical issues get decent answers but miss edge cases that a code-specialized model would catch.

With routing

SUPPORT_ROUTES = {
    "simple":    "glm-5.2",       # FAQ, greetings
    "general":   "glm-5.2",       # Complex support
    "reasoning": "glm-5.2",       # Investigations
    "code":      "glm-5.2",       # Technical issues
    "agent":     "kimi-k2.7",     # Multi-step resolution
}

FAQs resolve quickly via GLM 5.2. Complex support issues get GLM 5.2’s full analytical capability. Technical problems also route to GLM 5.2, which understands the code context well. If a support issue requires looking up order data via API, it routes to Kimi K2.7 for tool-assisted resolution.

The classification step adds ~200ms. For the 60% of requests that drop from ~4.5s to ~1.2s, that’s an invisible cost.

When NOT to use multi-model routing

Routing adds complexity. Skip it when:

All your requests are the same type. If you’re building a code editor, just use a single coding model like GLM 5.2. No routing needed.
You have fewer than 100 requests/day. The cost savings don’t justify the engineering overhead at low volume.
Latency doesn’t matter. For batch processing or async workloads, a single capable model is simpler.
Your classification accuracy is low. If the router misclassifies frequently, you get worse results than a single good model. Test the classifier on real traffic before deploying.

The sweet spot is high-volume applications with diverse request types — chatbots, API gateways, developer tools, and customer-facing products where response time directly affects user experience.

Implementation checklist

Log your traffic. Before building a router, understand your request distribution. What percentage is simple? Complex? Code?
Start with two tiers. A fast, lighter model for simple requests, and a stronger model like MiniMax M3 for everything that needs deep reasoning, code, or long context. Add specialists only when you have data showing they help.
Measure classification accuracy. Sample 100 requests, manually label them, compare against the router’s output. Target >90% accuracy.
Add fallback. Every specialist route should fall back to GLM 5.2 if the specialist is unavailable.
Monitor per-route metrics. Track latency, cost, and quality per category. This tells you where to optimize next.

The routing pattern works with any OpenAI-compatible API. The code examples in this guide use the model ids we actually serve — GLM 5.2, MiniMax M3, and Kimi K2.7 from our Frontier pool (DeepSeek V4 Flash and MiMo v2.5 in the Core pool make great router models too); the throughput and latency comparisons cite ecosystem reference models like Llama and DeepSeek V3.2/R1 for context. If you’re building a platform that needs LLM access for your users, see how per-key plans work.

Sources: Artificial Analysis Leaderboard · DeepSeek V3.2 · HLE Leaderboard