By now you have the parts. You know to match the model to the task, to read your meter, to treat effort as a dial, to cache what repeats, and to plan before you build. That’s a lot of judgement to exercise, fresh, on every single task.

You shouldn’t have to. Good discipline that lives only in your head fails exactly when you’re tired, rushed, or deep in a problem — which is most of the time. The fix is to stop deciding and start following: write the rules down once, as a routing policy, and let the policy make the easy calls so your attention goes to the work.

This is the capstone. Let’s build you a budget you can actually run.

The evergreen idea: a policy beats a decision

A routing policy is a small, written table: for each kind of task, which model tier and which effort level you’ll use by default. That’s it. Its power isn’t sophistication — it’s that it removes hundreds of tiny, repeated decisions and replaces them with one you made carefully, in advance, when you were thinking clearly.

Defaults are destiny. If your default is “flagship, high effort,” you’ll drift there on autopilot and pay for it. If your default is “workhorse, medium effort, escalate deliberately,” you’ll spend most of your budget correctly without thinking about it — and reserve your judgement for the genuine exceptions.

A policy also makes escalation conscious. When you reach for the expensive model, it’s now a deliberate step up from a known default, not an unexamined habit. That single shift — from “always flagship” to “workhorse unless earned” — is most of the savings in this entire series.

A personal routing policy: task type mapped to model tier and effort level TASK MODEL TIER EFFORT Plan / architecture Fable · Sol · Opus High Hard / correctness code Opus · Sol High Ordinary code Sonnet · Terra Medium Mechanical churn Haiku · Luna · GLM Air Low / off QA / review Opus · Sol High Apply review fixes Sonnet · Haiku · DeepSeek Low Default to the cheaper row; escalate deliberately. Names as of 2026-07-19 — verify before adopting.

The starting policy (as of 19 July 2026)

Here’s a default policy you can adopt today and tune to your own work. The table above is the shape; the models are the current lineups. Verify names and rates before you commit — they move.

Default routing policy: - Plan / architecture → Fable 5, Sol, or Opus 4.8, high effort. Short, high-value. - Hard / correctness-critical code → Opus 4.8 or Sol, high effort. - Ordinary code → Sonnet 5 or Terra, medium effort. Your default day-to-day. - Mechanical churn → Haiku 4.5, Luna, or a challenger, low effort or thinking off. - QA / review → Opus 4.8 or Sol, high effort — check the cheaper model’s work. - Apply review fixes → Sonnet, Haiku, or DeepSeek, low effort.

Plus two standing rules: caching on, stable context first, and plan before you build.

On a subscription, the policy adapts to your meter

  • Claude Pro / Max (compute-hour meter): the policy above works, but add context discipline — the meter is throughput, so keep sessions tight and don’t drag a huge repo into small tasks. Your escalations to Opus/Fable are the expensive moves; make them count.
  • ChatGPT Plus / Pro (message meter): the same tiers apply, but effort is your sharpest lever here — high-reasoning messages draw down your allowance hardest, so the “medium by default” rule matters even more than the model choice.
  • API (token meter): the policy plus aggressive caching and batching is the whole game; model tier and caching together set your bill.

A worked week

Picture a solo dev on a mid subscription shipping a feature. Under the policy: they open with a planning pass on a reasoning model (a few expensive minutes, high leverage), get a short spec, and read it. They build the bulk on the workhorse at medium effort — endpoints, components, tests — cheaply. They drop to the light tier for the boilerplate and renames. When a genuinely hard bug appears, they escalate deliberately to the flagship at high effort, fix it, and drop back down. They run a review pass on a strong model, then apply the fixes on a cheap one.

Same feature a single-model builder would have run entirely on a flagship at high effort — paying the top rate on planning, boilerplate, fixes, and all. The policy-driven dev spent the premium only where it mattered, and the difference is not marginal; it’s the gap between finishing the month inside budget and hitting the wall on Thursday.

The cheap lane, when you need it

Some weeks the goal is simply spend as little as possible — a side project, a tight month, a big batch job. The policy has a lane for that: shift your defaults down a tier (workhorse becomes challenger, light tier becomes DeepSeek Flash), keep effort low, lean hard on caching and batch, and accept slightly more iteration. You trade a little speed and polish for a much smaller bill. Having that lane written down means you can switch into “cheap mode” deliberately instead of just hoping to spend less.

The playbook

  • Write your policy down. A six-row table in a note, a README, or your repo. Real, visible, followed.
  • Set the cheap option as default. Workhorse and medium effort unless the task earns more. Make expensive a choice.
  • Escalate consciously, drop back deliberately. After the hard bit, return to the default. Don’t let a session drift and stay on the flagship.
  • Keep the two standing rules on. Caching and plan-first are always-on, not per-task decisions.
  • Match the policy to your meter. Context discipline on Claude, effort discipline on OpenAI, caching on the API.
  • Review it monthly. New models, new prices, new caps — a policy is a living document, not a tablet of stone.

The Khula Take

Most people treat AI spend as weather — something that happens to them, unpredictable, to be absorbed and complained about. We think that’s a choice, and the wrong one. A budget isn’t a restriction you suffer; it’s a system you design. The moment you write a routing policy, your AI cost stops being a surprise on an invoice and becomes an operating decision you control — dialled up when a project justifies it, down when it doesn’t.

For a South African business, that shift is quietly transformational. Predictable, policy-driven spend is what lets you plan — to quote a client with confidence, to run a project to a number, to reinvest the savings instead of bracing for the bill. The competitor still running everything on the flagship by reflex is faster to feel clever and slower to make money. A written routing policy is small-business discipline applied to a new kind of cost, and discipline, compounded, is how the small operator wins. That’s Applied AI as management, not magic.

Where this is heading

A routing policy is the manual version of the tool we’re building. The Token Economy Build-Estimator takes a locked scope and reports the same decisions this policy encodes — but priced, in your plan’s units, three ways: quickly (fastest, priciest), optimally (best value), and cheaply (lowest spend). And the background harness will apply the policy for you, routing each task without you touching the dial. This article is that system, done by hand — which is exactly where you should start, because the judgement is the point and the tool just automates a judgement you already trust.

Write the policy today. Confirm the current models and caps against your own plan before you adopt it — in this market, last month’s optimal default is this month’s overspend.

Sources (July 2026): - Claude & OpenAI current lineups/pricing — platform.claude.com/docs, OpenAI Help Center - Plan caps (community/aggregator) — IntuitionLabs - Challenger pricing — docs.z.ai, api-docs.deepseek.com

Model names, prices, and subscription caps change frequently. Confirm against your own plan and the vendor pages before adopting a policy.