Author here. The core idea is pretty simple: train linear probes on the model's internal state before it generates anything to predict if it'll succeed. Then use those predictions to route queries: Send easy ones to cheap inference, hard ones to expensive reasoning.
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.
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.
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)
3 comments
[ 4.4 ms ] story [ 15.5 ms ] threadTwo 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.
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.
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)