Provider routing and preferences

The "provider" object controls which backend serves a model — order, fallbacks, required params, price/throughput sorting and data policy.

May 29, 2026 6 slides 5 min read

OpenRouter · Models i routing

Provider routing and preferences

You decide which backend serves each model.
One model, many backends

Recall that an open-weight model can be served by several providers. The request's "provider" object is how you pick which one, in what order and under what conditions.
The key preferences

Inside "provider" you can set several preferences:
- order — an ordered list of preferred providers.
- allow_fallbacks — whether falling back to another provider is allowed.
- require_parameters — drops backends that don't accept the params you send.
- sort — sort by price or by throughput.
- data_collection — exclude providers that collect data.
OpenRouter · Models and routing arlaf.dev

A full provider object

{
  "model": "meta-llama/llama-3.1-70b-instruct",
  "provider": {
    "order": ["together", "fireworks"],
    "allow_fallbacks": true,
    "require_parameters": true,
    "sort": "throughput",
    "data_collection": "deny"
  },
  "messages": [
    { "role": "user", "content": "Hola!" }
  ]
}

Price, speed or privacy

These preferences let you optimize for whatever matters: lowest cost, fastest response, or not sending data to backends that retain it.
The slug picks WHICH model; the provider object picks WHO serves it.

Read the full note

Has vist que un mateix model pot estar servit per diversos backends. Per defecte OpenRouter en tria un per tu, però quan necessites control fi, l’objecte provider de la petició decideix qui serveix el model — no quin model, que això ja ho fa el slug.

Què pots configurar

Dins de provider hi caben diverses preferències que, combinades, descriuen la teva política de routing:

order — una llista ordenada dels proveïdors que prefereixes. OpenRouter els prova en aquest ordre.
allow_fallbacks — si es permet o no caure a un proveïdor que no estigui a la teva llista quan cap dels preferits respon.
require_parameters — descarta els backends que no admetin els paràmetres que envies (per exemple tools o response_format).
sort — ordena els candidats per criteri, típicament preu o throughput.
data_collection — exclou proveïdors segons la seva política de recollida de dades.

Un exemple complet

{
  "model": "meta-llama/llama-3.1-70b-instruct",
  "provider": {
    "order": ["together", "fireworks"],
    "allow_fallbacks": true,
    "require_parameters": true,
    "sort": "throughput",
    "data_collection": "deny"
  },
  "messages": [
    { "role": "user", "content": "Hola!" }
  ]
}

Optimitzar pel que importa

La gràcia és que cada cas d’ús té una prioritat diferent. Un batch nocturn voldrà el preu més baix; un xat interactiu, el throughput més alt; i un projecte amb dades sensibles, no enviar res a backends que les retinguin. L’objecte provider cobreix els tres sense canviar de model.

Nota: els noms exactes dels camps, els valors admesos de sort o data_collection i el comportament de allow_fallbacks poden canviar. Verifica’ls sempre a la documentació vigent d’OpenRouter abans de dependre’n.