Most teams starting a new job pick the biggest model on the list. It seems sensible. Whatever the best one is, use that.
The choice backfires in two places. On the invoice at the end of the month, and in the time a user spends waiting at a screen.
A three-cornered balance
Model selection is a balance between quality, speed and cost. No option does best on all three at once. As one improves, the others give way.
Which corner matters most also changes with the job. In a reporting job that runs overnight, latency does not matter at all. In a search a user is waiting on, latency may be the measure that matters most.
Which job for which model
Small models handle some work comfortably. Classifying text, assigning labels, converting a short text from one format to another, extracting specific fields and producing a short summary all belong in this group.
Large models make the real difference elsewhere. Work that needs multi-step reasoning, finding a contradiction in a long document, writing code and fixing its bugs, and turning a vague request into a workable plan are large-model jobs.
There is a job that sits in between. Tool selection. When the tools are few and clearly different a small model is enough, and when the list gets crowded and the tools start to resemble each other, a large model becomes necessary.
The models in the catalogue and the models that work are not the same list
An example of our own is useful here. Of the twenty-four models one provider listed, only ten could actually be called.
The rest dropped out for three reasons. Some were closed to the account's access tier, some were not offered in the region, and some were versions whose names were still in the list but were no longer in use.
Do not choose a model by looking at the catalogue. Actually call your candidate, try it on your own work, then decide.
A tiered setup
You do not have to pick one model for a job. Putting two models in sequence gives the best balance in most places.
The small model tries first. If the result is good enough it stops there, and if not, the job is handed to the large model.
This setup has two conditions. The small model has to be able to say "I am not sure about this", otherwise it gives the wrong answer with confidence and the handover never fires. And the handover rate has to stay reasonable, because if every job runs twice the saving disappears.
Set up properly, the gain is clear. The easy jobs that make up most of the volume stay on the cheap side, and the hard ones go to the model they deserve.
Make the choice by measuring
Model selection debates usually stay at the level of opinion, and that is unnecessary. Measuring is a day's work.
Collect thirty or forty real examples from the past, write the correct answer next to each, run the same set through both models and compare the outputs.
That set keeps paying later. When the provider ships a new version you run it again and see whether anything broke.
Trying to fix quality by upsizing the model
When the output comes back poor, the first reflex is to move to a bigger model. Most of the time the problem is not the model.
The instruction may be vague, the necessary information may never have entered the context, or the expected output format may not have been described. Upsizing the model without fixing those does not solve the problem. It only makes it more expensive.
Would a person get it right if you gave them the same request? If not, what is missing is the description, not the model.
Latency is a quiet cost
The invoice is visible, latency is not. Yet anywhere a user is waiting, seconds land directly on usage.
In background work the picture flips. If an overnight job takes thirty seconds instead of five nobody notices, and preferring quality there is the right call.
That is why model selection should be made job by job, not for the whole product. Picking one default and applying it everywhere means overpaying on the cheap jobs and falling short on the hard ones.