Model tiers: fast, pro and max model slots

The problem tiers solve

DevFlow runs twenty or more agent roles. Choosing a model for every role separately is more choice than most teams want to maintain, and most roles fall into a few natural groups anyway. Tiers collapse the long list into three named slots.

The three slots

DevFlow names the slots by intent:

• Max is for heavy reasoning: planning, task decomposition, the diagnostician, the build doctor and the learner.
• Pro is for writing and checking code: the implementer, the fixer, the verifier, the expert, the instructions generator, the preflight detector and screenshot discovery.
• Fast is for aggregation, triage and chat: the summarizer, the finding advisor, the scanner, the preflight verifier, chat, team chat, Sentry triage, attention analysis, the auto-classifier and the scope gate.

Anything not named in that mapping, including roles added later, lands in fast by default.

Binding a slot

In Workspace Settings → Execution, an owner picks a backend and a model for each of the three slots. Every agent then draws from its slot automatically, so changing one slot reaches all of its agents at once: a new fast binding moves the summarizer, chat and triage together. The bindings live in one JSON column on the workspace, model_tiers.

A fixed mapping on purpose

Which role belongs to which slot is decided in code, not in settings. The code comment says why: making that mapping configurable would bring back the per-role sprawl that tiers exist to remove.

Because the mapping is static, each agent always draws from the same slot. When a single agent needs something different, a per-role override handles it. Overrides take precedence in the routing order, at workspace or task level.

Where tiers sit in routing

DevFlow resolves what each run uses in four steps: task override, workspace override, tier, then the flat workspace default. The last step only applies when a slot is unset, as on a newly created workspace before an owner binds its slots. The flat default columns remain on the workspace as that safety fallback.

A sensible starting point

Bind max to the most capable model you are willing to pay for, pro to a model that codes reliably and fast to an inexpensive one. Then adjust with recorded spend per role and the verification results on the dashboard.

Planning and verification also always run at maximum reasoning effort, so the max and pro slots carry the heaviest thinking load. Other roles get maximum effort only when their model is known to support a reasoning-effort setting, either from a curated list or from the parameters OpenRouter lists for it.