Provider routing

A model can be served from more than one place: a slot on our own GPU, an external provider, sometimes both. The provider object in the request body lets you say which of those you will accept and in what order.

{
  "model": "google/gemma-4-26b-a4b",
  "provider": { "only": ["local-gpu"], "sort": "price" },
  "messages": [{ "role": "user", "content": "…" }]
}

By default — with no provider object at all — candidates are ordered by priority, which puts local GPU slots first. See Local-first routing.

Provider slugs

The values you put in order, only and ignore are provider slugs. List them:

curl https://openrouter.myip.co.kr/api/v1/providers

{
  "data": [
    { "name": "MyIP Local GPU", "slug": "local-gpu", "model_count": 4,
      "privacy_policy_url": null, "terms_of_service_url": null, "status_page_url": null }
  ]
}

local-gpu is the slug for our own hardware. Which external providers exist depends on what our operators have configured, so read the list rather than hard-coding it.

To see which providers serve one particular model, and with what context window and quantization:

curl https://openrouter.myip.co.kr/api/v1/models/google/gemma-4-26b-a4b/endpoints

Fields

Order of operations

The fields are applied in a fixed sequence, and the sequence matters:

order → only → ignore → sort → allow_fallbacks → max_price → require_parameters → metadata filters → cooldown

Two consequences worth internalising:

• sort overrides order. If you set both, the sort runs afterwards and rearranges everything. Sorting is stable, so candidates that tie keep the order they had — which is where your order survives, and nowhere else.
• allow_fallbacks: false runs before the price and parameter filters. The chain is cut to one candidate first; if that one candidate is then removed by max_price or require_parameters, you get 404 no_endpoints_found rather than a cheaper alternative.

Cooldown is applied last: a candidate that has failed three times in a row is skipped for 60 seconds regardless of your preferences.

Examples

# Local GPU only — no external provider may see this prompt
curl https://openrouter.myip.co.kr/api/v1/chat/completions \
  -H "Authorization: Bearer $MYIP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/gemma-4-26b-a4b",
    "provider": { "only": ["local-gpu"] },
    "messages": [{ "role": "user", "content": "사내 문서를 요약해 줘." }]
  }'

Interaction with models[]

models[] picks the models; provider{} filters and orders the endpoints of all of them at once. The provider object is applied to the whole concatenated chain, not per model. In particular, allow_fallbacks: false cuts the chain to one candidate globally — it does not mean "one candidate per model". See Model fallbacks.

Verifying the outcome

X-MyIP-Provider: MyIP Local GPU
X-MyIP-Model: google/gemma-4-26b-a4b

If the answer is not from the provider you expected, GET /api/v1/generation?id=… shows provider_responses, the list of everything that was tried and why it was passed over.

What we do not have

These exist in some other gateways and are deliberately absent here:

• Auto-routing / frontier selection. No openrouter/auto-style meta-model, no Pareto or fusion routers. Routing is your chain and nothing else.
• Model variants. No :nitro, :floor, :free suffixes. Use sort: "throughput" or sort: "price" instead — that is what those suffixes were shorthand for.
• Presets. No server-side saved routing configurations. Send the provider object with each request, or wrap it in your own client.
• BYOK. You cannot attach your own provider credentials. The byok_* fields in key responses are always zero.

Requests to the endpoints backing those features return 404 not_supported. See Unsupported endpoints.