LLM routing chooses which model answers a request. In Skyfix that choice is made only after policy, budgets and guardrails have narrowed the options: the router ranks eligible models by task, cost, latency and region, fails over inside the same limits, and records why it chose what it chose.
01
A routing layer that can pick a model policy forbids is a policy bypass. Skyfix evaluates the gates before any preference: the regions and providers the workspace allows and denies, the data-residency rule for the request's data class, the budgets that apply to the key, team, workflow and end user, and the guardrail outcome from the AI Firewall. Only the models that survive every gate are candidates. A request with no surviving candidate is refused with the gate that stopped it, and that refusal is in the ledger.
02
When an application asks for 'auto', Garuda classifies the request by task type and ranks the eligible models for it, preferring a lower-cost model where the task allows and a stronger one where it does not. Router heads are signed artifacts that your installation verifies and re-signs before loading, like detection packs; when no head is present, the gateway falls back to baseline routing by the alias mapping and fallback order.
Garuda never widens the candidate set. It chooses among what policy already allows, and its choice is recorded with the task class and the reason.
03
Each provider has a connection test, health checks and a circuit breaker. When the preferred provider fails or its breaker is open, the load-balancing strategy moves to the next provider in the fallback order, and only to one that passes the same gates. Response and semantic caches, administered per installation, can answer a request without a provider call where policy allows; a cache hit is a routing outcome with its own ledger entry and its own cost line.
04
Every decision records the alias asked for, the task class, the route reason, the models skipped and why, the provider used, the fallback reason if any, the cache outcome and the trace ID. The request trace shows the routing step on the waterfall next to policy, guardrails and the budget check, so an engineer can answer 'why this model?' from one screen and an auditor can verify it from the signed ledger.
05
Before changing an alias mapping or enabling a router head, compare the candidates in an experiment: variants run over a saved dataset through the governed gateway, scored by versioned evaluators, with results paired by item and a regression badge. Because the experiment traffic is governed, it respects the same budgets and data controls as production and leaves signed evidence.
FAQ
The decision of which model and provider answer a request. In Skyfix it happens after policy, budgets and guardrails have narrowed the candidates, by alias mapping or by Garuda's task classification, with failover and caching inside the same limits.
No. Region and provider lists, data residency, budgets and guardrails are evaluated first and remove ineligible models. The router, including fallback, chooses only among what remains.
The load-balancing strategy moves to the next provider in the configured order when the preferred one fails or its circuit breaker is open. The fallback must pass the same gates, and the ledger records the providers skipped and the reason.
The alias, task class, route reason, models skipped, provider used, fallback reason, cache outcome and trace ID, visible on the request trace and in the signed ledger.
No. Applications call an alias, or 'auto', through the industry-standard chat-completions API. Routing rules, fallback order and router heads are managed by platform teams in the console.
