OpenRouter has published a concrete pattern for keeping routine requests on a cheaper model while escalating uncertain answers to a stronger one. The first model returns both its answer and a numeric confidence field in a schema-validated JSON response, allowing application code to compare the score with a threshold.
The score is not a literal probability of correctness. A reported 0.9 does not guarantee a 90 percent chance of a right answer, and values cannot be assumed to mean the same thing across models or task types. Instead, teams should run representative traffic, grade the answers and check whether errors become more common in lower score bands.
The cutoff should sit where the measured error rate begins to rise, with stricter thresholds for tasks where mistakes are costly. Raising it sends more traffic through a second model call, improving accuracy at the expense of money and latency. OpenRouter’s worked figures are illustrative and are not a recommended universal threshold.
The application, not OpenRouter’s fallback feature, must make the escalation decision. Fallbacks handle provider errors rather than valid low-confidence responses. After launch, teams should track score distributions, escalation volume and errors among answers that were not escalated, then recalibrate whenever models or traffic patterns change.