Route by traffic and task

Two different problems share one answer here. When a provider is slammed and starts returning 429s, you want the work to keep moving. And when a certain kind of task runs better or cheaper on a certain model, you want that task to land there every time. Both are just questions of ordering your providers.

Survive a provider's traffic

When the provider behind your tier is rate-limited or at capacity, your fallback chain is what keeps the task alive. You call a tier like ultra; behind it you have set an order:

1. Claude (subscription)
2. GPT (API key)
3. Grok or a Qwen model (API key)

OpenLLM tries the first. If it is down, rate-limited, or the request is over that model's context window, it steps to the next and returns the first good answer. Your tool never sees the 429, and the request is never dropped.

You do not change anything when a provider gets busy; the chain already handles it. What you do control is the order, under Configuration → Fallback chains in the dashboard. A reliable default is a subscription first to keep everyday cost near zero, then a metered API key as the always-available backstop:

• ultra → Claude subscription, then Anthropic API key, then a Qwen model.

Most days you ride the subscription. On the day it is at capacity, the task finishes on the API key, and you see the fallback in the dashboard. Because tools only ever reference the tier name, reordering never touches a line of tool config.

Route a task to a specific model

The other direction is deliberate: send a particular kind of work to a particular model. This is useful when one model is stronger, cheaper, or faster for a job, for example routing UI and web-facing edits to GPT or Grok while your deep reasoning stays on Claude.

There are two ways to do it, depending on how permanent you want it to be.

Per-request: pin the full model id

For one task, call the model by its full id instead of a tier. No fallback, no substitution:

curl https://openllm.sh/v1/chat/completions \
  -H "Authorization: Bearer sk-llm-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok/grok-4.5",
    "messages": [{"role": "user", "content": "Update the landing page hero."}]
  }'

Inside a coding tool, this is the same as switching the model for that part of the thread. See Try and switch models.

Standing rule: give the task its own chain

If a kind of work always wants the same model, dedicate a named chain to it. In Configuration → Fallback chains, click New chain, name it, and put the model you want that job to use first, backed by a second provider so it never stalls. Then point that class of task at the chain by its name. For instance, alongside the built-in plus, a UI-focused chain:

1. plus (default coding) → Claude subscription, then GPT.
2. ui (a chain you create) → GPT first, then Grok, then Claude as the backstop.

Now "use the ui chain for web updates" is a routing decision you make once, not a model name you retype on every request. Reorder or repoint it any time from Configuration without changing your tools.