Model routing for AI coding agent pipelines

Why route at all

Each step of a pipeline asks for something different. Planning a change across a codebase needs depth; labelling an issue or summarising a diff does not. Sending every step to the strongest model wastes money, and sending every step to the cheapest one costs quality where it matters.

Routing means deciding per step. The question is who decides and in which order.

The resolution order in DevFlow

Before each agent run, a resolver walks four levels for the run's role and stops at the first match:

1. an override set on the task for that role;
2. an override set on the workspace for that role;
3. the tier the role belongs to, fast, pro or max, each bound to a backend and a model in settings;
4. the flat workspace default, openrouter/minimax/minimax-m3 unless an owner sets another.

The flat default only applies when a tier is unset: a newly created workspace starts with no tiers until an owner binds them, while a migration seeded tiers on every workspace that already existed. Task overrides can be edited only while the task is idle, planning, in plan review or failed. Workspace overrides cover auxiliary roles too, such as the finding advisor, the diagnostician, the build doctor, the expert, chat and Sentry triage, and these per-role overrides exist for cost control.

A planning override only takes effect if it is set before planning starts, while the task is still idle or, before a re-plan, failed.

A worked example

Suppose a workspace binds its max tier to a strong model and its fast tier to a cheap one, and pins the verifier for all of its tasks. On one task, the user also overrides the implementer. Planning then runs on the max tier, the summarizer on the fast tier, the verifier on its workspace pin and the implementer on the task override.

Guard rails

The Claude Code backend is off unless the operator enables it. A selection that still points at Claude Code is moved to OpenCode, together with the workspace's OpenCode model or the instance default, so a run never starts with an empty one. The same rule covers legacy rows and overrides saved before the operator switched Claude Code off.

Ids starting with ollama/ are rejected by the settings validators, so routing can never point at an Ollama endpoint.

Deciding with data

DevFlow's dashboard joins recorded spend per role and model with verification results for the implementer role: the clean-verify rate, the density of review findings, the failed rate and how often rework was involved. Synthetic rows, such as reasoning bookkeeping and the final holistic review, are left out of the comparison.

The dashboard suggests a cheaper implementer model only when both the current and the candidate model have at least 10 verified subtasks, the candidate's clean rate is no more than 5 points below the current one and its spend per subtask is at most half.

These suggestions are read-only hints. Changing a route is always a person's decision, made through the same override settings, and an edit to a task's overrides replaces that task's whole override map in one request.