How to pick an AI by the task, not the hype: a simple routing framework
Pick your AI by the task, not the hype: a simple framework to route each job by what it is, what a wrong answer costs, and what the model needs to reach.
Pick your AI by the task, not the hype. Before you open a chat, ask three things: what the job actually is, how much a wrong answer costs, and what the model has to reach (a giant input, your files, the live web). Match those to a model, keep more than one open, and send each job to whichever fits.
That routing habit beats chasing whichever model topped a benchmark this month. Benchmarks and launch threads sell you a single "best" model. Real work is different: the best model changes with the task. Below is a simple framework to route any job to the right one, and when not to bother switching at all.
How do I pick an AI for a specific task?
Start with three questions, in order. Each one narrows the choice before quality even comes up.
- What is the job? Making something (writing, code, a plan), analyzing something (a contract, a dataset), finding something (a fact, a source), or automating something (a repeated action). The verb points you at a model type.
- What does a wrong answer cost? A throwaway summary and a client-facing proposal are not the same risk. High stakes point to a careful model, even if it is slower. Low stakes and high volume point to a fast, cheap one.
- What does the model need to reach? A normal-size prompt, a giant input that will not fit anywhere, your own files and tools, or today's web. This one often decides it outright.
Answer those and the model type is usually obvious. You are not ranking models, you are matching a task to the tool that fits its shape.
What kinds of models am I routing between?
Forget brand names for a second. In practice you choose between four archetypes:
- The careful one. Follows instructions closely, reasons through multi-step problems, holds a steady voice. Your default for code, reasoning, and anything you will publish or act on.
- The big-context one. Swallows a whole book, a year of transcripts, an entire codebase in one pass. Reach for it when the input is the problem.
- The fast, cheap one. Cheaper per call, quick to answer. Right for simple tasks run in bulk, where good-enough at scale beats perfect once.
- The connected one. Reaches the live web or your tools and data. Right when the answer depends on something current or something only you have.
Most model families ship a version of each. The skill is naming your task's shape, then picking the archetype, then the specific model.
Routing table: which task goes where?
"Default" means start here, not that the others cannot do it.
| Task | Route to | Why |
|---|---|---|
| Code you'll ship, tricky refactors | careful model | close instruction-following, admits gaps |
| Writing you'll publish | careful model | steady tone, low filler |
| A decision you'll act on | careful model | multi-step reasoning that holds |
| A book, whole repo, or year of logs | big-context model | input won't fit anywhere else |
| Hundreds of simple, similar tasks | fast, cheap model | good-enough at scale, low cost |
| Anything that needs today's facts | connected model | reaches the live web |
| Anything that needs your files or CRM | connected model | reaches your data through connectors |
How do I route in practice?
1. Name the dominant job, not "which AI is smartest". What will you do most this week? That is your default model. 2. Check the one hard constraint. Input length, budget, live-data need, or where the data lives. Usually one of these decides it before quality matters. 3. Run your real task through two candidates. Twenty minutes on a task you have right now beats any leaderboard. Same prompt, compare the output you'd actually use. 4. Route, don't marry. Keep two open. Send each job to whichever fits its shape. Locking into one model is the only clear mistake.
When should I not bother switching models?
Most of the time. Model choice is the last 10%, not the first. A sharp prompt and a clear task beat the "better" model used lazily, so before you shop for a different AI, fix the request: say what you want, give an example, set the constraints. If the output is still wrong for the shape of the task, then route. Getting good at that request-writing moves more than any model swap, and you can practice it in the real Claude without signing up.
In short
Route by task, not hype. Ask what the job is, what a wrong answer costs, and what the model must reach, then match that to a careful, big-context, fast, or connected model. Keep two open, send each task to whichever fits, and fix your prompt before you blame the model.
Questions
Ask three questions: what the job is (create, analyze, find, automate), what a wrong answer costs, and what the model has to reach (a giant input, your files, the live web). Then match the task's shape to a model type: a careful one for code and writing, a big-context one for huge inputs, a fast cheap one for bulk simple tasks, a connected one for current data. You don't need to rank models by an overall score.
One is fine to start, but the people who get the most out of AI keep two open and send each task to whichever fits. Code and writing to one, giant context and live data to another. Locking into a single model is the only clear mistake; everything else is just convenience.
Writing the task. Model choice is the last 10%: a sharp prompt and a clear target beat the "better" model used lazily. Fix the request first: say what you want, give an example, set the constraints. If the output is still wrong for the task's shape, then switch models.