Pick the Right Model
Sort ten everyday tasks onto the model tier that actually fits them, not the biggest one you can reach for.
About 2 min to play
0 / 10
Draft a one-line Slack reply to a teammate
- Rewrite a sentence to sound friendlier
- Summarize a 3-paragraph email
- Write a weekly team status update from bullet notes
- Proofread a blog post for tone and clarity
- Turn a rough feature idea into a one-page spec
- Debug a gnarly multi-file race condition
- Plan a multi-step migration across a large codebase
- Work through a multi-step math proof
- Generate ten alternate taglines for brainstorming
Why this matters
"Just use the smartest model" is expensive advice, and it's often wrong advice too. Model providers ship several tiers for a reason: a fast, cheap model nails a one-line rewrite in a fraction of the time and cost of a heavyweight reasoning model โ and the heavyweight one isn't automatically better at it, just slower and pricier for no gain.
The skill isn't knowing which model is "best." It's matching the tool to the job: how much genuine multi-step reasoning does this task need, versus how much of it is just fast pattern-completion that any competent model handles the same way?
Get the match wrong in one direction and you're paying reasoning-model prices and latency for a task that didn't need it. Get it wrong the other way โ a fast, cheap model on a task that actually needs to hold a lot of state and reason through edge cases โ and you get a confidently wrong answer instead of a slow correct one.
What you'll learn
- Bigger and slower isn't automatically more correct โ it's a trade-off, not a strict upgrade
- Short, well-defined, single-step tasks are exactly what fast/cheap tiers are built for
- Multi-step reasoning, long-horizon planning, and gnarly debugging are where heavier reasoning models earn their cost
- The real question is 'how much reasoning does this task need', not 'which model is smartest overall'
This game goes with Why "Use the Smartest Model" Is Bad Advice.