Prompted by IndyDevDan's videos on model routing and model tiers.
Most conversations about AI collapse into one question: which model is the best one? It sounds practical, and it quietly treats an entire business process as a single giant request. The better question is which job this is, and which option is cheap enough and reliable enough to do it.
Picking a favorite is how the trouble starts. You choose the smartest option you can afford, point everything at it, and move on. Then routine work consumes premium pricing, simple requests inherit the slowest response, and one vendor having a bad afternoon stalls everything you built at once.
Give each job a tier, not a leaderboard winner
A workable approach sorts work into three tiers. A lightweight tier handles narrow, frequent tasks with an obvious definition of success: tidying a record, sorting an inbox, pulling a field out of a document. A workhorse tier carries the repeatable business processes that make up most of your volume. A top tier is held back for genuinely hard work, or for the cases where being wrong is expensive.
rTech tested that on its own work. It ran six AI model settings against six real tasks it had already finished, twice each from the same code and brief, with a script scoring the results against hidden checks. Opus at medium effort passed 11 of 12 runs, Sonnet at medium 9 of 12, and Sonnet at low 7 of 12; on one task the check passed whether or not the work was right, and the settings that failed it quietly deleted the tests that prove a delete-protection rule works. Only Opus at medium kept those tests both rounds, so rTech now sends read-only and documentation work to Sonnet at medium and anything touching code or safety to Opus at medium.
The takeaway for a business is that model choice stops being a contest and becomes a routing decision: use the least expensive option that reliably completes the task.
Reliably is the word that matters
A cheap attempt is not cheap if it produces retries, cleanup by hand, or output nobody can use. The same scrutiny applies to speed. A tool can look fast while the person waiting on the finished result is still waiting.
So measure the whole task rather than the price of one request. Define an observable bar for what finished looks like. Try the least expensive tier that looks capable. Time it from request to a result that clears the bar. Count the retries and the failed attempts in the cost. Escalate only when output misses the bar, and write down why it missed, so the next routing decision is better informed than the last one.
Let code decide whether the work passed
Routing without checking is only cost allocation. The piece that turns it into something repeatable is a check written in code rather than in a request: required fields present, numbers adding up, a schema satisfied, a test passing. If the check fails, the concrete failure goes back for another attempt. If it passes, the work moves on.
This is the same discipline that applies anywhere in a business: a rule described in an instruction is a suggestion, and a rule enforced by a step that refuses to continue is a rule. Where a requirement can be expressed as a check, let the check decide.
Ask whether the model failed or the setup did
There is one question to answer before paying for a higher tier. Did the model fail, or was the task given to it underspecified? Clearer instructions, the right background material, and a narrower job description routinely lift what a mid tier option can accomplish. Upgrading first hides a design problem behind a larger bill.
For anything the business genuinely depends on, add one more consideration: can you substitute another provider? Keeping a tested alternative reduces how much of your operation rests on one vendor. The alternative has to clear the same bar, though. A backup nobody has ever run is a name in a settings file.
What this gives the people doing the work
Routing is not about removing anyone from the process. It is about spending your capability where ambiguity actually lives. The narrow, repetitive parts go to a cheap tier that does them all day without complaint, which gives your staff back the hours those tasks were eating. The genuinely hard calls stay where judgment belongs, with a person who now has time to make them properly and a stronger tool helping with the parts that are hard to think through.
The point is not that one model has become the best. It is that different jobs have different requirements, and the right option for a job changes as price, speed, and quality change. A written routing rule survives those changes. A favorite does not.
The first step
Pick the one workflow in your business where AI already runs, and write down what finished looks like for it in a sentence a script could check. That sentence is the start of a routing rule. You can request an assessment and we will map the workflow, name the tiers, and write the check with you.