We Don't Always Use the Best Models
Small, cheap AI models are now the workhorses under real automation. Why we default to fast and cheap, when we reach for the flagship, and what it does to your token bill.
Clients ask us this constantly: which model are you using?
They're usually expecting us to name the biggest, newest, most expensive one on the market. It feels like the right answer. If you're paying for AI automation, surely you want the smartest thing available driving it.
Most of the time, we're not using it. And that's not a cost-cutting compromise we're apologising for — it's a deliberate architecture decision that makes the systems we build faster, cheaper, and more reliable in production.
Here's the reasoning.
The interesting story in AI isn't at the top of the leaderboard
Everyone watches the frontier. New flagship model, new benchmark record, new headline. Fair enough — that's where the research is.
But the number that actually changes how businesses operate is happening at the other end of the range. According to Stanford HAI's AI Index, the inference cost of running a system at GPT-3.5-level performance fell from $20 per million tokens in November 2022 to $0.07 by October 2024 — a 280-fold drop in under two years. The report attributes that collapse directly to increasingly capable small models.
Read that again. The capability that cost twenty dollars now costs seven cents.
And the gap keeps narrowing. The same research found the performance difference between open-weight and closed frontier models compressed from 8% to 1.7% in a single year, while the spread between the top-ranked model and the tenth-ranked fell from 11.9% to 5.4%.
Translated into operator language: the cheap models got good enough to run your business on. That, not the next flagship release, is the development we get excited about.
Reason one: they're much faster
Cost gets all the attention. Speed is what your users actually feel.
Independent latency testing in 2026 puts the small-model tier — the Claude Haiku family, Google's Gemini Flash line — at consistently under 600ms time-to-first-token on medium prompts, with Gemini Flash-Lite measured as low as 0.35 seconds. On throughput, Gemini 2.5 Flash streams around 204 tokens per second against roughly 80–100 for heavier alternatives.
Now put that inside a real workflow rather than a benchmark. An automation that classifies an incoming WhatsApp message, pulls the client record, drafts a reply, and updates the task ledger isn't one model call. It's five or six, chained. A two-second penalty per call is a twelve-second delay before anything visible happens.
At that point the automation stops feeling like automation. It feels like waiting.
The models we reach for first are the ones where the whole chain finishes before the user has stopped looking at the screen.
body-1-cost-collapse
Reason two: the economics are not close
Look at the published rate cards and the spread is stark. Across the Claude range, the fast tier runs about $1 per million input tokens against roughly $2–3 for the flagship tier and $10 for the top-end reasoning models — before you count output tokens, which are priced several times higher again. Google's Gemini 3.6 Flash sits at $1.50 / $7.50 per million input/output, with the preview Flash tier far below that.
A five-to-ten-times price difference sounds survivable until you understand how modern automation consumes tokens.
A chatbot exchange might use 2,000–4,000 tokens. A single agentic task — one that plans, calls tools, checks its own work, and loops — can burn tens of thousands to hundreds of thousands. That's not an edge case. That is the useful kind of automation, the kind that closes a loop without a human in it.
Multiply a hundred-times token volume by a ten-times token price and the flagship-for-everything approach doesn't produce a slightly higher bill. It produces a bill that kills the project at the finance review.
The economics of tiered routing bear this out. Organisations running a tiered model architecture consistently report blended costs well below frontier-only deployments — with combined caching and routing typically cutting 70–85% off an unoptimised baseline.
Same outcomes. A fraction of the cost.
body-2-model-tiers
Reason three: with decent reasoning, cheap and fast wins by default
This is the part that changed our thinking, and it's the reason we watch small-model releases more closely than flagship ones.
Once a smaller model can hold a chain of reasoning together — follow a multi-step instruction, use a tool correctly, know when it doesn't have enough information — the case for defaulting to anything larger largely evaporates for day-to-day work.
Because most day-to-day work isn't hard. It's constant.
Classify this email. Extract the line items from this invoice. Decide whether this message needs a human. Summarise yesterday's group thread. Check whether this client has an open task. Draft a status update from these five data points.
None of that requires a model that can reason its way through a novel research problem. All of it needs to happen hundreds of times a day, quickly, at a cost per run low enough that nobody bothers metering it.
The small models are the workhorses. They sit underneath the automation, running constantly, invisibly. That's where the operational value in AI actually accrues — not in one impressive answer, but in ten thousand competent ones nobody had to wait for.
body-3-decision-matrix
So when do we use the expensive models?
We do. Deliberately, and in specific places:
Development and engineering work. Writing and reviewing the code that runs the automation. Get this wrong and every downstream run inherits the mistake — this is exactly where you want maximum capability.
Genuinely deep reasoning. Architectural decisions, gnarly debugging, analysis where the reasoning chain is long and the cost of a subtle error is high.
Long multi-step processes with no human checkpoint. When a task runs autonomously across many steps, small errors compound. A stronger model earns its price by not drifting.
The judgment layer above the workhorses. Cheap models do the volume; a stronger model adjudicates the ambiguous remainder.
The pattern is simple: capability where errors compound, efficiency everywhere else.
What we don't do is pay flagship rates to decide whether an email is an invoice.
The practical version
If you're building or buying AI automation, three questions are worth putting to whoever is designing it:
Which model runs the high-volume path? If the answer is "the newest one, for everything," that's not a technical decision — it's the absence of one.
What's the cost per run, and what happens at 100x volume? Pilots hide this. Production doesn't.
Where does a mistake compound? Those are the only places that justify premium capability.
The UAE is a good market to be asking these questions in. Microsoft's AI Diffusion research puts the country top of the world for AI adoption, with over 70% of the working-age population using AI regularly against a global average near 18%. Adoption here isn't the constraint. Building systems that stay economical once they're actually being used — that's the constraint.
Our take
The most useful thing that happened to AI automation over the past two years wasn't a smarter frontier. It was the bottom of the market becoming good enough that entire categories of work became cheap to automate.
At Optomize.ai, we design for that. Every automation we build gets a model chosen for the job it's doing — cheap and fast for the ninety percent that's routine, heavyweight for the ten percent that genuinely needs it. Clients don't buy a model. They buy an outcome that still makes commercial sense at volume.
If you're running AI in production and haven't looked at what's actually driving your token bill, that's usually the fastest win available — and it rarely requires rebuilding anything.
Want to know what your automation should actually be running on? Book a discovery call and we'll map it with you.
