Skip to content
Definition

Model task router

A model task router lets an AI coding agent use different models for different jobs in the same session, so cheap models handle simple work like searching and strong models handle the parts that need them.

The idea, explained

Agentic coding workloads are not uniform. A single task fans out into many sub-jobs: reading files, running searches, navigating a dependency graph, drafting code, reviewing the diff, summarizing symbols, and compacting context when the window fills. These jobs differ enormously in how much reasoning they actually require. Reading and grepping is mostly retrieval. Writing a correct multi-file change is where model quality pays off. A task router exploits that asymmetry by mapping each job type ("slot") to a model rather than forcing one model to do everything.

The motivation is mostly cost and latency. Frontier models are priced at a large multiple of fast/cheap models, and a typical agent run spends the majority of its tokens on exploration and bookkeeping rather than on the final edit. Routing the high-volume, low-stakes work to a cheap model and reserving the expensive model for code generation can cut per-task spend severalfold with little or no quality loss, while also reducing wall-clock time because the cheap models tend to be faster.

Routing decisions are usually made by job category, not by trying to predict difficulty per prompt. Common slots include exploration/read-only research, code editing, web search, post-edit cleanup, adversarial review, context compaction, and short summarization. Resolution is typically layered: a configured model for the slot, then a default, then the session's active model as a fallback. This is distinct from provider-side request routing or "model auto-select" features that pick one model per chat turn, a task router operates inside one task and runs several models concurrently across its sub-agents.

The main trade-offs are configuration overhead and the risk of under-provisioning a slot (for example, putting too weak a model on verification or compaction, where mistakes silently degrade output). Done well, it is one of the biggest cost savings available to an agent, because it targets the structural fact that most agent tokens are spent thinking about code rather than writing it.