I do not want the most expensive AI model doing every job. I want enough capability for the work, enough review for the consequence, and a clear reason to spend more.
When comparing AI workflows, I count three costs: the price of the model, the time people spend preparing context and checking the result, and the cost of being wrong.
Those costs change with the job.
Reformatting approved copy or naming a small set of internal files can be easy to check. Speed and cost matter. A quick comparison with the originals may be enough when a mistake is reversible and has little consequence.
Preparing an account brief, comparing products, or drafting a marketing campaign requires more context and judgment. I want the sources attached, the assumptions visible, and a person who knows the subject to review the result.
Patient-facing communication, financial records, clinical material, permissions, billing, and anything sent externally deserve a higher bar. A stronger model may help, but the model is only one part of the decision. Those jobs also need reliable source data, restricted access, a review step, and a clear point where the system stops and asks a person.
GitHub's automatic model selection illustrates the tradeoff. Its efficiency, balance, and intelligence preferences adjust how it weighs cost, quality, and response time. GitHub says the system still considers each task, so even an intelligence preference can route a simple prompt to a smaller model. The setting expresses a priority; your own results determine whether that priority suits the work.
The right way to choose is to test the task.
Start with work your team already understands. Write down what an acceptable result looks like, run the same type of job with the settings you are considering, and include correction time in the comparison. If a cheaper run saves a few cents but creates twenty minutes of cleanup, it was not cheaper. If a higher-effort run produces a polished answer from the wrong record, it still failed.
Keep the comparison fair. Give each version the same source material and judge it against the same acceptance criteria. Include ordinary work and the awkward cases: a missing field, conflicting records, or a request that should be handed to a person. Record whether the result was usable, how long correction took, and why it failed. A faster first answer has little value if the team spends longer repairing it.
I would give each recurring workflow a simple service level:
- Low consequence: optimize for speed and cost, with a fast verification.
- Moderate consequence: use more context, require sources, and review before use.
- High consequence: use the capability the task needs, then add hard permissions, evidence, approval, and a record of what happened.
The labels matter less than deciding before the work begins. Otherwise teams reach for the biggest model by habit, or choose the cheapest one without counting the work it creates afterward.
Pick one recurring job this week and compare two levels of effort. Measure the completed result, the correction time, and the consequence of a mistake. Put the more capable model and the most careful review where failure costs more.