> ## Documentation Index > Fetch the complete documentation index at: https://docs.mesh.texturehq.com/llms.txt > Use this file to discover all available pages before exploring further. # Automatic model selection > Choose answer models per turn using provider catalogs and bounded complexity decisions. Automatic model selection lets Mesh choose a concrete answer model for each new conversational run. It uses the agent's existing provider connection, available models, and request complexity. The agent keeps the same identity, persona, memory permissions, and tools when the model changes. This feature is implemented and starts off for each agent. It does not require an uploaded evaluation profile or a separate installation serving credential. ## Enable automatic selection Open the agent's **Models** page: 1. Configure a working provider connection and a concrete primary model. Keep a primary model suitable for the hardest work this agent should handle. 2. In **Automatic model selection**, choose a model family and preference. 3. Turn on **Choose models automatically** and select **Save model selection**. Available families come from that agent's provider catalog: any available family, Anthropic, OpenAI, Google, or xAI. Family is a hard filter. A model also needs to fit the request's known context, output, tool, and image requirements. A native [Decision model](/runtime/decision-models) is needed for complexity-based selection. If the installation has no native Decision route for this agent, automatic selection keeps its conservative fallback. It does not ask the fast text model to choose a model. Saved changes apply to new turns. Manual primary, fast, and heartbeat settings are retained; turning automatic selection off restores the manual path. Under **Evaluation options**, **Collect shadow decisions using the current answer model** records routing choices without changing the answer model. Shadow mode can incur classification charges and cannot be enabled alongside live 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. | Preference | Current catalog behavior | | - | - | | Balanced | Map complexity to the corresponding price tier. | | Faster responses | Use the same tier mapping as Balanced; the catalog path does not rank measured latency. | | Lower cost | Bias the mapped choice one tier cheaper, within the eligible pool. | | Best quality | Bias one tier higher, capped at the 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: | Endpoint | Purpose | | - | - | | `GET/PUT /api/agents/{slug}/model-routing` | Inspect or change the agent's routing policy. Writes include the last observed revision. | | `GET /api/agents/{slug}/model-routes?before={run_id}` | Page through captured routes, 50 per page. | | `PUT /api/settings/model-routing` with `{"stopped":true}` | Installation-owner stop: skip new classification and use the eligible fallback. | 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`. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.