Model Routing for Coding Agents, Explained

Published October 15, 2026 · by the AQ team

Model routing means the harness picks the model for each request instead of you picking one for the whole session: a router classifies the task and sends easy work to a fast, cheap model and hard work to a frontier model. As of October 2026 it is a first-class feature of coding tools: Cursor routes agent requests through its ML-based Cursor Router, GitHub Copilot ships auto model selection across Chat, its CLI and its cloud agent, ChatGPT has routed between fast and reasoning models since GPT-5, and OpenRouter sells routing as an API primitive. Claude Code, Codex CLI and OpenCode, by contrast, run the model you set. This guide covers what a router can actually see, what routing does to cost, usage limits and reproducibility, and when pinning one model is still the right call.

What is model routing?

A model router is a small decision layer in front of a pool of models that chooses one per request, usually by classifying the prompt's task type and difficulty, then weighing price, capability and current availability. The idea predates the products: the RouteLLM paper (UC Berkeley, Anyscale and Canva, July 2024) trained routers on human preference data and reported, on its own benchmarks, cost reductions of over 85 percent on MT Bench while keeping 95 percent of GPT-4's quality. Products ship the same bet: most coding requests do not need the most expensive model, and a classifier can tell which ones do.

Three adjacent mechanisms get called routing but are not the same thing:

• Fallback switches models only when the primary fails. Claude Code, for example, can retry a turn on a configured fallback model when the primary is overloaded or unavailable: a reliability feature, not task-based selection.
• Role splits assign fixed models to fixed jobs. Claude Code's opusplan alias uses Opus during plan mode and Sonnet for execution; OpenCode's small_model option sends lightweight work like title generation to a cheaper model. The assignment is static.
• Effort dials change how hard one model thinks (reasoning effort in Codex, thinking budgets elsewhere) without changing which model runs.

True routing is dynamic: the same session can land on different models from one request to the next.

Which coding tools route models automatically? (October 2026)

Cursor relaunched Auto as the Cursor Router: a machine-learning classifier runs on each agent request and routes by task type and complexity, with the stated goal of picking the cheapest model that still produces comparable results. As of October 2026 routing is not configurable per request; you choose an optimization mode (Cost, the former Auto; Balance, the default for new users; or Intelligence for complex multi-step work), and all Auto modes bill at the routed model's list price. Models a team blocks are skipped.

GitHub Copilot's auto model selection, per its documentation as of October 2026, combines two systems: one tracks real-time model health and availability, the other evaluates task complexity. It is generally available in Copilot Chat, Copilot CLI, the GitHub Copilot app and the Copilot cloud agent, with Efficiency, Balance and Intelligence tiers in VS Code, the CLI and the app. Auto never selects models outside your plan or your administrator's policy, paid plans get a 10 percent discount on model costs when using auto, and every surface shows which model answered (hover over a response in Chat, or read it in the terminal in the CLI).

ChatGPT is where routing went mainstream: OpenAI's GPT-5 system card (August 2025) describes a real-time router picking between a fast model and a deeper reasoning model based on conversation type, complexity, tool needs and explicit intent (asking it to think hard counts), trained continuously on signals like model-switch behavior and measured correctness, with mini variants taking over once usage limits are hit. The API never got the router: API callers pick a model by name.

OpenRouter treats routing as an API product. Its Auto Router slug classifies each prompt into one of roughly 30 task types and ranks candidates by what OpenRouter's own users spend on that task type over a trailing 7-day window. You can restrict the pool with allow and exclude patterns or a cost tier, conversations stick to the model they landed on while it stays a top candidate, and the response's model field reports which model answered.

And where there is no router, say so plainly: Claude Code runs the alias or model you set, Codex CLI runs the model in its config file or flags, and OpenCode runs your configured model, each verified on the vendor's documentation in October 2026. Their automatic behaviors (fallback chains, opusplan, small_model) are real but fixed-role, not per-request selection.

What signals can a router use?

Across the products above, the inputs reduce to a short list:

• Task class and difficulty. The core signal everywhere: a rename is not a refactor, and classifiers can tell them apart from the prompt and context.
• Context size. A request carrying 300k tokens of repository context can only go to models whose context window fits it, which alone can decide the route.
• Price. Routers exist to spend less; Cursor states the cheapest-comparable-result goal outright, and OpenRouter exposes cost tiers.
• Availability and health. Copilot routes around degraded models in real time; Claude Code's fallback chain is this signal without the rest of the router.
• Policy and plan. Enterprise-facing routers exclude models an admin blocked or the plan does not include.
• Your stated intent. GPT-5's router listens for explicit cues, and most routers let a manual model pick override them entirely.

What routing means for cost and usage limits

Routing changes your bill from a price you chose to a distribution you influence. On usage-based pricing you pay the routed model's rate per request (Cursor bills Auto at the routed model's list price; Copilot charges for the model auto selects, minus its 10 percent discount on paid plans). That usually lands below always running the frontier model, but it also means two similar days can cost different amounts, and a router update can shift your average with no change on your side. On subscription plans the same logic applies to limits rather than dollars: a router that reaches for the expensive model burns a plan window faster, the dynamic behind Claude Code's usage limits and the subscription versus API credits tradeoff generally. ChatGPT inverts it: there the limit changes the routing, with mini models taking over at the cap.

What routing means for reproducibility

A routed session is not reproducible the way a pinned one is. The same prompt on the same repository can land on different models on different days because the router updated, the pool changed, a model degraded, or a policy shifted. That is fine for everyday work and bad for anything you need to compare: with a router in the loop, you no longer know what you measured. The practical hygiene: know where your tool reports the routed model (Copilot shows it per response, OpenRouter returns it in the model field, Cursor's visibility depends on team settings), record it when a run matters, and switch to a pinned model when the variable must hold still. A/B testing a new coding model on your own repo covers the controlled version of that comparison.

When is a pinned model the right call?

• Evaluations and bake-offs. When comparing models, harnesses or prompts, pin everything except the thing under test.
• Bisecting a regression. When agent output quality drops, you need to know whether the model changed under you before blaming your prompt or your repo.
• Long, stateful sessions. Mid-task switches can change style and judgment midstream; for a delicate multi-hour refactor, one model the whole way is easier to review.
• Compliance. If policy says which models may see your code, a pin is simpler to attest than a router plus an exclusion list.
• Learning a model's character. Calibrated trust comes from watching the same model work for a while.

For everything else (routine fixes, small features, triage) the router's bet is usually right: most requests do not need the model you would have picked by habit. Which harness you run matters more than which router it ships; the coding agent harness directory maps the field.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. Agents run as the real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, so each CLI's own model behavior, routed or pinned, is exactly what you get, under your own Claude or OpenAI login for that CLI (AQ never marks up usage on your own subscriptions). Sessions stream live to the browser, survive a closed laptop, and resume from any device, and teammates can open the same workspace and watch the same live session: run the task, see what the model did, decide together.

What AQ adds to a model comparison is isolation and persistence. Every workspace gets its own git worktree on its own branch with dependencies installed, so running the same task twice, one session pinned and one routed, or one on Claude Code and one on Codex, means two workspaces that cannot collide, both still running after everyone goes home. The Free plan is a personal sandbox for one person, nothing to install, no time limit; the Team plan is $50 per user per month early access (standard $200, billed monthly), covering VMs you connect from your own cloud or a dedicated always-on AQ-managed VM, rate locked for your first 12 months.