Skip to main content
Every agent carries a routing strategy. There are two: Smart routing, where the platform scores each request and picks a model, and Specific model, where you pin one. Set it in the Portal under Agents → (agent) → Model. The models either strategy can reach are listed in the model catalog below.

​
Smart routing

The platform selects a model per request. Scoring is local and heuristic — no LLM call is made to decide. Signals include input length, how many tools are bound, conversation depth, whether images are present, remaining budget, and keyword patterns. Three optional constraints, all “Auto” by default: Model style is not the same as the inference provider. It describes the kind of model behaviour, and deliberately does not leak which provider, gateway, or billing route serves the request. Two scorers abstain rather than dilute: tool density contributes nothing when no tools are bound, and budget pressure contributes nothing when no budget is in play. Below the confidence threshold the tier defaults to Standard. Agents on Smart routing pick up new models as they ship.

​
Specific model

Pin one model by name. You can add:
  • Model settings — the form only offers the options the selected model actually supports. Max tokens is bounded by that model’s ceiling; reasoning effort appears only on reasoning models; temperature is hidden while a reasoning effort other than “none” is active, and is absent entirely on models that do not support it.
  • A budget model — a cheaper model used for low-complexity turns. It carries its own settings block. While fallback is on, it must be in the same family as the pinned model; saving a cross-family pair with fallback on is rejected, because the fallback resolver stays inside the primary’s family and would never reach the budget model.
  • Fallback (on by default) — fail over when the primary is unavailable. Fallbacks stay inside the same model family and may cross providers within it.
The Portal’s model picker only lists catalog models that are reachable in this environment. Reachability is derived at startup from which routes could build a client with the credentials present — there is no per-model enable/disable list. A model with no reachable route is dropped from both smart routing and the picker.
Available model settings are temperature, max_tokens, reasoning_effort, verbosity, thinking_budget, and response_format. There is no top_p, frequency_penalty, or presence_penalty.

​
Tiers

Budget < Standard < Premium. Tier is a declared field on each catalog model, not something inferred from the model’s name or category.

​
The model catalog

This is the full set of models an agent can run on. It is the one place these names are published — other pages link here rather than repeat the list. These columns are the declared fields the routing constraints above match against — Model style, Tier, and Use case respectively. Rows are in catalog order, which is also the order that breaks ties when more than one model satisfies a request. Model is the name you pin under Specific model. Note the dated identifier on Claude Haiku 4.5 — claude-haiku-4-5-20251001 is the whole name, not a version suffix you can drop. claude-fable-5 is opt-in by name: smart routing does not select it. Every other row is eligible for both strategies.

​
Resilience

Model calls run in two layers. A per-route layer handles wire-level retries and recovery; a chain layer routes across models when a route gives up. The journal records both wire and chain attempts on every call. Streaming recovery is pre-commit only: once an answer token has reached the user, the platform stops trying to recover and surfaces the error. Route cooldowns after a failure are per process — they are not shared across replicas and are lost on restart.

​
Cost

Prompt tokens are billed in three separate buckets — fresh input, cached input, and cache writes — because each carries its own rate. Cached reads are substantially cheaper than fresh input and cache writes are more expensive. See Usage and limits and noorle.com/pricing.

​
Gateways

MCP gateways carry no routing strategy of their own. They expose tools; the model that calls those tools belongs to whoever is driving the client.

​
Next