Stop Using Your Smartest AI For Everything

I have just run into a problem while building one of my Orchistra systems.

It was not that I did not have enough intelligence available.

It was that I had no sensible way to decide how much intelligence the job actually needed.

We now have OpenAI's Luna, Terra and Sol. Anthropic has Haiku, Sonnet, Opus and Fable, with Mythos available for a much narrower defensive-security route. Google, xAI, Mistral, DeepSeek, Kimi and Qwen all have their own versions of fast, balanced, reasoning and frontier models.

Then, inside some of those models, we can choose how hard they think.

None. Low. Medium. High. Extra high. Maximum.

Come on. We have never had to manage intelligence like this before.

We do not hire people by IQ setting

When we recruit a person, we do not normally say:

I would like somebody with an IQ between 110 and 120, using medium reasoning effort, please.

We say we need an experienced architect. A junior analyst. A careful bookkeeper. A developer who understands a particular system. Someone who can work with customers. Someone who has done this before.

Then reality gets involved. Who is available? What can we afford? Will they enjoy the work? Will they stay? Does it fit their career? Do they want to travel?

AI changes that calculation.

A frontier model can do a routine job without becoming bored. It will not resign because the work is beneath it. It will not ask for a promotion. If we can afford to use it, we can.

But that does not mean we should.

Using the most capable model for every task is like sending your most expensive architect to rename 10,000 files. They may do it beautifully. It is still a peculiar use of the budget.

A model is not an IQ score

There is an important warning here.

Sol is not a person with a higher IQ than Terra. Fable is not simply a more educated Sonnet. Model families differ in training, latency, tool use, context handling, coding behaviour, safety controls, modality and price. They can also fail in different ways.

The harness matters too.

The same underlying model can perform very differently depending on the instructions, memory, tools, permissions, retry policy, stopping rules and evidence the harness gives it. A cheaper model inside a well-designed harness may finish a task more reliably than a frontier model wandering around with vague instructions.

So there are at least three dials:

1. Model family: the broad capability, speed, context and price envelope.
2. Reasoning effort: how much model work to spend on this particular request.
3. Harness: the tools, memory, rules, permissions, tests and recovery route around the model.

If we only discuss the model name, we are discussing one part of the worker.

Use the smallest model that can reliably finish

I think the operating rule is quite simple:

Use the smallest model and reasoning level that can reliably produce an accepted outcome. Escalate when the evidence says it cannot.

The last four words matter.

Do not choose the cheapest model because its token rate looks attractive. A cheap model that loops, retries, uses more tools, produces work that needs rewriting or quietly fails the task can be the expensive option.

Do not choose the frontier model because the label makes you feel safer either. More reasoning is not automatically better. OpenAI's current guidance explicitly recommends comparing configurations on representative tasks rather than assuming the highest effort is the best trade-off.

The useful measure is not cost per token.

It is cost per accepted outcome.

Three useful lanes

I would begin with three lanes. They are not laws. They are a starting hypothesis to test.

Lane	Typical work	Starting route	Escalate when
Routine	Classification, extraction, reformatting, tagging, simple summaries, monitoring and bounded scheduled tasks.	Fast or high-volume model; no or low reasoning.	Accuracy falls below the threshold, exceptions require judgement, or tool use becomes multi-step.
Professional	Drafting, analysis, ordinary coding, document comparison, planning and reliable tool-using workflows.	Balanced model; medium reasoning.	The task is novel, ambiguous, consequential, long-running or repeatedly fails its acceptance tests.
Frontier	Architecture, difficult debugging, complex research, high-value review and decisions where marginal quality matters.	Frontier model; high reasoning only where evaluations justify it.	Increase effort or use a specialist route when the measured quality gain justifies the time and cost.

For my own OpenAI work, that often means Luna for narrow routine tasks, Terra for everyday building and agentic work, and Sol for difficult architecture, research and problem solving.

But I would not hard-code that judgement forever. Terra at a higher effort may beat Sol at a lower effort on a particular workflow. Luna inside a tight deterministic process may be all the intelligence the task needs. The only honest way to know is to run the same representative work and compare the outcomes.

Ask the harness before it starts

A good harness should help us make this choice.

Before a substantial task begins, I want it to be able to tell me:

• Which model it proposes to use.
• Which reasoning level it proposes.
• Why that combination fits the task.
• What it expects the main cost and latency drivers to be.
• What evidence would trigger an escalation.
• Whether tools, context, data location or security constraints change the choice.
• How success will be measured.

If the harness cannot answer those questions, I would take that seriously.

That is not because the harness should be conscious or possess some magical self-awareness. It is because an operating system for agentic work should expose its own route. It should know which model is configured, what controls are available and why it is spending the company's money.

Here is the prompt I would use:

Before starting, recommend the cheapest model and reasoning level likely to complete this task reliably. Explain the choice, the success criteria, the likely cost and latency drivers, and the evidence that would cause you to escalate. Account for tools, context, permissions, data restrictions and the consequences of failure. Do not switch models without recording why.

The recommendation is a hypothesis. The evaluation decides whether it survives.

The current model field guide

This guide reflects provider documentation available on 24 August 2026. It is a map of intended roles, not an independent quality ranking.

On a phone, swipe the table sideways to see every route and recommendation.

I have deliberately not put a UK sovereign model into a named performance tier. Sovereignty, hosting location and control can be decisive selection criteria, but they do not by themselves tell us the model's task quality. For a local or sovereign deployment, I would use the same method: define the work, run the evaluation, measure the accepted outcome and include the cost of operating the model.

Review the route every month

This is not a decision we can make once.

Model names, prices, context windows, tool support and reasoning controls now change quickly enough that a route which made sense three months ago may be wasteful today.

I would add a small monthly model review to every serious agentic system:

1. Take a fixed set of representative successful and difficult tasks.
2. Run the current model and one plausible cheaper route.
3. Compare success, human correction, retries, tool calls, latency and total cost.
4. Check whether the provider changed the model behind an alias, its price, its limits or its regional availability.
5. Promote the cheaper route only when it meets the acceptance threshold.
6. Keep an escalation path for exceptions.

Do not optimise away the evidence. A cheaper answer is not cheaper if nobody can trust it.

We are learning to manage intelligence

This is the new management skill.

We are not only deciding what work should be done and who has authority to do it. We are deciding how much model capability, reasoning, context and tool access the work deserves.

The companies that learn this will get much more from the same token budget.

They will reserve frontier intelligence for the places where it genuinely changes the answer. They will use cheaper models for repeatable work with clear tests. Their harnesses will expose why a route was chosen, when it escalated and whether the result was accepted.

So next time you open Codex, Claude or another harness, do not immediately turn every dial to maximum.

Ask it what the work needs.

Then ask it to prove it.

Related reading

• What Does AI Cost This Month? August 2026
• The AI Harness Is Becoming The Operating System
• The Harness Is The Employee. The API Is The Contractor.
• AI Is Not One Thing