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.