Model Routing

Four named tiers cover the space of work the bot does. Most turns land on balanced; the others kick in when a skill, a command, or the bot itself asks for them.

On top of the four named tiers, the router exposes five extra slots: special1, special2, special3, special4, special5. They behave exactly like the named tiers — you set them in Settings → Model Router, skills can reference them, and the /tier command accepts them — but they carry no semantic meaning, so the bot never auto-picks a special slot. It uses one only when something explicitly asks for it.

Their purpose is to hold specialized models that you want to reserve for specific flows — skills, webhooks, scheduled automations, and other special cases. That is the canonical use. Typical examples:

• A skill that needs a specific model regardless of your global setup — declare model_tier: special1 in its frontmatter and pin special1 to that model.
• A webhook mapping that must run on a specific model for cost or compliance reasons.
• A second provider running in parallel with your primary one, for A/B comparison or fallback during an outage.

Nothing stops you from using a special slot in an ordinary chat session — type /tier special1 and the rest of your conversation will run on whatever model you pinned to that slot. But that is the exception; the canonical use is binding specialized models to specific flows.

Unset special slots fall through to balanced, same as unset named tiers.

Several things can ask for a tier on the same turn. The bot resolves them in this priority order — the first one that has an opinion wins:

1. Inbound webhook override. If the turn came from a webhook whose mapping sets a tier, that wins. Relevant only if you configured a webhook; see Webhooks.
2. Forced tier (user lock). If you ran /tier coding force or toggled Tier force in Settings, the tier is locked. Skills, the classifier, and the set_tier tool all defer to the lock until you release it.
3. Active skill request. An active skill whose frontmatter declares model_tier: <name> gets its requested tier for as long as the skill is active.
4. Soft preference. The /tier coding command without the force keyword is a suggestion. It loses to an active skill that asks for a different tier, but wins over the default.
5. Default. The bot falls back to balanced.

Initial resolution happens once, on the first iteration of the turn. On subsequent iterations a separate step called dynamic upgrade can promote the turn to the coding tier if it detects code activity — filesystem operations on code files, shell commands like python/npm/mvn/cargo, or stack traces in tool output. It is a lightweight pattern match over tool calls and results (no extra model call), it only ever upgrades to coding (never smartor deep), it never downgrades, and it is skipped entirely when the tier is forced. You can turn it off in Settings → Model Router.

Open Settings → Model Router. You see one row per tier — four named plus five special slots — with a model picker on each row. The dropdowns show the models you added in Settings → Model Catalog; if a dropdown is empty, add the model there first.

Below the tier rows you will find two more controls:

• Dynamic upgrade — the toggle for the mid-turn classifier described above. On by default.
• Global temperature — a slider that applies to every tier. Leave at the default unless you have a specific reason to nudge the bot toward more deterministic (lower) or more varied (higher) output. Skills that need a different temperature should set it in their own configuration.

If you are setting this up for the first time and do not yet know what your usage looks like, this is the safe shape:

• balanced — a mid-sized general model from your primary provider (for example gpt-5.1). Most turns land here.
• coding — a code-specialized model from the same provider if you have one; otherwise reuse the balanced model. Do not leave blank if dynamic upgrade is on — the first code-related turn will fail otherwise.
• smart — reuse the balanced model to start. Point it at a reasoning-tuned model later, once you have skills or commands that explicitly request smart. Leaving it blank only works if nothing ever requests it.
• deep — reuse the balanced model to start. Swap in a reasoning-optimized model when you have a concrete use case (a research skill, a long auto-mode session). Same rule: blank is only safe while nothing requests it.
• special1–special5— leave blank until a skill, webhook, or automation asks for one. These are the only slots where “blank” is genuinely safe by default, because nothing picks them implicitly.
• Dynamic upgrade — leave it on if coding is bound to a model. Turn it off if you want strict cost control, or if you decided to leave coding blank.