Track I · Pro / Systems & Consulting-Grade Matching model to task instead of defaulting.

What's your favorite model?

Almost everyone uses one model for everything. They picked a favorite, they trust it, and every task goes to the same place, whether it's drafting an email, extracting a date, or reasoning through a hard architecture decision. It feels consistent. It's also the single most common reason people overpay and underperform at the same time: the cheap routine work is running on a model priced for hard reasoning, and the genuinely hard work is sometimes running on whatever they happened to default to. Choosing the right model isn't about knowing which model is "best." There is no best. It's about matching the model to what the task actually demands.

Now let me introduce you to my Ten-Speed Theory. I've got almost two dozen agents working for me across six projects, and the day I stopped asking "which model is best" and started asking "what gear does this task need" was the day the whole thing got efficient. You don't climb a hill in tenth gear and you don't cruise the flats in first. Bring a frontier model to a tagging job and you're burning money to go slow; send a hard architecture call to a tiny model and it'll confidently hand you something wrong. The unit was never the model. It's the task in front of me.

Two things are important to me now. The first is making sure I build AI agnostic systems, meaning I can open the project in any current coding agent like Claude Code or Codex. If I hit a limit in Claude, I can immediately swap to Codex and keep going. The second is making sure I'm using the right model (Fable 5, Opus 4.8, Sonnet, etc.) for the task in front of me.

When you combine these two, you give yourself more token efficiency for one, and you give yourself the ability to keep working when you do happen to run into your hourly or weekly token limits, simply by switching to another platform.

What choosing the right model actually is

Strip away the leaderboards and model selection is one discipline: picking the cheapest, fastest model that still clears the task's real bar. That's the part that never changes. Not the smartest model, the right-sized one. The task sets the bar; your job is to find the least expensive thing that gets over it, not to bring the heaviest thing you own to every job.

This means the unit of decision is never the model. It's the task. "Which model is best?" is unanswerable and the wrong question. "What does this task actually demand: reasoning, speed, cost, a long context, a specific capability?" is answerable, and the answer points at a model. Defaulting skips the question entirely, which is why defaulting quietly loses on both cost and fit.

A model, plainly, is one trained system with its own profile: how well it reasons, how fast it responds, how much it costs, how much it can hold at once. Different profiles suit different jobs. That's the whole game.

I want you to succeed at this so I'm including a chart with this PDF that will show you which task is which "gear" on the ten-speed. You can adjust based on the models you have access to. See below.

The dimensions a task actually demands

Before you can match a model to a task, you have to know what the task is asking for. The dimensions that matter most:

Reasoning depth. Is this multi-step thinking where a wrong inference cascades, or is it pattern-shaped work the model has seen a thousand times?
Speed. Is a human waiting on this in real time, or is it a background batch where latency is invisible?
Cost sensitivity. Does this run once, or ten thousand times? Per-call cost that's trivial at one call is decisive at scale.
Context size. Does the task need the model to hold a huge document or long history at once, or does it fit in a small window?
Specialized capability. Does it need a specific strength (code, structured output, a particular modality) that some models do markedly better?

The task is a profile on these dimensions. A good model choice is just the closest match between that profile and a model's profile. You're not ranking models; you're fitting two shapes together.

The gear chart: a task-to-engine map

Here's the whole idea on one page. Think of model power as gears: 1 to 2 = script / tiny-local, 3 to 5 = mid / local-thinking, 6 to 8 = strong model, 9 to 10 = frontier plus human. Then read across what a task actually is and the gear falls out.

Every row is a thing an agent does. Two independent decisions hang off each row:

Gear is which engine the work needs. That's the model question, and it's what this guide is about.
Human gate is what you, the human, have to do. That's the involvement question, and it's a different decision entirely.

The Gear / Gate Chart, page 1 of 2: routine and mid-gear work

The Gear / Gate Chart, page 2 of 2: high-consequence work and the human gate

The two things the chart teaches that a list can't:

Most work is low-gear. Classify, summarize, extract, format, route, gather, first-draft: the bulk of an agent fleet's actual workload sits at gears 1 to 5. The frontier engine is for the few rows that genuinely reason without a ground truth: strategy, architecture, the final release call.
Gear and involvement are different axes. Notice the chart has a separate human gate column, and it does not track the gear. A small bounded code edit is mid-gear but needs no hovering, because the tests are the verifier. An irreversible op can be gear 1 and still demands your authorization, because you can't cleanly undo it. Gear is set by what the task demands. The gate is set by catchability and consequence. They line up by accident, never by rule.

What this looked like when I actually ran it

I forked my own version of HyperFrames, Heygen's free video generator. The forking was the work: I added fifteen design skills and had Claude Fable strip out the API and URL endpoints, so the whole thing came out self contained. No Heygen API, no external endpoints, nothing reaching out to the internet for anything. I called it Hyperspace. I wanted a generator built for me, and I wanted it to stop depending on somebody else's endpoint staying the way I found it.

Once it ran, I had something better than an opinion. I had a real job with a result I could look at. So I ran the same video work through two models, Claude Fable 5 and Codex Sol 5.6, and I watched what came out.

Fable 5 gave me the better video. That is worth sitting with, because Codex Sol 5.6 benchmarks higher. The leaderboard said one thing and the video on my screen said another, and I went with the video.

That's the whole move, and it's smaller than it sounds. I didn't read a comparison article. I didn't argue about it on the internet. I took one real job I already do, ran it both ways, and looked at the output. The gear chart tells you roughly where a task sits. Only your own output tells you which engine actually clears the bar on your work.

So the moral of the story is, you're going to have to test if you really want measured results you can expect. Otherwise you are just pointing at a model and hoping. The good news is, you don't have to go into a specific testing mode and test old data and results. Just add a testing loop to your current tasks. Test as you go!

The second axis: gear is not the same as "do I watch it"

Picking the engine answers how much horsepower. It does not answer do I stay in the loop. Those are two separate decisions on the same row, and conflating them is how people end up either babysitting cheap work or rubber-stamping dangerous work. Four named places the human gate fires:

Verification gate. The agent can build it but can't confirm it. It can verify "tests pass"; it cannot verify "the video plays," "the UI looks right," or "the tone lands" without your eyes. The trap is the agent reporting VERIFIED when the truth is only TRUSTED.
Authorization gate. The action is irreversible or high-blast (send, publish, delete, deploy, spend). This gate ignores gear entirely: even a gear-1 step gets your approval if you can't cleanly undo it.
Direction gate. Intent is ambiguous or several strategies are valid. The model fills an underspecified goal with a plausible guess, and plausible-but-wrong is its most dangerous output. You set direction before it runs.
Coherence gate. Long, multi-step state where the agent drifts. A checkpoint partway through catches drift before it compounds.

Rule of thumb: actually look at the results when something is expensive to fix AND mistakes could be hard to find later. Once those two conditions are met, you need to be the human in the loop at the intersection of those roads.

Here's my verdict, and I'll hold it knowing the model names underneath will turn over: the gear is set by what the task demands, and the gate is set by what a mistake costs and whether anyone can catch it. Those two are not the same dial. Most of my fleet runs at low gears with no gate at all. I spend my expensive gears and my own attention on the same short list of rows: the ones with no ground truth, where wrong is costly and only a human can see it. Match the gear to the task; set the gate by the stakes; never let one decide the other.

Here's a little help understanding when to be the human gate (human in the loop) in your work. Let's say you had AI write something for your blog. If the agent finishes the blog and then it or another agent posts it immediately, you've missed the chance to fix any mistakes that are now costly. Your audience is seeing a mistake that you never wanted them to see. Because you let it be posted without you, finding the mistake later just got much harder. The AI's mistake now has the ability to live where your audience can see it. That can be devastating in an age where people lose faith in your brand if they find AI slop that was never checked by a human.

Door 1: Start matching today (beginner)

You don't need to memorize model specs. You need one question before you start a task: "Is this hard thinking, or routine work?" Hard thinking (multi-step reasoning, high stakes, expensive to get wrong) earns your more capable models. Routine work (formatting, extraction, simple drafts) goes to faster, cheaper ones. That two-bucket sort captures most of the available win.

A thirty-second version: the next time you reach for your default model out of habit, pause and ask whether the task in front of you actually needs it. Half the time it doesn't, and you just saved cost and time for free.

Before you assign a task, name its gear out loud. "This is a 2." "This is an 8." You don't need exact model names to do it. You need the honesty to admit when you're about to climb a hill in tenth gear for no reason. Pick the lowest gear that still clears the job. That one habit, run every time, is most of the win.

Door 2: Build the routing into the system (advanced)

The advanced version is to stop choosing by hand. You profile your recurring tasks once, decide which tier each one needs, and build that routing into the workflow so the right model fires automatically: cheap models on the volume steps, the expensive model reserved for the few that earn it. You also build in a fallback path: if the cheap model fails a quality check, the task escalates rather than silently shipping a bad result.

At that point model selection stops being a per-task decision and becomes a property of your operating system, one that ties directly into cost optimization (the cheap models cut spend) and measurement (the quality checks tell you when a downgrade went too far).

I used to use the highest model for everything. In my head, I wanted the smartest model doing everything. I felt like I needed it to avoid hallucinations. But the fact is, good context and tight constraints on the changes you are about to make are how you reduce hallucination.

I'm currently building a system that can code. It contains an orchestrator agent that runs the rest of the agents. I had the whole plan and was building the system and agents for weeks. In theory everything was lining up. Then I realized the best model I can run locally on my machine won't be able to do the coding portion. Even while testing the setup on simpler tasks, the 9B parameter model I had on my machine was hallucinating regularly.

It was disappointing. But it led me to the discovery. Understanding the power of the model you need, and what tasks it's good for, is one of the most important parts. I hadn't thought about that when I started my project. Now I think about it for every task.

My project has other functionality so I still want to build it, but it won't be doing any coding until I get a massive hardware upgrade. At the end of the day, knowing what you have access to and what it can do well will save you time and energy if you think about this before your project instead of during. Take it from me.

A note on naming names

I do name models in this guide, so let me be clear about what that is and what it isn't.

This is not a map of which model to use for what. There are more models out there than I could test in a year, and I haven't scraped the surface of them. What I've given you is narrower, and I think more useful: one real situation, the model that helped me in it, and how and why it helped.

Take that as a snapshot with a date on it, not a recommendation. Models, prices, and benchmarks turn over fast enough that any verdict I hand you would be wrong within months. What doesn't go stale is the method: profile the task, match the model, and look at the output yourself. The verdicts are yours to hold and update.

New models need a break-in period

There's a wrinkle here I want to be honest about, because it's the part that makes my own verdict shakier than it looks.

Both of the models I tested dropped recently. A new model is not a known quantity on day one. You have to spend real time with it to learn how it responds to your prompts, and how it behaves inside an agent, which is a different question again. The potential is in there. Getting at it takes testing and tweaking, the same as everything else worth having.

So when a new model doesn't impress you right away, you've learned one of two things and you can't yet tell which: either it isn't a fit for this job, or you haven't learned to drive it yet. Both are real. Only time at the wheel tells them apart. Decide in advance how you'll break a new model in, and you'll get to that answer faster.

That's why testing output has to be a habit instead of an event. You test when a model is new. You test again when you've had a month with it and you actually know how to ask. And you test on your own work, not on somebody's benchmark, because your work is the only bar that matters to you.

So here's my dated verdict, and the date is the important part of that sentence.

As of July 2026, for my video work, I get better output from Claude Fable 5 than from Codex Sol 5.6, even though Codex benchmarks higher. That's what I've seen with my own eyes on my own job.

Now the ceiling on it, and I mean this. My opinion is premature. Both models are new, I've spent more time with Fable 5 than with Sol 5.6, and it's entirely possible I just don't know how to use Sol 5.6 well yet. If that turns out to be true, the fix is mine and not the model's. Ask me in two months and I may have a different answer. If I do, that's the method working, not the method failing.

And notice what my verdict is not. It is not "use this one, don't use that one." You don't pick a model and retire the other. You pick the best one for the task in front of you, and finding that out means playing with both and trying different approaches. The gear is still set by the task. All the testing does is tell you, honestly, which engine is in which gear this month.

Try the system I run this on

So here is something that drives this whole thing home. I created an agnostic agentic coding system called ForgeOps. It has a constant state memory so it understands the entire project, every phase, what phase you are on, the last changes you made while coding, and the next set of changes you are going to need to make. Each change is an extremely tight scope. I do not need Fable 5 for this. Opus 4.8 will be more than adequate at half the token cost. ForgeOps is fantastic, but it's slow, on purpose. It does one change at a time. It keeps the human in the loop where things need human eyeballs or opinions.

Fable 5 is really good at seeing the big picture. It can handle looking at a very large project that doesn't have pre-planned tightly scoped changes. If you have the tokens to spare, you can have it build something from scratch. It can do large sections of work, and work autonomously for a long time with great results. You can see how the biggest gear is needed here, but not for the tightly scoped changes in ForgeOps.

My system works to build just about anything. It makes working on a project systematic and highly structured. It helps reduce hallucination with very tight scopes packed with the right context. You can try it today on Gumroad.com.