Protocol
Route to the cheapest model that still passes your task eval
Do not pay for intelligence the task does not use—but do not guess where the boundary is.
When it fits
- A workflow uses a frontier model for every request even though many requests may be easier.
When to avoid it
- A cheaper request can still create a more expensive service if retries, failures or human recovery increase.
Why it matters
Partition requests by observable task features, evaluate candidate models on each slice and route only where the cheaper model continues to meet the required outcome and safety thresholds. Re-test the boundary after model, prompt, tool or traffic changes.
Steps
- Define task slices that can be identified before inference.
- Run the same acceptance eval for candidate models on each slice.
- Choose the least expensive model that passes the slice's required thresholds.
- Keep a fallback for uncertain or failing cases.
- Re-evaluate routing when the system or traffic changes.
An example
Use a smaller model for straightforward classification only after local cases show it preserves routing accuracy and escalation behavior; send ambiguous cases to the stronger model.
Check your result
Every routing rule points to a current local eval slice and a fallback path rather than to model reputation.
Keep this limit in mind
- A cheaper request can still create a more expensive service if retries, failures or human recovery increase.
Connected ideas
Useful withOwn the task eval before shopping for a better model
Evidence and sources
Model routing can use local task evaluations to identify the least expensive model that still meets the required behavior for a bounded class of requests.
The passing boundary can change with prompts, tools, model versions and request distribution, so routing rules require re-evaluation.
Improving Agents Is a Data Mining Problem · 7:36-12:46, find the least expensive capable model and fit model, harness and task together