Why One Model for Everything Is the Most Expensive Habit in AI Coding

You picked a good model. Probably the best one — the flagship, the one that tops the benchmarks. You pointed it at everything: planning, boilerplate, the hard algorithm, renaming variables, writing the commit message. It works. The code is good.

And then the usage limit hits on a Tuesday afternoon, or the API bill lands and it’s four times what you budgeted, and you can’t quite explain where it went.

Here is where it went: you paid flagship prices to rename variables.

This is the most expensive habit in AI-assisted building, and almost everyone has it. Not because it’s stupid — because it’s convenient. One model, one chat, one mental model. The problem is that “one model for everything” treats every task as if it were equally hard, and charges you as if it were equally hard, when the truth is that most of what a coding session actually consists of is cheap work wearing an expensive coat.

The evergreen idea: work has a difficulty shape, and so should your spending

Strip away the model names and prices — which change monthly — and one thing stays true: a software task is not one thing. It’s a sequence of sub-tasks with wildly different difficulty. A single feature might contain:

• Genuinely hard reasoning — the architecture, the tricky concurrency, the algorithm that has to be correct, the security-sensitive path. Getting this wrong is expensive downstream. You want the best brain you can afford here.
• Ordinary construction — CRUD endpoints, wiring, the fourth similar React component, a migration that looks like the last five. A competent mid-tier model does this cleanly.
• Mechanical churn — renames, formatting, moving a function, writing a docstring, updating an import. Almost any model does this correctly, and thinking harder about it buys you nothing.
• Review and verification — checking the cheap model’s work, hunting for the subtle bug. This wants a strong, sceptical reader — but only after the cheap work is done.

The single-model habit ignores this shape entirely. It runs the whole sequence — hard, ordinary, mechanical, review — through the same expensive engine at the same high effort. You’re not paying for capability; you’re paying for capability you didn’t need on that turn.

The fix is a mindset, not a tool: match the model and the effort level to the difficulty of the task in front of you. Route the hard 20% to the strong model, and everything else to something cheaper. This is the whole thesis of this series, and everything else — metering, caching, effort dials, the challenger models — is detail underneath it.

The current state (as of 19 July 2026)

Numbers move fast in this market — the lineups below only settled in the last fortnight — so treat this block as a dated snapshot. The framework above is what lasts. All figures are API price per 1 million tokens, input / output, confirmed against vendor and aggregator pricing pages in July 2026 (sources at the foot).

As of 2026-07-19:

Anthropic — handover lineup Fable → Opus → Sonnet → Haiku: - Claude Fable 5 — $10.00 / $50.00. New Mythos-class flagship; built for planning, architecture and frontier agentic work. - Claude Opus 4.8 — $5.00 / $25.00. Premium reasoning; the heavy-code workhorse. - Claude Sonnet 5 — $2.00 / $10.00 (introductory, rising to $3.00 / $15.00 after 31 Aug 2026). - Claude Haiku 4.5 — $1.00 / $5.00. Light tier for mechanical churn.

OpenAI — GPT-5.6 handover Sol → Terra → Luna (GA 9 Jul 2026): - Sol — $5.00 / $30.00. Premium frontier. - Terra — $2.50 / $15.00. Balanced default. - Luna — $1.00 / $6.00. Cost-efficient worker.

The challengers (cheap, capable, not yet app-wide): - GLM-5.2 (Zhipu) — $1.40 / $4.40. - Kimi K3 (Moonshot) — ~$3.00 / $15.00. - DeepSeek V4 Flash — $0.14 / $0.28.

Two levers cut all of these further: prompt caching (cached input roughly −90% on the majors) and the batch API (−50%). More on those in later articles.

Look at the spread. Fable’s output ($50) is 5× Sonnet 5’s intro rate, and the flagships — Fable, Sol, Opus — run 90× to 180× the price of DeepSeek V4 Flash. If you run a full build session — where realistically 60–70% of the tokens are ordinary or mechanical — entirely through a flagship, you are paying that multiplier on the majority of your work. That’s the leak.

What routing looks like in practice

Here’s one worked example — deliberately one example, not the one true way. Say you’re building a feature end to end:

1. Plan and architecture → a strong reasoning model. This is where Anthropic’s new Fable 5 (or GPT-5.6 Sol) earns its price: a small number of tokens with enormous leverage. Spend here without flinching.
2. The hard, correctness-critical code → a flagship at high effort — Opus 4.8 or Sol. The concurrency, the money math, the auth path.
3. The ordinary construction → drop to a workhorse: Sonnet 5 or GPT-5.6 Terra. The endpoints, the components, the wiring. Cheaper and completely capable.
4. QA and review → raise back to a strong model to check the workhorse’s output. A sceptical senior reader catches what the cheaper model missed. This is the counter-intuitive move: cheap to write, expensive to check.
5. Executing the review’s fixes → drop again — Haiku 4.5, Luna, or a challenger. Applying a clear list of corrections is mechanical.

The pattern isn’t “cheap = good.” It’s spend on judgement, save on typing. The expensive turns are the ones where being wrong is costly — design decisions and verification. The cheap turns are the ones where the answer is basically determined and you’re just producing it.

If you only ever remember one rule from this whole series, make it that.

Where the challengers actually fit

The Chinese open-weight and low-cost models — GLM, Kimi, DeepSeek, Qwen — have become genuinely good, and their prices are not a rounding error against the majors: GLM-5.2’s output is over 5× cheaper than Opus 4.8, and DeepSeek V4 Flash is cheaper than almost anything with a pulse. Even Kimi’s newest flagship, K3, sits well under the Western frontier on input.

But cheaper-per-token is not the same as ready-to-own-your-build. As of mid-2026 the honest picture is: these models are excellent worker turns — bulk generation, transformation, cost-sensitive batch jobs, first drafts you’re going to review anyway — and they’re a legitimate way to run the “Cheaply” lane of a project. Where they still lag the majors is the connective tissue: tool-use reliability inside agent harnesses, IDE integration, and the ecosystem maturity that lets a model drive a long, multi-step build without supervision. That’s a directional judgement from practitioner reports, not a benchmark — so test on your own workload before betting a project on it. Used as cheap muscle behind a capable orchestrator, though, they can quietly cut a bill in half.

The playbook

You don’t need tooling to start. You need to stop defaulting to the flagship. A checklist you can adopt today:

• Set a default workhorse, not a default flagship. Reach for Sonnet 5 (or GPT-5.6 Terra) first. Escalate to Opus, Sol, or Fable deliberately, when the task earns it — not by habit.
• Name your hard 20% before you start. At the top of a task, decide which parts genuinely need the strong model. Route the rest down.
• Write cheap, review expensive. Generate with a workhorse; verify with a flagship. Never the other way around.
• Push mechanical churn to the light tier or a challenger. Renames, formatting, docstrings, boilerplate migrations — Haiku, Luna, GLM Air, or DeepSeek Flash will do it correctly for cents.
• Turn the effort dial down when the answer is determined. High reasoning effort on a rename is pure waste (its own article, next in this series).
• Re-check prices monthly. This market reprices constantly — two whole flagship lineups (Fable, and GPT-5.6 Sol/Terra/Luna) landed in the weeks before this was written. What’s optimal in July may not be in September; the Sonnet 5 intro-pricing cliff (31 Aug 2026) is a live example.

None of this makes your code worse. Done right, it often makes it better, because you’re spending your best model’s attention on the decisions that matter instead of diluting it across busywork.

Where this is heading

Everything above is manual — you, deciding turn by turn. It works, and it’s where everyone should start, because the judgement is the point. But doing it by hand every session is exactly the kind of repetitive discipline that begs to be automated. That’s the direction this series is building toward: a background harness that watches the task in front of you and routes it — the right model, the right effort, the right lane — without you thinking about it, and an estimator that tells you up front whether a build should be done quickly, optimally, or cheaply.

We’ll get there. For now, start with the habit, not the tool: stop paying flagship prices for cheap work. Verify the current numbers before you act on them — in this market, “as of July 2026” has a short shelf life.

Sources (July 2026): - Anthropic pricing (Fable 5, Opus, Sonnet, Haiku) — platform.claude.com/docs, BenchLM - OpenAI GPT-5.6 Sol/Terra/Luna — OpenAI Help Center, finout - GLM / Z.ai — docs.z.ai pricing - Kimi K3 — OpenRouter - DeepSeek — api-docs.deepseek.com pricing

Prices are point-in-time and change frequently. Confirm against the vendor pages before making budget decisions. Refreshed 2026-07-19 to the GPT-5.6 (Sol/Terra/Luna) and Claude Fable 5 lineups.