Can five components unify all LLM routing approaches?

The LLMRouter paper starts from a fragmentation problem. Existing routers "span binary quality predictors, cost-aware cascades, graph-based routers, and agentic routers," but their "diverse formalisms and incompatible implementations," together with the lack of a standardized evaluation pipeline, "hinder fair comparison and further extension." The proposed remedy is a unified formulation that treats LLM routing as a sequential decision process. Under it, a router is characterized by five component types: context encoders, model encoders, scoring functions, decision rules, and learning signals. Existing methods then sort into three families: single-turn, multi-turn, and personalized routing. The conclusion restates the move, casting all three families "as instances of a common sequential decision process."

The premise is the one the routing literature already shares: "no single large language model (LLM) is optimal across all queries and budget constraints," so something must decide which model handles each query. The paper adds that routing does more than save cost. It also "matches each query to the candidate model best suited to it and adapts model choice to user-specific preferences." That second job is why personalized routing appears as its own family rather than as a tuning knob on single-turn routing. The formulation is offered as the base for everything else in the paper. It underlies an automated pipeline that builds routing supervision by running a pool of candidate models across benchmarks, an evaluation protocol that scores routers on both response quality and inference cost, the xRouteBench benchmark (generic, memory-augmented, vision, time-series and personalized scenarios), and an open-source library implementing more than 16 routers behind one interface.

Against the library's earlier routing notes, this is a widening of frame. Can routers select the right model before generation happens? treats cascades as a foil for single-model routing, an alternative that multiplies latency. LLMRouter counts "cost-aware cascades" as routers in the same design space, differing in components rather than in kind. What decisions must multi-agent routing systems optimize simultaneously? widens what gets routed (topology, roles, backbones). LLMRouter widens how routers are described and compared, and claims deployment support for multi-agent systems without saying whether the formulation covers topology or role choices. The shared premise also runs through Can routing beat building one better model?, which argues model selection is the stronger lever. LLMRouter's contribution is infrastructure for testing that claim across router designs on equal terms.

The excerpt is silent on most of what would test the framework. It reports no router results, no cost or quality figures, and no comparison among the 16-plus implementations. It does not say what the steps of the "sequential" process are, or how single-turn routing fits a sequential description. It does not map any named router onto the five components, so the claim that existing methods fall into three families, with every router expressible in those five parts, rests on the authors' assertion here. Read at that strength, the pattern is a shared vocabulary and a benchmark harness. It does not show that any router type wins, and the five components are best used as questions to put to each router: what encodes the query, what represents the model, how candidates are scored, how a choice is made, and what signal trained it.