Model routing

RunYard resolves stable aliases like copilot.fast, copilot.deep, smithers.task, hermes.support, and gateway.default through one persisted policy. Each alias points at an ordered provider/model/account/harness chain. Only safe metadata is returned to clients; credentials stay in the existing secret and runner authentication stores.

Open Settings -> Models and routing to inspect primaries, fallbacks, source, compatibility, safe health, and the behavior when every route is exhausted. Enabled non-pinned aliases require a fallback. Hard pins remain visible with the reason fallback is unavailable.

Usage-limit signals such as 402, 429, quota exhaustion, allowance limits, and provider capacity advance the routing cursor to the next compatible target. If no eligible target remains, RunYard parks the work as provider_limited with redacted attempted-route evidence and retry timing instead of treating allowance exhaustion as a generic run failure.

API and automation surfaces:

• GET /api/model-routing
• PUT /api/model-routing
• POST /api/model-routing/validate
• POST /api/model-routing/simulate
• GET /api/model-routing/explain
• runyard model-routing inspect|simulate|explain
• MCP tools inspect_model_routing, simulate_model_routing, and explain_model_resolution