I don't think your best AI model should be your default AI model. That's how a business ends up paying for a Nobel committee to sort the post.
AI models are the engines inside tools such as chatbots and automated office software. Some are priced for demanding work, others for cheaper everyday jobs. The useful question isn't which engine looks cleverest in a demonstration. It's what you actually need it to do, and what an acceptable result costs.
My suspicion is that the premium end of AI benefits from a wonderfully convenient confusion: people hear “more capable” and translate it into “necessary”. The model supplier gets paid. The software seller gets a shinier sales pitch. The customer gets to explain why filing an enquiry now requires the computational equivalent of a private jet.
I'm not against paying for intelligence. I'm against paying for intelligence nobody's asked to use.
The meter isn't subtle
Look at Claude's listed standard model prices. Haiku 4.5 costs $1 per million input tokens and $5 per million output tokens. Fable 5.1 costs $10 and $50 respectively. Tokens are the units on the AI meter: there's a charge for what you send in and another for what comes back. That's a tenfold price gap before any special discounts or extras.[1]
Those are software-connection prices, not the monthly subscription for a person chatting in an app. If you're comparing a team's subscription with an automated system's running costs, you're comparing the club membership with the bar bill.
Here's a deliberately hypothetical illustration. A workload using a million input tokens and 200,000 output tokens would cost $2 on Haiku's base rates and $20 on Fable's. Same assumed volume, different engine. That calculation excludes discounts, tools and other charges; it doesn't assume the two models produce equally good answers.[1]
OpenAI's standard short-context prices show an even wider spread: GPT-6 Astra lists $10 per million input tokens and $50 per million output tokens, while GPT-6 Luna lists $0.10 and $0.50. “Short context” is the pricing category for smaller amounts of material supplied at once. The headline rates are a hundredfold apart.[2]
A price table doesn't prove the cheaper model can do your job. It does prove that automatically reaching for the expensive one deserves an explanation better than “it's the best”.
The best forklift is still an odd way to deliver an envelope.
Cheap answers can be expensive
This isn't an argument for choosing the lowest number and declaring victory. That's procurement theatre with a calculator.
Imagine a model sorting incoming enquiries into a few sensible categories. The test is whether it puts them in the right place, recognises when it's unsure and leaves awkward cases for a person. Beautiful prose adds nothing. Nobody needs a moving account of an invoice's childhood.
Now imagine a model comparing two suppliers' proposals, spotting conflicting assumptions and explaining what might go wrong. That's a different job. If the more expensive model catches something the cheaper one misses, the price gap may be perfectly sensible.
I haven't run a head-to-head test of those models for those tasks, so I'm not awarding a winner. My judgement is that the comparison belongs on the customer's actual work, not on the supplier's most flattering demonstration.
A fair test would use the same examples, the same instructions and a definition of acceptable set before anyone sees the answers. Count failures, retries and time spent checking. Include examples that don't fit neatly, because real work has an irritating habit of arriving without a presentation deck.
I'd call the useful number cost per acceptable result. A cheap answer that needs repairing isn't cheap just because the supplier's part of the bill is small. Equally, an expensive answer that's no more useful is just a cheap answer travelling business class.
Not everything needs to happen now
There's another distinction I'd make before debating intelligence: does the job need an immediate answer?
Claude's batch service lets software submit work together for processing without an immediate response, at a 50% discount on input and output token prices. Batches expire if they haven't finished within 24 hours.[3]
That could suit routine overnight classification or an internal document queue. It wouldn't suit a customer standing there waiting for an answer. The trade-off is waiting, not a magic improvement in quality.
Call me cynical, but urgency is a lovely thing to sell. Especially when nobody's checked whether the task is urgent.
I think the stronger AI businesses will be good at making these distinctions quietly: cheaper processing where it passes the test, more capable processing where it earns its keep, and people where the answer still needs judgement. That's less glamorous than having the fanciest model everywhere. It also gives the customer a reason to stay that isn't another launch announcement.
The suppliers can compete to sell the cleverest engine. The business using it should compete to waste the least intelligence.
Who's going to make money helping customers spend less on AI?
Sources
[1] https://platform.claude.com/docs/en/about-claude/pricing
[2] https://developers.openai.com/api/docs/pricing
[3] https://platform.claude.com/docs/en/build-with-claude/batch-processing