When a cheap model is the right answer, and when it is a trap
"Use a cheaper model" is good advice about eighty per cent of the time and terrible advice the rest. The useful question is not which model is best, it is which questions can tell the difference.
Where cheap models are genuinely fine
Tasks where the answer is mostly determined by the input, and the model is doing transformation rather than thinking:
- Rewriting and tightening. The content already exists. Shortening a paragraph is not a reasoning problem.
- Formatting and extraction. Pulling dates out of an email, turning notes into bullets, reformatting a table.
- Explaining a known error. A stack trace is a lookup with context attached.
- Short factual recall in a well-trodden area. Syntax, standard library behaviour, common formulas.
- First drafts you are going to edit anyway. The expensive model's extra quality is lost the moment you rewrite it.
On this sort of work a good everyday model matches a frontier model closely enough that in a blind comparison you would struggle to say which was which.
Where it quietly costs you
The failure mode is not that a cheap model refuses or produces nonsense. It is that it produces something fluent and plausible that is wrong in a way you will not notice until later:
- Multi-step reasoning. Anything where step four depends on getting step two right. Errors compound silently.
- Long context. Holding a whole contract, codebase or thread and keeping the details straight.
- Novel problems. Something genuinely unlike what it has seen, where pattern-matching produces a confident near-miss.
- Anything with a consequence. Legal, medical, financial, security. Not because cheap models are especially bad at these, but because the cost of a quiet error is not symmetric.
- Code that will be run rather than read. A subtle bug costs more than the model ever saved.
The pattern: cheap models are safe where you would notice a mistake, and dangerous where you would not.
How to decide without deciding every time
You can apply this by hand — switch models per task, keep a mental rule. Most people manage it for a week.
The alternative is to let the routing do it and keep the ability to overrule. Switchboard scores each message for length, reasoning depth and task type, picks accordingly, and tells you what it picked. When it guesses low and the answer feels thin, "try a stronger answer" sends the same question to a better model. That feedback loop is the important part: routing you cannot see or override is just someone else's cost-cutting applied to your work.
The honest caveat
No router is right every time, including ours. What makes it workable is that the failure is visible and cheap to fix — you can see the tier on every answer and escalate in one click — rather than invisible and expensive. A system that silently downgraded your hardest questions to save money would be worse than paying $20 a month, and we would deserve to lose you over it.
If you want to see how it calls it, ask it something. A few questions free, no account. Ask it one easy thing and one genuinely hard thing, and watch which model each gets.
Switchboard routes each task to the model that does it best for the least. Ask it something — a few questions free, no account — or see what it costs.