LLMRouter vs plano
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 — AI-native Envoy-based proxy for agentic apps: agent orchestration via a 4B routing model, smart LLM routing, guardrail filter chains and zero-code OTEL traces. Rust, framework-agnostic.
Both route each request to the right LLM. Plano bakes a 4B routing model into an Envoy proxy you deploy; LLMRouter is the library of routing methods you train on your own data and serve yourself.
| LLMRouter | plano | |
|---|---|---|
| Stars | 2.8k | 7.0k |
| Forks | 297 | 487 |
| Language | Python | Rust |
| License | MIT | Apache-2.0 |
| Last activity | 16 days ago | 17 days ago |
| Topics | gateway, training | gateway, orchestration |
| Curated connections | 3 | 7 |
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.
plano — the curator's take
Reach for it when multi-agent code is drowning in hidden middleware — intent routing, provider quirks, guardrail hooks, tracing glue. Plano moves all of that out-of-process: agents are plain OpenAI-compatible HTTP servers in any language, orchestration is YAML plus a purpose-built 4B router model. NOT for a quick single-agent demo (it adds an infra hop and Envoy operational surface), and note the catch: the hosted Plano-Orchestrator LLM is free-tier only — production means running the routing models yourself or getting API keys. If you only need provider unification, LiteLLM is lighter.