Shop for LLM infrastructure and you will meet both names, LLM router and LLM gateway, often describing what looks like the same product. The names are not interchangeable, but they are not rival categories either: they emphasise two halves of one job. This post pins down what each half actually does, where they overlap, and why the distinction should not drive your buying decision: capabilities should.
What "router" emphasises: the decision
Routing is the choice half of the job. Given a request, something has to decide which provider and which model serves it, and what happens when that choice goes wrong:
- Model selection — send the request to a pinned model, or choose one by configuration: cost tier, capability class, provider preference.
- Health-aware dispatch: a provider that is rate-limiting, timing out or degrading gets taken out of rotation before it hurts your latency.
- Failover: when a request fails mid-flight, it is re-issued to a healthy alternative under a retry budget, ideally without breaking a stream already in progress.
- Cost-aware policies: route cheap traffic to cheap models and reserve expensive ones for requests that need them, which is usually the biggest cost lever after prompt design.
What "gateway" emphasises: the checkpoint
Gateway is the control half: one place where all model traffic enters, so policy can be applied once instead of in every codebase. We covered the full definition in What is an LLM gateway; the short list:
- Key custody — provider credentials live in one audited place, not in a dozen .env files.
- Quotas and limits, per-key, per-team ceilings enforced before requests reach a provider.
- Attribution: who spent what, per request, per key, per team.
- Data terms: a single point where retention, masking and compliance posture can be stated and enforced.
The honest answer: mature products do both
A router that holds no keys and enforces no quotas pushes the governance problem back into your codebase. A gateway that cannot fail over is a single point of disappointment in front of unreliable upstreams. That is why every serious product in this space, whatever it calls itself, converges on the same capability set, and why the name on the tin tells you about positioning, not features. The practical consequence for buyers: evaluate on the capability list, not the noun. Ask how failover behaves mid-stream, where keys live, how cost is attributed, and what the data terms say — the answers separate products far better than their category labels do. We keep a worked comparison in our OpenRouter alternatives guide.
Why our product is called Runix Router
Runix Router does both halves — key custody, quotas and attribution on the control side; model selection, health-aware dispatch and mid-request failover on the decision side. We put Router on the label because the decision half is where the engineering effort concentrates and where products differ most in practice: anyone can store a key; keeping a stream alive through a provider's bad hour is the part that earns the name. If you are choosing infrastructure right now, the checklist above is the evaluation we would want to be held to — ask us those questions and we will answer concretely, in writing.