Choose the model around the work—not the other way around.
Once you are comfortable with a vendor’s stability, the next question is what actually powers the product. The largest available model may sound like the safest choice, but it is often more capability—and more cost—than the job requires.
The better question is simple: What kind of work does this model need to do?
Use smaller models for predictable work.
Small language models can be a strong fit for repetitive, high-volume jobs such as classifying tickets, extracting information, validating fields, or answering from a defined knowledge base.
Reserve frontier models for real complexity.
Larger frontier models earn their higher cost when the work requires broad reasoning, complex judgment, or questions you cannot easily predict. Paying for that level of capability on every routine request is rarely necessary.
Route the work instead of forcing one choice.
A practical deployment can send routine requests to a smaller, more efficient model and escalate genuinely complex cases to a frontier model. Ask whether the vendor can route work this way—and whether the savings reach you.
Match the model to the actual input.
A contact center may need strong voice capability. Other operations rely on screenshots, photographs, or scanned documents. A model that performs well on text but struggles with your real inputs is still the wrong model.
Ask the vendor
- Which model powers this specific use case?
- Can routine and complex requests be routed differently?
- How do model choices affect performance, cost, and future upgrades?
One useful step this week: List your three highest-volume AI tasks and label each one predictable or judgment-heavy. Then ask the vendor which model it would use for each task—and why.
Bonus tip:Â Bring 20 real examples to the demo: a mix of routine requests, messy inputs, and edge cases. A model comparison using your own work is more useful than a generic benchmark slide.
Mapping AI to your operation?
Ian would be glad to compare notes on where a smaller model may be enough—and where deeper capability is worth paying for.
Talk with Ian: Schedule a Conversation with Ian
