Key takeaways
- Providers sell a range of models at very different prices. Using one model for everything ignores your main cost lever.
- Route by task shape, not by importance. A critical task can still be simple.
- Smaller models are usually faster, which users notice and prefer on routine work.
- Write the routing map down. An undocumented convention decays within a month.
If you inherit one habit from this blog, make it this one. Most businesses that feel their AI spend is disproportionate are not using AI too much. They are using an expensive model to reformat a list, and doing it several thousand times a month.
Every major provider sells a family of models rather than a single product: fast and cheap at one end, slow and highly capable at the other, usually with something in the middle. The gap between the ends is frequently around an order of magnitude in price. Deciding which end handles which job is the highest-return, lowest-effort cost decision available to you.
Why the default is always the expensive one
Two reasons, both understandable.
First, interfaces default to the newest flagship, because that is what providers want you to experience. Nobody chose it. It was simply already selected, and most people never open the dropdown.
Second, when a developer or an enthusiastic staff member builds something, they use the model they trust to work while they are getting it working. That is sensible during development. What rarely happens is anyone going back afterwards to ask whether the cheaper model would have been fine in production. The prototype's model becomes the production model by inertia.
A useful analogy for the budget conversation: nobody sends every parcel by overnight courier. You send the urgent ones that way and the rest by standard post. Model routing is the same decision, and it is just as unglamorous.
Route by task shape, not by importance
The instinct is to reserve the best model for the most important work. That is the wrong axis, and it leads to expensive routing decisions that do not improve anything.
Importance tells you how carefully a human should check the output. It does not tell you how much reasoning the task requires. Sending a client invoice is important; extracting the invoice number from a PDF is trivial. Use the cheap model and check the result carefully.
The axis that actually matters is task shape. Four questions determine it:
- Does it need multi-step reasoning? Working through a chain of dependent inferences is where larger models genuinely earn their price.
- How much material must be held at once? Comparing three long documents is qualitatively harder than summarising one short one.
- Is the output format tightly constrained? Pulling structured fields out of text is something small models do well and cheaply.
- Is there a single right answer or a judgement call? Judgement, tone and nuance benefit from capability. Lookup and transformation do not.
A routing map you can adapt
| Job | Model tier | Why |
|---|---|---|
| Classifying or tagging incoming messages | Small | Narrow output, no reasoning chain, very high volume. |
| Extracting fields from documents | Small | Structured transformation with a checkable result. |
| Reformatting, tidying and restructuring text | Small | No new information is being produced. |
| Short internal drafts and replies | Small or mid | Speed matters more than nuance, and a human reviews it anyway. |
| Summarising a single meeting or document | Mid | Some judgement about what matters, moderate length. |
| Client-facing drafts where tone matters | Mid or flagship | Nuance is the product, and rework is expensive. |
| Analysis across several long documents | Flagship | Sustained reasoning over a lot of context, where smaller models degrade. |
| Code, complex spreadsheets, technical problem solving | Flagship | Errors are costly, subtle, and easy to miss on review. |
Treat this as a starting position rather than a verdict. The specific boundary between tiers moves with each generation of models, and it moves downward: tasks that needed the flagship last year are frequently handled well by the mid tier now. That is another reason to write your map down, because it gives you something to revise.
How to test a downgrade honestly
Do not do this by intuition, and do not do it by asking people whether they think quality dropped, because expectation contaminates the answer.
- Take twenty real recent examples of the task, with their actual inputs.
- Run them through both the current model and the cheaper candidate.
- Strip the labels so the reviewer cannot tell which is which.
- Have the person who normally does the task mark each output acceptable or not acceptable, not better or worse.
- If the cheaper model is acceptable on at least nineteen of twenty, switch it and note the date.
Acceptability is the right threshold rather than preference. A reviewer asked which output is better will always find a preference, even between two perfectly usable results. The business question is whether the output does the job.
Frequently overlooked upside: smaller models are usually much faster. On interactive tasks, users often prefer them for that reason alone, which means the cost saving and the experience improvement point the same way.
Where downgrading is a false economy
Three situations where reaching for the cheaper model costs more than it saves:
When the failure is silent. If a wrong answer looks exactly like a right answer and nobody would catch it, the saving is not worth it. Financial calculations and legal summaries often fall here.
When retries eat the saving. A cheaper model that needs three attempts and human correction is not cheaper. Measure the whole loop, not the per-request price.
When the task is rare. Optimising something that runs four times a month is effort spent for nothing. Route by volume first and ignore the long tail.
Make it stick
A routing decision that lives in one person's head lasts about a month. Three things make it durable:
- Write the map down in the same place as your staff guide, in task language rather than model names alone.
- Set defaults centrally where the admin console allows it, so the right choice is the one that happens automatically.
- Review quarterly. New models arrive, prices shift, and last quarter's flagship task is often this quarter's mid-tier task.
Frequently asked questions
Which AI model should a business use?
More than one. Route routine, high-volume work to a provider's smaller model and reserve the flagship for multi-step reasoning, long documents, nuanced judgement and code.
Will staff notice a cheaper model?
On routine work, usually not, and they often notice the extra speed favourably. Be careful on tasks that need sustained reasoning across long material, where the difference is genuine.
How much does routing save?
It depends on your task mix, but with roughly an order of magnitude between small and flagship pricing, moving the routine majority down a tier removes a large share of usage-based spend without a visible quality change.
Should we let staff choose the model themselves?
Give them a documented default per task and the freedom to escalate when something is genuinely hard. Full discretion with no guidance means everyone uses the flagship, because it is the safest-sounding option.
Have the routing map built for you
Model selection matched to jobs is part of the Implementation Package, along with hard spending limits, admin configuration and a staff guide that tells people which model to use for what. Fixed price, live in 30 days or less.