Watch someone build with a single AI model and you’ll see a familiar failure. They give it a big, vaguely-specified task. The model, eager to help, starts writing code immediately — picking an architecture on the fly, guessing at decisions that were never made. Two hundred lines in, it’s clear the whole approach is wrong. So they course-correct, re-explain, and the model rewrites. And rewrites again.

None of that thrashing was a coding problem. It was a planning problem — solved, expensively, with a coding tool. The model was never asked to think before it typed, so it didn’t.

We’ve covered which model to use and how hard to make it think. This one is about sequence: doing the thinking as a separate, cheaper, deliberate step before any code gets written.

The evergreen idea: thinking and typing are different jobs

Building software has two distinct modes, and they reward different things:

  • Planning is deciding what to build and how — the architecture, the data model, the sequence of steps, the trade-offs. It’s a small amount of output (a spec, a plan) carrying enormous leverage. Get it right and everything downstream goes smoothly. Get it wrong and everything downstream is rework.
  • Building is turning a settled plan into code — writing the functions, the tests, the wiring. It’s a large amount of output, but each piece is low-stakes because the hard decisions were already made.

These want different models. Planning wants your strongest reasoning model, thinking hard, for a short, high-value burst. Building wants a capable workhorse, running cheaply, across a lot of straightforward output. When you collapse both into one model — usually a mid-tier one, writing code from a vague prompt — you get the worst of both: no real plan, and a lot of cheap code heading in the wrong direction.

The counter-intuitive economics: a plan is a few hundred tokens of insurance against thousands of tokens of rework. Spending more on the think step is how you spend less overall.

Two paths: plan first with a reasoning model then build cheap, versus skip planning and pay for rework Plan first 1 · PLAN Fable / Sol / Opus few tokens, high leverage 2 · BUILD Sonnet / Terra / GLM many tokens, low unit cost ✓ low total cost, right first time Skip planning 1 · CODE MODEL jumps straight in, guesses the design 2 · THRASH wrong direction, rewrite, re-explain ✗ 2–3x cost in rework A plan is a few hundred high-value tokens. Skipping it makes your cheap code model expensive.

The current state (as of 19 July 2026)

The lineups make the split easy to staff. There’s now a clear “thinking tier” and a clear “building tier.”

As of 2026-07-19:

For the plan / architecture step (reasoning-heavy, short, high-value): - Claude Fable 5 ($10/$50) — Anthropic’s new Mythos-class flagship, explicitly aimed at frontier agentic and planning work. - GPT-5.6 Sol ($5/$30) or Claude Opus 4.8 ($5/$25) — premium reasoning for design and trade-offs.

For the build step (high volume, low stakes per piece): - Claude Sonnet 5 ($2/$10 intro) or GPT-5.6 Terra ($2.50/$15) — capable workhorses for ordinary code. - Challengers (GLM-5.2 $1.40/$4.40, DeepSeek V4 Flash $0.14/$0.28) — cheap muscle for bulk generation from a clear plan.

The plan step is a small number of expensive tokens; the build step is a large number of cheap ones. That asymmetry is exactly what you want.

Prices move, but the structure is stable: a strong reasoning model to decide, a cheaper workhorse to execute. Confirm current names and rates before you wire anything up.

What “plan first” looks like in practice

It doesn’t have to be heavy. For a small task, the plan might be three sentences: the approach, the files you’ll touch, the order. For a real feature, it’s a short spec — data model, interfaces, the sequence of steps, the tricky bits called out. You produce it with a reasoning model, you read it, and only then do you hand it to a cheaper model to build.

Two things make this cheap discipline pay off far beyond the token maths:

  • The plan catches wrong turns while they’re still free. Fixing “we should use a queue here, not a cron” in a one-paragraph plan costs nothing. Fixing it after 400 lines of committed code costs a rewrite.
  • The plan is a reusable artefact. Checked into the repo, it briefs the next session, the next model, and the next teammate. You paid to think once; everyone downstream inherits it for free. (This is the same “pay once, reuse” logic as caching — applied to decisions instead of tokens.)

The build model, handed a clear plan, stops guessing. It has fewer decisions to get wrong, so it thrashes less, so the cheap tokens stay cheap.

Where the challengers fit

Challengers are build-tier players, and the plan-first split is what makes them safe to use. A GLM or DeepSeek model handed a vague, under-specified task will wander — and cheap tokens spent wandering aren’t cheap. The same model handed a tight, reasoning-model-authored plan just executes it competently for a fraction of a flagship’s price. In other words: the better your plan, the cheaper the model you can safely build with. Planning discipline is what unlocks the challenger savings without the quality risk.

The playbook

  • Always produce a plan before code. Even three sentences. Make “what and how” an explicit step, not an assumption baked into the first prompt.
  • Use your strongest model for the plan, your cheapest capable one for the build. Fable/Sol/Opus to decide; Sonnet/Terra/GLM to execute.
  • Read the plan before you build. The whole value is catching a wrong turn here, where it’s free. Skimming defeats the point.
  • Check the plan into the repo. It’s reusable capital — it briefs the next session and the next model, and it’s the seed of consistent, agent-agnostic behaviour.
  • Match the plan’s depth to the stakes. A rename needs no plan; a new subsystem needs a real one. Don’t ceremony-ize trivial work.
  • Re-verify the tiers. Which model is “the planner” changes with each release; confirm before standardising.

The Khula Take

The whole industry is selling you a single model that “can do everything” — plan, code, test, review, all in one seamless chat. It’s a seductive pitch and, for controlling cost and quality, mostly wrong. We think the more useful stance is almost old-fashioned: separate deciding from doing, and treat the decision as the valuable part.

For a South African business, this is the difference between AI that feels magical and AI that compounds. A team that lets a code model improvise architecture ships fast and accumulates mess — every feature a fresh guess, nothing reusable. A team that produces a cheap, deliberate plan first accumulates assets: specs, decisions, and patterns that make the next build faster and the next model interchangeable. The plan is where institutional knowledge lives. Skipping it doesn’t just cost rework tokens — it costs you the compounding, which is the only thing that lets a small operation outgrow a bigger one. Applied AI that grows a business thinks before it types.

Where this is heading

Deciding, per task, whether to spend a planning pass — and on which model — is one more judgement call. The Token Economy harness will make the split automatically: route the framing and architecture to a reasoning model, hand the resulting plan to a workhorse, and keep the plan as a first-class artefact. The estimator prices both phases, because the “skip the plan and thrash” path is one of the most common ways a build blows its budget.

Until then, the discipline is free and immediate: don’t write architecture with your code model. Think first, cheaply and deliberately, then build. Confirm the current planning and building tiers against the vendors before you standardise — the names shift with every release.

Sources (July 2026): - Claude lineup (Fable 5 / Opus / Sonnet) — platform.claude.com/docs, tygartmedia - OpenAI GPT-5.6 tiers — OpenAI Help Center - Challenger build-tier pricing — docs.z.ai, api-docs.deepseek.com

Model tiers and prices change frequently. Confirm against the vendor pages before standardising a planning/building split.