Why I use different AI models for different jobs

I use more than one AI model when I’m building software. DeepSeek handles much of the routine implementation: writing code, making changes and working through test failures. I bring work to a model I use for deeper reviews in ChatGPT when I want to challenge an approach, review the architecture or look for mistakes before moving forward.

That division of work has made me think differently about AI costs. A project contains hundreds of small tasks, but some decisions carry far more weight than others. Choosing where to spend on deeper reasoning matters as much as choosing which model to use.

The aim is straightforward: use a model that can do the job well, and bring in stronger reasoning where it can make a meaningful difference.

Different work needs different judgement

Changing a repeated interface pattern and deciding how an application should handle sensitive information are very different jobs. Both might produce code. The consequences of getting them wrong are quite different.

For a clearly defined change, a faster, lower-cost model can be a useful starting point. When the requirements are unclear, the design affects several systems or the change is hard to reverse, I want more scrutiny before implementation gets too far.

We already recognise this distinction in engineering teams. A senior architect doesn’t need to write every routine change, but their judgement can shape the whole project. I think there is a similar opportunity with AI, provided we assess models against the actual work rather than assuming that price proves capability.

This approach also appears in published engineering guidance. OpenAI recommends establishing an accuracy target, then testing whether a smaller model can meet it at lower cost or latency. Its model selection guide puts acceptable quality first.

Build, review, refine, check again

My workflow moves between implementation and review. The faster model produces a change. A stronger model challenges the reasoning behind it, reviews the code and points out possible gaps. The implementation model can then work through the corrections before another review.

1. 01BuildImplement the agreed change.
2. 02ReviewChallenge the approach.
3. 03RefineWork through corrections.
4. 04Check againReview the revised work.

The review needs context: what the change is meant to achieve, what must stay intact, and what the tests actually cover. Asking whether some code “looks good” is much less useful than asking how it could fail or whether it meets a specific requirement.

Anthropic describes both routing work to different models and using a separate evaluation step to improve an output in its guide to building effective agents. Those patterns provide a useful way to think about the process, even when the handovers are manual.

A second model’s approval still isn’t proof that a change is correct. Models can share blind spots, and tests can miss important behaviour. For work going into production, I still want automated checks, practical testing and someone responsible for approving the release. A model review is another source of feedback within that process.

Count the cost of finished work

The price of a token, the unit used to measure model input and output, tells only part of the story. Repeated attempts, long explanations and extra reviews all add to the bill. So does the time a person spends correcting an answer.

I’d judge a mixed-model workflow by the cost of getting an acceptable result. That includes model usage, waiting time, review effort and rework. A cheaper model that needs several attempts may cost more overall than a stronger model that gets a difficult task right sooner.

There is also a cost to splitting work between tools. Context has to travel with it. Requirements can be lost in a handover, and someone has to decide when to stop iterating. A simple task may be best completed with one model and a clear check.

For a useful comparison, I’d track a few things across representative tasks:

• Whether the result meets the agreed requirements.
• Total model spend, including corrections and review.
• Time to an accepted result, including human effort.
• Errors found during testing and after release.

Any savings need to be measured on the work itself, including the review effort. The point is to test where a less expensive model is sufficient and where extra reasoning earns its place.

More AI use doesn’t mean the same growth in revenue

This is where the wider economics become interesting to me. If less expensive models become capable of work that previously needed a frontier model, users have a reason to move that work down the price ladder. Frontier models, the most capable general models available at a given time, may remain valuable for the difficult decisions.

That could let AI usage grow much faster than spending. As a purely hypothetical example, if the number of comparable paid tasks grew fiftyfold while the average revenue per task fell twentyfold, total revenue would reach 2.5 times its original level. Those figures illustrate the arithmetic; they are not a market forecast or a result from my workflow.

I’m cautious about the idea that ever more AI activity automatically justifies any level of infrastructure spending. The amount of compute needed for a useful result can change as models, software and routing improve.

There is another side to this, though. Lower costs may encourage people to attempt far more work, and new tasks may demand much more reasoning. Total demand for compute could still rise substantially. My view is that useful output, usage and provider revenue need to be considered separately. A rising token count alone doesn’t settle the business case.

Make model selection part of the process

I expect more of this routing to become automatic. A system could choose a model based on the task, an agreed quality threshold, a time limit and a spending limit. It would also need to know when to stop, ask for help or send a decision to a person.

For a business starting today, I’d keep the first version small. Choose a repeatable task, define an acceptable result and compare a few approaches using the same examples. Agree which data each tool may receive. Set clear escalation points for uncertainty, failed checks or decisions with significant consequences.

That is the direction I find most useful: fast models doing suitable routine work, stronger reasoning at the important decision points, and people responsible for the outcome. The model names will change. A clear process for using them can remain valuable.

If you’re considering where this approach could fit in your organisation, see how we help with AI systems and agents.