LLMRouter vs semantic-router
UIUC's LLM routing library: 16+ trainable routers (KNN, MLP, matrix factorisation, Elo, graph, BERT) pick the best model per query, with xRouteBench and a train/serve CLI. — versus — vLLM's programmable decision layer: one endpoint for your agent harness that selects or combines models per call by policy — quality, latency, cost, location — across local and cloud backends.
Same job — pick the best model per query; llmrouter is a research library of trainable routers, SR a production gateway built around that decision.
| LLMRouter | semantic-router | |
|---|---|---|
| Stars | 3.0k | 6.1k |
| Forks | 313 | 1.0k |
| Language | Python | Go |
| License | MIT | Apache-2.0 |
| Last activity | 6 days ago | yesterday |
| Topics | gateway, training | gateway, local |
| Curated connections | 5 | 5 |
LLMRouter — the curator's take
Reach for LLMRouter when you have many models behind one API and want a *learned* policy deciding which one answers — by task complexity, cost and quality — rather than a hand-written fallback chain. It's a research library from the xRouteBench paper: you train a router on your own traffic (there's a data-generation pipeline over 11 benchmarks), then serve it. NOT a gateway — it doesn't call providers, hold keys or retry; put it in front of LiteLLM or a proxy. And NOT for a two-model setup: below a handful of candidates a rule beats a trained router.
semantic-router — the curator's take
Use it when you serve several models — especially self-hosted vLLM next to cloud APIs — and want policy-driven per-request selection with guardrails, caching and hallucination checks in the path. Heavyweight for a single-provider app or a laptop: Kubernetes-grade infra with its own routing models. Just want quota failover for coding CLIs? That's a coding gateway's job, not this.