If you hand-pick a handful of models instead of using every model available, does your AI router actually pick better answers?

This explores whether a router (the component that decides which model should answer a given query) gets better results from a small, carefully chosen set of models than from simply adding more models or building one bigger one. To be upfront: no note in the collection measures router recall against pool size head-on. Several findings point the same way, though, and together they make a fairly strong case for curation.

The clearest evidence is about how fast a pool runs out of new behavior. When researchers measured how differently models in a large pool actually behave, a curated subset of fewer than ten models captured most of the full pool's range. Past that point, extra models mostly repeat what others already do How quickly does behavioral diversity plateau in model pools?. For a router this matters a lot. Its job is to find the right model for each query, and if most of the pool is redundant, a larger pool gives it more near-identical options to sort through without giving it better ones. The routing results fit this picture: ten 7B models with good routing beat GPT-4.1 and 4.5, and Avengers-Pro, which routes each group of similar queries to the model best suited to it, scored 7% higher than GPT-5-medium or matched it at 27% lower cost Can routing beat building one better model?. In these results, choosing well did more than scaling up.

There's a structural reason a small pool suits routers. Most deployed routers decide before any answer is written. They estimate how hard a query is and send it to one model, without generating several answers and comparing them Can routers select the right model before generation happens?. That makes the router a prediction problem: it has to know ahead of time what each model is good at. A few models with distinct, well-understood strengths are easier to predict than dozens of overlapping ones. The LLMRouter framework helps here because it breaks routers into five comparable parts, so you can test whether gains come from the pool, the difficulty estimator, or the selection policy Can five components unify all LLM routing approaches?.

The less obvious point is that 'curating vs. scaling' isn't only a choice between models. Extra inference compute can let a small model match a much larger one on hard prompts Can inference compute replace scaling up model size?, so a lean pool can have a 'think longer' option built in rather than needing a bigger model for hard cases. A deployed router also keeps records of which model it chose and how well the answer turned out. Those records can become training data, so the pool can be re-curated, or its models fine-tuned, from real usage Can a routing harness generate its own training data automatically?. Real-world usage suggests this mix is how things already work in practice: on OpenRouter, open-weight models serve over 30% of tokens even where closed models lead, because users weigh cost and speed against capability How much do open-weight models actually get used in practice?.

One caution that's easy to miss: every model in the pool is another place to attack. The routing layer can be manipulated into sending requests to weaker or less safe models Can attackers manipulate which model handles a request?. A small, vetted pool is easier to route well and also easier to secure. The open question the corpus leaves is how to pick that 'under ten' set for a specific workload, and whether the saturation point holds when diversity is measured as task accuracy rather than behavior.