I build systems that choose an economical AI model for each job. When I open a conversation for myself, I choose the smartest one I can get.
Even if the question looks simple. Even if I am only trying to untangle an idea that has been bothering me for twenty minutes. I look at the cheaper options, acknowledge their existence, and select the top one anyway.
I admitted this in a LinkedIn post in September. I understand the economics of “good enough”. I am much less enthusiastic when somebody proposes applying them to me. [1]
There is a reason, although I am still trying to establish how good a reason it is. A more capable model might notice something I did not know to ask about. It might question the assumption under my question. It might find the angle that turns a competent piece of work into something I actually want to put my name on.
Or I might be paying to avoid the irritating thought that a better answer was available and I chose not to ask for it.
Both possibilities deserve a place in this conversation. My AI bill has already made room for them.
For most of the past year, I have spent six to ten hours a day building with AI. From last December to this October, the experience has kept expanding my sense of what I can make. I have spent serious money finding that out.
By the smartest model, I mean the one I currently trust most for the work in front of me. There is no permanent winner for every task. I still have favourites, and my favourites tend to arrive with the more ambitious settings enabled.
Then I read Thoughtworks’ account of how it plans to reduce its AI costs while expanding access across the company. I enjoyed it enormously. It made me think harder about where my own apparent inconsistency makes sense, and where I am simply indulging it. [2]
What I am afraid of missing
When I ask AI to help me think, the request I type is often an early attempt at describing the problem. I expect the conversation to improve it.
Suppose I am writing about why a teenager should use AI to learn. I can ask for ten good examples and receive ten good examples. But I also want someone to ask whether the teenager has reliable access, whether the explanation helps them understand, and whether I have confused finishing the homework with learning the subject.
Those questions can change the article. A polished list that obediently follows my original instruction may leave all of them untouched.
The same thing happens when I think through a business idea. I might ask how to reach a particular customer. The useful interruption could be that I have misunderstood who has the problem, or that the person who benefits cannot authorise the purchase. More eloquent outreach would do very little for either mistake.
This is where I find it hardest to come down from the strongest model:
- I am still deciding what the problem is. An early conversation, a new idea, a piece of research whose implications I do not yet understand.
- The first decision will shape many later ones. A product’s structure, a data model, the promises a service makes, the central argument of an article.
- I want the premise challenged. Following my instruction accurately could still take us in the wrong direction.
- The work connects several subjects. Technology and incentives, education and confidence, a user’s request and the circumstances behind it.
- I cannot easily see what has been omitted. I can spot a misspelling. It is harder to spot an important consideration that never appeared.
That is my reasoning for paying more. It is not evidence that the model will do all these things. An expensive model can agree with a bad premise at considerable length. I have to ask it to challenge me, check the challenge, and decide whether it matters.
Nor should I confuse an elaborate answer with an intelligent one. Sometimes the better answer is a short question that makes my original request look rather silly.
The first build gets the best seat
My coding habits reveal the same preference, with one useful difference.
For a first build, I tend to choose the top model and the highest reasoning effort available. I want it to consider the shape of the thing before it starts filling in the rooms. A single ambitious request can take a painful bite out of my allowance. I will inspect the usage meter, reflect on my choices, and quite often make the same choices again the following morning.
The first build feels consequential. It establishes assumptions that subsequent work may inherit. Who is allowed to see a record? Where does the information come from? What happens when a job fails halfway through? How will a person recover something they spent an hour writing?
Those questions are easier to neglect when the screen already looks impressive.
Take a blog. Before the first version exists, we need to decide what makes it worth reading, how the cartoons carry the argument, how someone finds another story, and whether a draft can accidentally become public. “Build a blog” contains rather more than a heading and a grid.
Once we have agreed the reading experience, asking for equal image sizes is a more bounded job. I can see whether it has been done. I can inspect the page on a phone. I can point to the card that still looks wrong.
For that sort of iteration, I often move to a strong second choice and reduce the effort to medium. The work has acquired a target against which I can judge it.
Medium effort is not a confession of low standards. Sometimes it is enough because we have finally done the hard work of deciding what we want.
I am still careful with the word “small”. Moving a button may be straightforward. Changing who is allowed to press it can lead straight into permissions, security and the way the entire system works. A task can become difficult after it has begun. I need to be able to reconsider the model along with the task.
Part of me would like the rule to be: pour all the creativity in before coding, then let the code get on with it. A very attractive rule. It would save everyone a lot of trouble if building things agreed to follow it.
It does not. Implementation exposes missing ideas. A failed test can force a design decision. Looking at the first working version can reveal that we asked for the wrong thing. Coding involves judgement and invention all the way through.
The distinction I can defend is between work whose requirements we are still discovering and work we understand well enough to test. Both happen while coding. Both happen outside it.
The smartest model still has to finish
There is another complication in my expensive preference: waiting.
Recently, I have had sessions with Claude and ChatGPT where an hour or two passes with so little visible progress that I end up asking what happened. Sometimes the work then seems to come alive again. From my chair, it is difficult to tell what the system was doing during the interval.
I cannot diagnose that from a conversation window. It might involve tools, queues, the length of the job, or something else entirely. I can report the lost time and the lack of a useful explanation. I cannot turn either into proof of the cause.
A spinning indicator is remarkably economical with information.
Highest effort also needs to earn its place. More computation may help with a difficult problem; choosing the maximum setting for everything is still a habit I ought to examine. There are jobs where a faster, adequate answer lets me take the next step while the supposedly ideal answer is still considering its position.
I want to know what improved. Did the stronger model prevent a bad architectural choice? Find a source we had missed? Remove hours of rework? Or did it produce a more impressive account of the same answer?
My preference becomes more defensible when I can answer those questions. “I selected the highest setting” tells us what I bought, rather than what I gained.
Thoughtworks made the bill discussable
Thoughtworks reported spending $450,000 a month on frontier-model APIs for internal use by September 2026. At that scale, a personal preference for the best model becomes a purchasing policy with a very large invoice attached. [2]
Its response was to examine actual usage: what people were doing, how much context they reused, when demand arrived, which work needed more capable reasoning, and which work carried information requiring tighter control.
It then tested combinations of models and hosting arrangements against its traffic. That last part matters. An attractive price per token says little about whether a model can do your job, or whether a dedicated server will sit idle through the weekend.
The resulting approach keeps frontier models for demanding work and uses open-weight models for other workloads, with different hosting arrangements where they make sense. People choose high, medium or light tiers. The models and providers behind those tiers are reviewed as capabilities, prices and demand change.
Someone has studied the work, made decisions, and arranged to revisit them. The tiers give people a manageable choice while the team deals with the changing suppliers behind it.
The headline 72% reduction concerns the worst-case 2028 cost forecast. It is supported by measurement and modelling, but it is a forecast, and the stated inference figures exclude the platform team and change programme. I would keep those qualifications attached to the number. A projected saving has yet to pay an invoice.
What impressed me was that the plan makes wider access something leadership can budget for. The strongest model remains available where it earns its place. Routine work has other options. A growing bill becomes a set of decisions people can examine.
For my own systems, I want the calculation to run all the way to a result someone can use.
If a cheap answer needs three retries and twenty minutes of checking, I want that counted. If an expensive answer saves none of that effort, I want that counted too. The checking may be necessary whichever model we use; hiding it makes the comparison less useful.
Routing research gives us reason to take economical combinations seriously. It also gives us reason to test our own tasks. RouteLLM’s experiments showed that routers trained on general chat preferences could perform poorly on different kinds of questions until they received relevant examples. A router learns something about the work represented in its training. That is a useful capability with a boundary. [3]
When the same decision runs a million times
This is where my behaviour changes most sharply: when I stop being the person having a conversation and start building software that will call AI repeatedly.
I cannot afford a system that casually develops a $100,000 monthly token habit. I have put considerable work into routing, selection, decisions and enrichment because the economics have to survive repeated use.
Imagine a system reading incoming messages. It needs to decide which are relevant, identify the subject, direct them to the appropriate place and flag the cases a person should inspect. Some messages will require deeper investigation. Many will not.
I want creativity when we design that system: what counts as relevant, what a costly mistake looks like, which evidence matters, when the system should stop. Once we have established and tested a particular decision, I want it made reliably and economically each time it recurs.
I do not need a fresh essay on the philosophy of customer service before every message reaches the billing team.
This is why Jev caught my attention. TypeSafe built it to return structured decisions that software can use: choices, scores and probabilities. It gives up free-form writing to concentrate on that kind of work. [4]
In September, I posted that the problem was “NOW SOLVED”. My enthusiasm was real. “Solved” was doing rather a lot of work. [1]
TypeSafe’s headline claims of roughly 200 times the speed and 400 times lower cost came from its own selected workflow evaluations. The launch article explains the comparisons and acknowledges that those figures sit towards the upper end of likely real-world gains. They are worth investigating on the right tasks. They do not establish that Jev replaces a general model across everything I do. [4]
OpenAI’s Decisions API, launched in public beta on 6 October, points towards a similar need for a different interface. It takes text or images and returns a probability, a choice from supplied options, or a score against a rubric. Written explanations, arbitrary structured documents and tool calls belong to other interfaces. [5]
At the time of writing, Jev’s published input rate is $0.042 per million tokens; the Decisions endpoint’s rate with GPT-6 Luna is $0.10 per million input tokens, with no output-token charge on either. Those prices are striking. I would still have to test their decisions on my own work. [4][5]
The interesting change is what becomes possible when a small decision can be made quickly and cheaply enough to sit inside ordinary software. You can inspect more material, make finer distinctions, and reserve human attention for the cases that deserve it. Whether that works depends on how well the decisions hold up.
This is also why “open” and “closed” are insufficient shopping instructions. Open weights give you a way to run and adapt a model under its licence. They do not automatically give you the lowest delivered cost. Hosting, utilisation and the people operating the system still count. Thoughtworks’ own analysis makes that clear. [2]
Someone still has to know what good means
Routing products and open-source projects already exist. LiteLLM provides routing infrastructure, including complexity-based model selection; OpenRouter offers automatic model routing; RouteLLM provides an open research framework. [3][6][7]
What I still want is confidence that the choices fit my work, that I can understand failures, and that unusual cases get a way out. Buying access to a router does not settle those questions.
Suppose a system chooses among five possible replies. It can always return a valid option and still select the most useless one. A reply can be grammatically excellent, relevant to the broad topic, and add absolutely nothing to the conversation.
We need examples of useful replies and disappointing ones. We need to explain the difference. We need to notice when the right response is to ask for more context, or to say nothing. And we need to test whether our judgement carries across subjects and situations.
The same is true of typed decisions. A guarantee that the answer fits the allowed structure does not guarantee that the judgement is correct. A system can be impeccably formatted and confidently wrong. The neatness makes it easier to connect to other software, which is precisely why the mistakes need attention.
This leaves a difficult question for my own preference. If a stronger model spots something outside the evaluation, how will we recognise its value? And if it invents a concern that merely sounds profound, how will we recognise that?
An unexpected observation earns its place by being relevant and supportable. Surprise alone is a very poor quality standard. So is the reassuring feeling that I consulted the most prestigious model.
For repeated decisions, I want representative examples, a clear account of the mistakes that matter, and checks on actual results. I want the system to send uncertain or unusual cases for a stronger review, which may involve a person. I also want to inspect some cases it considered easy, because a mistake does not always announce itself with low confidence.
For open-ended work, I need a different discipline: check the sources, ask what would change the conclusion, examine the alternatives, and keep responsibility for the final choice. A longer conversation gives me more opportunities to think. It does not relieve me of thinking.
What I want the saving to buy
The person who already knows a subject can often recognise a shallow answer and ask a better question. A beginner may accept the first fluent explanation because they have little basis for challenging it.
That matters when we decide who gets access to what kind of help. I would be uncomfortable with a system that permanently reserves its most capable assistance for people who already know how to demonstrate their expertise.
Consider a student who asks AI to help with an essay. There are routine jobs in that conversation: organising notes, finding a repeated paragraph, checking whether a quotation appears in the supplied source. There are also moments when the student’s understanding needs attention. They may be repeating a claim they do not believe, or misunderstanding the question entirely.
The useful tutor notices the difference. It helps the student do more of the thinking themselves. A cheaper service is valuable if it makes that help available more often. A more expensive one is valuable if it actually helps the person learn something they otherwise would have missed. We have to look at the learner to know.
I want efficiency to buy more chances: another explanation, another attempt, time to explore an idea before deciding it is beyond you. Someone with a small budget should be able to ask an untidy first question and gradually discover a better one.
That is also what I am doing, with a rather more expensive subscription.
So I still choose the smartest AI for most of my own conversations. I am paying for the possibility that the conversation will improve the question. For first builds, I still favour the model I trust most to see the consequences of the early choices. As the work becomes clearer, I am much more willing to change models and settings. For repeated decisions inside software, I want evidence that the least expensive adequate approach really is adequate.
I expect those habits to change as I get better at judging the results. They should.
Tomorrow I will probably open a new conversation and select the top model again. What I want to get better at is recognising when it made a difference.