Introduction#
No single model wins every task. I keep several in rotation on purpose and pay the switching cost so I can match latency, reasoning depth, and tool behavior to the work in front of me that hour.
This is the chapter most at risk of aging badly, so I am going to write it to outlast the models it describes. I will not name a single one. The specific roster, with versions and the date I last revised it, changes every few months. What belongs in a book is the way of thinking about models, which has stayed stable even as the names underneath it have churned completely.
No Single Model Wins Every Task#
The instinct to find the one best model and use it for everything is natural but wrong. Different models are built with different priorities, and loyalty to one leaves real capability on the table. The right question stopped being “what is the best model” some time ago. The right question is “what is the best model for this,” and the difference between those two phrasings is the entire chapter.
Models differ along axes that matter for daily work. Some are tuned for speed and low cost, some for slow and careful reasoning, some for very large or visual inputs, and some are built into the editor itself for long, tool-heavy sessions. None of these is better in the abstract. Each is better at something, and the skill is knowing which something is on your desk right now. Treating them as interchangeable is how you end up using a careful reasoner for trivia and a fast skimmer for the subtle bug that needed real thought.
I will be candid that I work with broad access to capable models, which makes rotating between them cheap for me. If your access is narrower, the lesson scales down cleanly. One fast model and one deep model cover the large majority of real work, and you add a third only when you keep hitting the same wall that neither of the first two clears. The principle is the same at any budget. Match the tool to the task instead of forcing every task through one tool.
Matching Models to the Work#
Think in terms of the kind of work, not the brand. When the task is mechanical and lives across many files, such as a broad rename, a repetitive transform, or a wide search, reach for speed. The work is easy to verify and easy to undo, so the cost of an occasional miss is low and throughput is what you want. Spending your most expensive reasoning model on this is using a precision instrument to hammer a nail.
When the task is genuinely hard, reach for depth. Subtle bugs, contradictory specifications, concurrency, security-sensitive logic, and changes that touch contracts or migrations all reward a model that slows down and shows its reasoning, because a wrong assumption in this kind of work spreads like a disease. The latency and cost are real, and they are worth paying exactly here, on the work where redoing it three times with a faster model would cost far more than getting it right once.
Two more shapes round out the map. When the input is large or not purely text, such as screenshots, long mixed documents, or very wide file sets, reach for the model built for big context, because that is where it earns its keep. And when you have been circling the same problem through one model’s way of thinking for too long, reach for a different one entirely, not because it is stronger, but because a fresh set of priors sometimes surfaces the thing your current line of attack kept missing. Even a weaker answer can be useful when it prompts a sharper question.
The Switching Cost, Paid on Purpose#
Rotating between models is not free. There is a real tax in remembering each one’s quirks, re-establishing context, and recalibrating your trust as you move. The temptation is to avoid that tax by settling into a single default and never leaving it. I pay the tax on purpose, because the alternative is more expensive in a way that is easy to miss.
The hidden cost of never switching is that you slowly forget the others exist. A model you keep in rotation stays calibrated, because you have recent, firsthand experience of where it is strong and where it lies to you. A model you abandoned is a capability you no longer have, regardless of whether it is still installed, because you have lost the feel for when to trust it. Keeping a model in light rotation is how you keep that judgment alive for the day you actually need it.
There is a discipline here that mirrors the rest of the book. Paying a small, deliberate cost now to avoid a large, unpredictable one later is the same trade as writing tests, isolating changes, and reading the diff. Switching models with intention is a tiny version of that same habit, applied to your own toolkit. The effort is the price of staying capable across the whole field instead of strong in one narrow lane.
A Working Rotation#
In practice, my decision procedure is fast and unglamorous, and it runs at the start of a task rather than in the middle. If the work is mostly mechanical and spread across files, I start with speed. If it is a hard problem where I want to see the reasoning, I start with depth. If it involves large or visual input, I start with the big-context model. If I have been stuck for an uncomfortably long time, I deliberately switch to a different family to break the pattern.
Most days, this means I live in one or two models and call on the rest only when the task demands it. The full roster is not there because I use all of it daily. It is there so that when an unusual task arrives, I already have a calibrated tool for it and a mental map of which one to reach for. The map is the real asset, and it only stays accurate because the rotation keeps refreshing it.
I want to be clear that this is not science. It is a working heuristic that I adjust as the models underneath it change, and you should expect to build your own version through your own firsthand calibration, given which models are available to you. Copying my exact choices would be pointless even if I named them, because by the time you read this they will have moved. Copy the procedure instead. Decide the shape of the task first, then pick the model that fits that shape.
Putting It Into Practice#
- Replace “what is the best model” with “what is the best model for this task” as your default question.
- Keep at least one fast, cheap model and one slow, deep model, and reach for each by the shape of the work.
- Send mechanical, easily reversible, high-volume work to speed, and hard or high-stakes work to depth.
- Reach for a large-context model when the input is big or visual, not as a general default.
- When you have circled a problem too long, switch model families deliberately to break the pattern.
- Keep abandoned-but-useful models in light rotation so your judgment about them stays calibrated.
- Decide the model at the start of the task, and keep the dated, named roster on the living web rather than in your head.
