Routing LLM queries using internal success predictions (70% cost reduction)(arxiv.org)
arxiv.org
Routing LLM queries using internal success predictions (70% cost reduction)
https://arxiv.org/abs/2602.09924
3 comments
This is a nice approach — using model internals to predict success before committing to full generation.
We took a different path at Komilion: classify the prompt upfront (regex fast path + lightweight LLM classifier) and route to the cheapest model that benchmarks well for that query type. Simpler, but works without model-specific training.
The 70% cost reduction figure matches what we see in practice. The insight that most queries are "easy" is the key — once you stop sending FAQ-level questions to frontier models, the savings are dramatic.
Curious if you have looked at combining both approaches — upfront classification for obvious cases, then internal state probes for the ambiguous ones in the middle.
We took a different path at Komilion: classify the prompt upfront (regex fast path + lightweight LLM classifier) and route to the cheapest model that benchmarks well for that query type. Simpler, but works without model-specific training.
The 70% cost reduction figure matches what we see in practice. The insight that most queries are "easy" is the key — once you stop sending FAQ-level questions to frontier models, the savings are dramatic.
Curious if you have looked at combining both approaches — upfront classification for obvious cases, then internal state probes for the ambiguous ones in the middle.
Thank you!
I haven't used Komilion before, but it seems like we were thinking in the same direction. There's definitely room to add more to our suggested application of the probe. That's why we kept it simple so that people can add more business logic on top of how someone may want to route (so stuff like length, topic, etc)
I haven't used Komilion before, but it seems like we were thinking in the same direction. There's definitely room to add more to our suggested application of the probe. That's why we kept it simple so that people can add more business logic on top of how someone may want to route (so stuff like length, topic, etc)
Two findings that surprised us:
1. The same model has completely different internal representations of "difficulty" depending on decoding settings. What GPT-oss thinks is hard with greedy ≠ what it thinks is hard with sampling.
2. Model difficulty and human difficulty are orthogonal. The problems they struggle with aren't the ones we struggle with, and this gap increases with extended reasoning.
Code: https://github.com/KabakaWilliam/llms_know_difficulty Probes: https://huggingface.co/CoffeeGitta/pika-probes
Happy to answer questions.