Model routing & version pins

The most common production complaint about model aggregators isn’t price — it’s silent quality drift: the same model id served from different providers, on different hardware, sometimes with different weights. Our routing policy is designed around disclosure.

How routing works

• Every model id maps to one or more upstream providers. The “Providers” block on each model page lists them, with current price and observed latency.
• By default, requests go to the primary provider shown on the model page — not to whoever is cheapest for us this minute.
• You can pin a provider explicitly:

{
  "model": "meta-llama/llama-4-maverick",
  "provider": { "only": ["fireworks"] }
}

• Fallback routing is opt-in ("route": "fallback"). Without it, provider failure returns 502 provider_unavailable — see error semantics.

Version pins

When a lab revs a model in place (same id, new weights), the change is logged in the changelog with the date and, where the provider discloses it, the version identifiers. Model ids that point to rolling versions are labeled on their pages.

Free-model stability

Free models rotate at every aggregator — the difference is whether you find out from your error logs. Our free collection carries a dated availability log, and removals get a 7-day notice in the changelog wherever the upstream provider gives us that much warning.