Which signal best decides when to escalate a query to a larger model?

A model-routing tier serves cheap queries on a small model and escalates hard ones to a frontier model. The whole question is: what signal decides escalation? The right answer is a **signal that correlates with query difficulty** and is cheap to compute. Two good options: a lightweight classifier trained to score how hard a query is, or the small model's own confidence — if it's unsure, escalate. Both can be calibrated against labeled examples so you know the cut is right. The wrong options all fail in instructive ways. Always escalating defeats the purpose — you're back to paying frontier prices for everything. Routing by time of day is unrelated to whether a query is hard. And escalating on raw prompt length, or length versus the last prompt, is a noisy proxy: a short prompt can be very hard, a long one trivial. The signal has to track real difficulty, not something incidental.

Routing escalation should fire on a signal that actually correlates with whether the query needs more capability, and is cheap enough to run on every request. The correct choice is a per-query complexity or confidence signal — a lightweight **classifier** that scores difficulty, or the small model's own uncertainty. You tune it against labeled data so the threshold is calibrated. This spends the frontier model precisely on the queries that need it. The distractors each teach a different failure. Always escalating removes the entire reason the tier exists: you pay frontier prices on the easy majority. Time of day is a load-balancing notion that has nothing to do with query difficulty — it would escalate easy queries at peak hours and keep hard ones cheap off-peak. Prompt length relative to the previous prompt is the trap distractor: it feels difficulty-related but isn't. Length correlates weakly with complexity, and 'longer than last time' is trivially gameable and resets per conversation. The underlying principle: a good escalation signal is (1) correlated with the thing you care about — does this query need the bigger model — and (2) cheap to compute. Proxies that satisfy neither, or only the second, send the wrong queries up and waste the savings.