Provider Selection — LLMRouter Docs

Default behavior (no `provider{"{"}{"}"}`)

With no provider object at all, deployment choice among a model's healthy providers follows the same rule OpenRouter documents: deployments with a significant outage in the last ~30 seconds are deprioritized first; if a prior request from your session or key already landed on a deployment (sticky routing, for provider-side prompt-cache hit rate), that one is preferred; otherwise a deployment is drawn at random weighted by the inverse square of price — a $1/M provider is ~9× more likely to be picked than a $3/M one. Setting sort or order disables both the weighting and the stickiness in favor of your explicit choice.

The `provider{"{"}{"}"}` object

curl https://api.llmrouter.sh/v1/chat/completions \
  -H "Authorization: Bearer llmr_sk_live_..." \
  -H "content-type: application/json" \
  -d '{
    "model": "meta-llama/llama-3.3-70b-instruct",
    "provider": {
      "only": ["together", "deepinfra"],
      "max_price": {"prompt": 0.5, "completion": 0.5},
      "require_parameters": true
    },
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

Field	Default	Effect
allow_fallbacks	true	`false` restricts the call to a single deployment with no within-model retry
order	unset	ordered list of provider names — first match among healthy deployments wins, pinned
only / ignore	unset	allow-list / block-list of provider names
max_price	unset	`{"{"}prompt, completion{"}"}` ceiling in $/1M tokens — deployments above it are excluded
require_parameters	false	drop model candidates that can't satisfy params your request actually carries (e.g. `tools`, JSON mode) — checked before a model is even selected
sort	unset	see below

only/ignore/max_price never prune a model down to zero servable deployments — an over-restrictive filter degrades to "ignore that one preference" rather than making an otherwise-healthy model fail your request outright.

`sort` & `order`

Setting either one opts out of the default weighted/sticky behavior above in favor of a deterministic pick:

order: ["together", "deepinfra"]	first name in the list with a healthy deployment wins, every time
sort: "price"	always the cheapest healthy deployment
sort: "latency" / "throughput"	lowest measured average latency among deployments we have data for; falls back to cheapest on a cold-start deployment with no samples yet

Slug suffixes: `:nitro` / `:floor`

Same idea, no request body change needed — append :floor to a model id for sort:"price", or :nitro for sort:"throughput" — e.g. "model": "meta-llama/llama-3.3-70b-instruct:floor".

Filters never hard-fail

A too-narrow only/max_price combination that would exclude every deployment of a model is treated as "ignore this one filter" instead of a hard failure — we'd rather serve your request than enforce a preference into an outage. order and sort still only ever choose among deployments that are actually healthy right now.

Outage cooldown

A deployment that fails repeatedly is cooled down and excluded from selection for a window before being retried — the same "no significant outage in the last ~30s" rule used in the default weighting above applies here too, so a struggling provider stops receiving new traffic well before your request would otherwise time out against it.

Default behavior (no provider{"{"}{"}"})

The provider{"{"}{"}"} object