TL;DR
These are some ways to optimize OpenRouter speed versus cost: :nitro for the fastest live host (including priority-priced endpoints), sort: "throughput" with max_price to cap what that speed costs, or a quick Python function against the endpoints API that ranks hosts by speed then price and pins the winner.
Same slug, different hosts
If I send a plain model id (z-ai/glm-5.3-flash, google/gemini-3.8-flash, and the rest), OpenRouter’s default ranking is closer to price / balanced than fastest. That ranking is not a footnote. I ran legal-RAG prompts through a hybrid search stack (keyword plus semantic, then the model) with up to 60 pages of context (~12–13k prompt tokens): a mineral-lease template, oil-rig liability, a forced-pooling argument, and the rest of that cached-context set. I compared default routing to :nitro on 2026-09-03, sorting the host tradeoff by cost and speed.
| Model | Route | Avg / prompt |
|---|---|---|
| GLM 5.3 Flash | default | 221s |
| GLM 5.3 Flash | :nitro | 152s |
| Gemini 3.8 Flash | default | 55s |
| Gemini 3.8 Flash | :nitro | 29s |
Nitro was ~1.5× faster on GLM (~1.9× on Gemini). Even then, the fastest GLM host was still in another league from Gemini: ~152s vs 29s. Routing helps. Switching the model can help more.
Default routing mixed a slow first-party host (Z.AI) with faster resellers. Nitro skipped the slow end of that pool. Parasail on the default route once beat Nitro on a single prompt (196s vs 233s). Nitro optimizes the distribution, not every draw.
That split is visible on a model page. Different companies host the same model. Throughput and latency are not the same from one row to the next.
Output quality on GLM was very good. The wait was not. There is a rumor going around that hosts of this model serve it on Chinese chips, which may explain its slowness.
Nitro is the routing mode that sorts for speed. If I do not ask for it, I should not expect the fastest host.
The one-line fix: :nitro
Append :nitro to the model id. Same chat-completions endpoint, same headers, no extra fields.
{
"model": "z-ai/glm-5.3-flash:nitro",
"messages": [{ "role": "user", "content": "..." }]
}Nitro does two things:
- Sorts eligible providers by throughput (tokens/sec). Same effect as
provider.sort: "throughput". - Lets priority-tier endpoints compete. They win only if they are actually fastest, unlike forcing
service_tier: "priority".
OpenRouter is explicit about the bill: because priority-tier endpoints are billed at priority rates, a :nitro request served by a priority endpoint is charged that endpoint’s priority pricing. If the provider sheds the request to its default tier, I pay the default rate. (Nitro variant)
So :nitro should be the fastest live route. It is not the thriftiest. On GLM that suffix is the jump from 221s to ~152s. Real speedup. Still slow next to Gemini’s 29s, and the host that won may have been a priority tier.
If I want that speed without blindly paying priority rates, I do not stop at the suffix. I sort hosts by throughput and then take price into account. That workaround is the Python below.
When I want control instead of a suffix
Throughput, no priority pool. Fastest default endpoints, usually cheaper than Nitro:
{
"model": "z-ai/glm-5.3-flash",
"provider": { "sort": "throughput" }
}Time-to-first-token. I use "sort": "latency" if I care about first byte more than tokens/sec.
Cheap but not slow. Keep price ranking, require a minimum p90 throughput:
{
"model": "z-ai/glm-5.3-flash",
"provider": {
"sort": { "by": "price" },
"preferred_min_throughput": { "p90": 40 }
}
}I pin or skip hosts with provider.only, provider.ignore, or provider.order if one provider is consistently slow. :floor is the other shortcut: cheapest provider, not fastest.
Speed first, then price
:nitro is max speed, including the priority pool. That is why it can be the fastest and not the cheapest. OpenRouter’s request object still sorts by one key. sort: "throughput" plus max_price is the documented combo: highest tokens/sec, drop anyone above a ceiling. Price is not a second sort key on the wire. It only knocks out outliers. Provider routing says it in those words: use the provider with the highest throughput, as long as it does not cost more than $x/m tokens. The 1 and 2 below are OpenRouter’s own example ceilings, not a live rate. I put in what I will actually pay.
{
"model": "z-ai/glm-5.3-flash",
"provider": {
"sort": "throughput",
"max_price": { "prompt": 1, "completion": 2 }
}
}One thing to know about the ceiling: max_price is per-token USD and OpenRouter’s actual bill can run well above a chars / 4 token estimate on long context. On one of my recent 20-prompt runs, billed cost came in about 66% higher than the char/4 guess. Set the ceiling with headroom or you will filter out hosts you would have been happy to pay.
When two hosts are close on speed, I want the cheaper one to win. That tie-break is not a routing field, which is why :nitro is not thrifty. I rank the endpoints list myself in Python: throughput_last_30m.p50 first (tokens/sec), then pricing.prompt plus pricing.completion (USD per token, as strings). Throughput on that route is only filled when the request is authenticated.
import requests
def pick_fastest_then_cheapest(model, api_key):
author, slug = model.split("/", 1)
r = requests.get(
f"https://openrouter.ai/api/v1/models/{author}/{slug}/endpoints",
headers={"Authorization": f"Bearer {api_key}"},
)
r.raise_for_status()
def rank(e):
tps = (e.get("throughput_last_30m") or {}).get("p50") or 0
price = float(e["pricing"]["prompt"]) + float(e["pricing"]["completion"])
return (-tps, price)
return min(r.json()["data"]["endpoints"], key=rank)["tag"]Feed the returned tag back into provider.only on the next chat call and the router will pin the winner. Speed first, then price. That is the workaround when :nitro would pick a fast priority endpoint I do not want to pay for.
A practical rule
| Goal | What to send |
|---|---|
| Fastest live chat | model: "...:nitro" |
| Fast, skip priority pricing | provider.sort: "throughput" |
| Fastest under a price ceiling | sort: "throughput" + max_price |
| Fastest, then cheapest at that speed | Rank endpoints in Python, pin with provider.only |
| Lowest cost | model: "...:floor" or provider.sort: "price" |
| Cheap with a speed floor | sort by price + preferred_min_throughput |
| Slow model, no routing tweak helps | Try a different slug |
Speed on OpenRouter is not a mystery. It is telling the router I care about throughput, paying for it when the fastest endpoint is a priority tier, ranking by speed then price when I do not want that bill, and switching the model when even the fastest host of it is still too slow.