Model routing
A policy of directing each task to a different AI model based on risk, complexity or cost, instead of using a single model for everything.
Definition
Model routing means defining explicit rules for which model handles which task: a cheap model for mechanical work (boilerplate generation, simple unit tests), a more expensive model for architecture, complex refactoring or subtle bug hunting. It's not one session = one model, but a documented task → model mapping, whether applied manually or automatically through a proxy/gateway routing on defined criteria.
postcursors perspective
Model routing is relevant as an explicit policy, especially at the scale of a team budget — it's a concrete way to control cost without sacrificing quality where it matters. The trap: calling "routing" what is actually just individual tool-hopping, switching models with no written rule and no measurement, driven by the latest release or the mood of the day.
In practice
A team running Kilo Code on OVH AI Gateway can route to Gemini by default for everyday work, and to Claude Sonnet via the direct Anthropic API for architecture and complex refactoring. Routing by task type — documented, not improvised session by session — is the maturity step that follows adopting a single model.
Common misconceptions
- ✗ Calling it 'routing' when it's actually switching models at random based on the latest release or a mood, with no written rule and no measured outcome
- ✗ Routing purely on token price without accounting for the quality produced for the task type at hand