Model authenticity: what happens when one model name has four routes
One model name can sit in front of several upstream channels. Which one answers is a policy decision, and the policy is the thing worth reading.
On a relay, a model name is not an address. It is a label attached to one or more upstream channels, and the relay chooses between them for every request. Understanding that choice is the difference between believing a catalogue and being able to check one.
This is where the category’s worst measured failure lives. A study of 28 relays found 45.83% of endpoints served a model that did not match the one requested. Not a few bad actors: close to half of the endpoints tested.
What a route actually is
A route is one path from a model name to something that can answer. Concretely it is a provider credential plus an endpoint plus whatever configuration goes with them. A relay offering claude-opus-5 might hold three separate Anthropic accounts, and each is a route. Same model, same weights, three ways to reach it.
Multiple routes exist for good reasons. Rate limits are per-account, so three accounts mean three times the throughput. Accounts fail independently, so a second route is a failover. Prices can differ by region or contract, so one route may be cheaper.
They also create the opportunity for the bad version: one of those routes is not the model you asked for. It may be a smaller sibling, a fine-tune, or a different provider’s model behind the same label. From the outside, all three look the same until you test.
- Models in this catalogue
- 53 (read 2026-08-30)
- Served by exactly one route
- 29
- Served by more than one
- 24
- Deepest fan-out
- 4 routes, on 3 models
Those numbers come from the route_count field this station publishes per model in the public catalogue. Whether a relay publishes it at all is itself informative — a relay that will not tell you how many ways there are to serve a request is asking you not to think about the question.
How the choice gets made
With more than one route available, a policy decides. The policy is an ordering, and the ordering encodes what the operator optimises for. This station’s is, in order: stability, time to first token, authenticity, then price.
Read that as a sentence and it says: prefer the route least likely to fail; among those, the one that starts answering soonest; among those, the one most likely to be the genuine model; and only then, the cheapest. A relay that put price first would be making a coherent but very different promise, and you would notice it in exactly the way a canary test is designed to detect.
| Ordering | What it optimises | What you give up |
|---|---|---|
| Stability first | Uptime and predictability | Occasionally paying more than necessary |
| Price first | Headline discount | Authenticity and consistency, silently |
| Latency first | Time to first token | Cost, and sometimes the larger model |
| Authenticity first | Getting the exact model named | Availability during upstream incidents |
None of these is wrong. What is wrong is not saying which one you run, because every one of them produces a different answer to "did I get what I paid for" and the customer cannot tell from the response.
Substitution, and why it is hard to see
A substituted model is not a broken response. It is a fluent, well-formed, correctly-shaped answer that is slightly worse than the one you paid for. That is what makes it commercially attractive and hard to catch:
- The response schema is identical, so nothing in your code errors.
- The
usageblock still returns token counts, so your accounting looks normal. - Quality loss shows up as a small shift in an evaluation you probably are not running per request.
- It can be intermittent — one route in four — so a single test passes.
The tell, when there is one, is usually not the text. Different model families tokenize differently, so completion token counts for an identical prompt tend to diverge before the wording does. That is why the canary method compares token counts alongside the answer.
What "healthy" means, and what it does not
Catalogues often publish a per-model status. On this one, every model currently reads healthy, and it is worth being precise about what that word covers: it means the route answered recent requests successfully. It is an availability signal.
It is not an authenticity signal. A route serving a substituted model is perfectly healthy — it answers quickly and correctly-shaped every time. Health and authenticity are different properties and only one of them is easy to measure from the server side. Any relay that presents a green status as evidence that you are getting the right model is conflating the two, and you should read the claim carefully.
What to ask a relay about routing
Four questions, all answerable in a sentence by an operator who has thought about it, and all revealing when they are not:
- How many routes serve this model, and do you publish that number?
- What is the ordering of your routing policy, and can I read it?
- Are all routes official provider credentials, or are some of another kind?
- What happens on failover — do you fall back to a different model, or only to a different route to the same model?
That last one catches a specific and defensible-sounding behaviour: falling back to a cheaper model when the requested one is unavailable, so the request succeeds instead of erroring. Some users want that. It should never be the default, and it must never be silent, because it converts an outage you could have handled into a quality regression you cannot see.
Our answers, for the record: route counts are published per model in the catalogue; the policy is stability, first token, authenticity, price; routes are official provider credentials; and failover moves between routes to the same model, never to a different one. Those are claims. Test them.
What substitution is worth, to them and to you
Substitution happens because the arithmetic is attractive. Frontier and mid-tier models in the same family are often separated by five to ten times in price while producing answers that read similarly on easy prompts — which is most prompts.
Work it through with published list prices. A frontier model at 4.00 per million input tokens and a mid-tier sibling at 0.75: serving the cheaper one against the expensive one’s price captures the difference on every request, invisibly, with no change to the response schema and no error for your monitoring to catch.
What it costs you is not evenly distributed, and that is the awkward part. On simple prompts the substituted model is often indistinguishable. The loss concentrates in exactly the cases you bought the expensive model for — long context, multi-step reasoning, careful instruction-following, code that has to compile. So the damage is real, concentrated in your hardest workloads, and least visible in the casual testing most people do.
Reading a route count
A published route count is useful information, but it does not mean what people often assume. Higher is not better and lower is not safer; the number describes capacity and failover, not authenticity.
| Route count | Reasonably implies | Says nothing about |
|---|---|---|
| 1 | One credential; simple to reason about | Whether that route is the real model |
| 2–3 | Failover and headroom on rate limits | Whether the routes are equivalent |
| 4+ | Meaningful upstream capacity | How the choice between them is made |
| Not published | Nothing | Everything — and the omission is the signal |
The useful reading is combined with the policy. Four routes under an authenticity-first ordering is capacity; four routes under a price-first ordering is four chances to be served something cheaper. The number alone cannot distinguish those, which is why both belong on a catalogue page.
Routing is the mechanism; canary testing is how you check it from outside. Both sit inside the wider guide to relays, which covers what else is worth auditing before you route production traffic through one.
Figures in this guide were read on the dates shown beside them. Prices change; where a claim depends on a provider’s published price, the link goes to that provider’s own page so you can check it rather than take ours. This guide is reviewed by 2026-10-26.
Check the numbers yourself
Every model on this station, its per-token price and the provider’s published list price are on the pricing page, with no account required to read them.