Escalate to a Reasoning Model Only When the Fast One Fails

A routing rule: default every task to the fast model and only escalate to a reasoning model when the fast answer is demonstrably wrong or shallow — not pre-emptively.

Reasoning models cost latency and, on paid tiers, tighter usage limits. Most tasks don't need them, and using one everywhere trains a slow, expensive habit. Letting the fast model try first tells you whether the task is actually hard, so you spend the deep model only where it earns its keep.

Any workflow where you handle many tasks of varying difficulty and can't tell up front which are genuinely hard — drafting, lookups, mixed coding and analysis.

Tasks you already know are hard and one-shot critical (a subtle proof, a risky plan) — start deep. And trivial tasks that never need escalation at all.

First pass (fast model): <task>.

[If the answer is thin or wrong] Escalate: here's the fast attempt and where it fell short: <paste>. Take the time to reason this through properly and fix what it got wrong.

A tricky SQL window-function bug gets a plausible-but-wrong fix from the fast model; you hand that attempt to the reasoning model, which spots the framing error the first pass missed.

• Defaulting to the strongest model for everything and burning limits on easy work.
• Never escalating, so hard problems get fast, confident, wrong answers.
• Escalating without showing the failed attempt, wasting the reasoning model's head start.