Routing Gemini, GPT-5.6, Grok, GLM, Kimi, MiniMax, and Qwen

Gemini 3.5 Flash, GPT-5.6, Grok 4.5, GLM-5.1, Kimi K2.5, MiniMax M2.7, Qwen 3.6 Plus: seven names on the current shortlist, and two of the version strings were already stale before anyone wrote a line of routing config.

the roster on my desk, and two names that are already wrong

Z.AI's own documentation lists GLM-5.1, not the GLM-5.2 that keeps turning up in comparison threads.

Moonshot documents Kimi K2.5, not K2.7.

Small thing, except it isn't. A version number that doesn't match the vendor's own docs has no business near a benchmark table or a production config file, full stop. It goes on a watchlist instead, checked again before it gets trusted with real traffic.

The bigger point sitting behind that correction: these seven models are not rungs on one ladder you climb by price or by parameter count. They split across speed, reasoning depth, multimodal support, tool calling, context window, regional availability, and price in combinations that refuse to line up neatly against each other. Pick a single "best" model out of that set and you throw away most of what made the set worth assembling in the first place.

That is the whole argument for running a portfolio instead of crowning a favorite. It just needs enough structure underneath it that routing work into the right slot doesn't depend on someone eyeballing every request as it arrives.

five lanes, not one ladder

Real traffic sorts into a small number of classes once you actually look at it: fast interactive work, high-volume structured automation, coding and tool use, long-document or multimodal jobs, and the hard escalations nobody wants auto-approved.

Each lane needs its own contract before a single candidate model gets tested against it:

• a latency target
• a quality gate
• a data-residency rule
• a maximum context size
• a cost ceiling

Only once those five things exist per lane does comparing candidate models mean anything. Skip that step and you're comparing vibes with extra steps.

Whatever harness runs the comparison has to log the unglamorous stuff: exact model ID, provider API version, prompt revision, tool schema, token categories, queue time, first-token latency, completion time, review outcome. Replay the identical task set through every provider while respecting each one's own documented conversation format, rather than flattening everything through a lowest-common-denominator wrapper. "OpenAI compatible" describes a transport convenience, nothing about whether streaming, tool calls, error handling, or token accounting behave the same way underneath.

filters first, cleverness never

A plain rules router covers almost every case you will hit early on, and it is worth resisting the urge to swap it for something smarter before you have actually earned the need.

Sensitivity and residency are hard filters: fail either one and the candidate is out, no appeal. Required modality and required tools are capability filters, checked next. Context length and output limits are fit filters after that. Only once a candidate clears all three do you weigh it against the others, and the winner is whichever one clears the task's evaluation bar and its latency objective at the lowest price.

Escalate when validation fails, or when the request declares itself a genuinely harder class than the lane assumed. That's it.

Don't reach for a second, pricier model whose only job is deciding where to send the first one, not until logs actually show that hand-written rules can't separate the traffic anymore. Learned routing is not free: it adds latency, it adds cost, and it hands you a brand-new model to evaluate on top of the ones you already had to evaluate. Most systems already know, straight from the request itself, whether an image is attached, which tools it needs, how big it is, and whether a human already flagged it high-stakes. Building an autorouter covers the deeper case for keeping the router deliberately dumb, if you want the long version.

Cache design belongs inside the routing layer, not bolted on afterward. Stable system prompts and schemas should become reusable prefixes wherever a provider supports them, and cache keys need to include the model, the prompt version, the permission set, the tenant, and the relevant data version. Matching on semantic similarity alone is unsafe the moment an answer is time-sensitive or authorization-sensitive: a near-identical question asked under different permissions is not a cache hit, it's a leak waiting for a demo.

the ground moves under the alias

None of this stays put. Aliases get repointed, previews vanish, and defaults change without an announcement that reaches you in time to matter.

Pin exact versions for any workflow that needs reproducible output. Subscribe to each vendor's release and deprecation notices directly, because model migration reality is that the deprecation calendar rarely runs on the same clock as the marketing calendar. Canary every alias update against the same evaluation set you used the first time around, not a fresh one built to flatter the new version.

Keep the provider-specific adapters sitting at the gateway boundary, so the rest of the application only ever talks to one internal response contract, regardless of which of the seven names actually served the request underneath it.

The router needs to say, out loud, which provider handled each request. Users and operators both need that visibility, especially anywhere privacy, cost, or tool permissions differ across candidates. A silent fallback from a local or approved route out to an external frontier model is not some harmless convenience quietly smoothing the rough edges off. It is a defect in the architecture, and it should fail loud instead of failing soft.

If I keep exactly one rule out of all of this: the router names its choice, every single time, or it does not go anywhere near production.