Enable automatic selection
Open the agent’s Models page:- Configure a working provider connection and a concrete primary model. Keep a primary model suitable for the hardest work this agent should handle.
- In Automatic model selection, choose a model family and preference.
- Turn on Choose models automatically and select Save model selection.
How Mesh chooses
Mesh discovers the catalog through the agent’s resolved provider, endpoint, and credential. It keeps a snapshot of at most 32 candidates, preserving configured roles and family diversity. Snapshots expire after ten minutes and refresh automatically. Connection changes invalidate cached facts. The Decision model classifies the request into a complexity level: simple, standard, advanced, or frontier. Runtime code then maps that classification to eligible models. The selection step does not generate an answer or invoke a serving text model. For the current catalog-based path, price is a ranking proxy, not measured model quality. Candidates are ordered into price tiers. Automatic selection excludes candidates whose input or output token rate exceeds the conservative fallback’s corresponding rate. Frontier work reaches the fallback at the top of the ladder. The configured primary is the fallback when it remains eligible; a family or capability restriction can require another eligible fallback.
Catalogs with only model IDs and no comparable prices cannot establish a useful
price ladder. Mesh keeps the fallback in that case. Where output-modality facts
are absent, discovery includes only configured primary/fast roles instead of
assuming every returned ID can generate text.
These preferences are selection rules. They do not establish measured speed,
quality, or total-cost improvements for your workload, and they are not a
monetary spending limit.
Fallbacks and run recovery
The selection phase has a two-second budget and runs concurrently with tool preselection. An uncertain or low-probability classification, Decision failure, timeout, saturation, incomplete context, installation routing stop, or a single eligible model keeps the conservative fallback. If catalog discovery fails, the serving path can fall back only to the configured concrete primary, with a 30-second catalog retry backoff. Cancellation and storage failures still propagate. Routing never makes a smaller model fit by discarding extra evidence. If no model is eligible, selection fails instead of ignoring the family or capability rules. There is no mid-run plan-to-execution model switch. Scheduled instructions retain their existing model path. A captured selection belongs to its run. Recovery reuses that choice without classifying again, after checking current connection binding, catalog membership, and capability requirements. A revoked or incompatible choice cannot silently resume on a different model.Inspect and control routing
Routing details belong in the operator trace, not in normal conversation. Mesh records the policy, catalog snapshot, candidate exclusions, selected model, classification, and native Decision call ID. Useful operator endpoints are:
The stop switch preserves captured runs. Disable an individual agent’s routing
policy to return new turns to manual model selection. Stale policy edits return
409 and require a refresh.
The
decision_calls ledger records model_routing classification and each
model_routing_attempt serving attempt. Successful serving calls also appear in
model_calls; do not add both records’ token counts when calculating usage.
Audit-write failure blocks inference or use of the result. Body retention follows
the existing operator retention settings.
The legacy reviewed-profile API remains available for compatibility and has its
own qualification rules. Publishing a profile is not part of normal catalog-based
setup. The implementation is in internal/modelrouting, with serving wiring in
internal/app/model_routing.go and internal/turn/model_routing.go.