When I route coding work to a lower-cost model, I do not want the first question to be "is it cheaper?"
The first question is:
Can I tell whether this route behaves like the model I intended to use?
That is especially important when the route is used as a backup for Claude Code limits or routine coding work. A cheap route is useful only if the failure mode is visible early.
I would not use a single benchmark score. For day-to-day coding, I care more about whether the model handles the boring but failure-prone parts of software work.
Give the model a small refactor task with clear constraints:
Pass condition:
Fail condition:
Ask it to fix code that crashes when config is missing.
Pass condition:
Fail condition:
Before the patch, ask for a short risk list.
Pass condition:
Fail condition:
The same model should not be the only verifier of its own patch.
Pass condition:
Fail condition:
Give it a small issue and a tempting nearby cleanup.
Pass condition:
Fail condition:
I would record the result like this:
| Test | Pass / Fail | Evidence | Notes |
|---|---|---|---|
| Preserve existing behavior | existing tests / diff review / repro | ||
| Empty config handling | logs / error path / fixture | ||
| Risk before edit | risk list / acceptance criteria | ||
| Independent evidence | existing source of truth | ||
| Narrow task boundary | diff scope / review notes |
The empty cells matter. They show which parts are not verified yet.
For low-cost coding routes, the expensive part is often not generation. It is review.
If the model saves tokens but increases the human review burden, it is not actually cheap. If the route can pass small, reproducible, independent checks, then it becomes much easier to decide which work belongs there.
My current rule:
Use cheaper routes for tasks with cheap independent verification. Keep risky behavior changes on the strongest model or behind a human review gate.
That rule has been more useful than asking whether a model is generally "good at coding."