Stop Paying Frontier Prices for Executor Work

Most teams adopting AI coding agents make the same expensive mistake: they treat model selection as one decision. Pick the smartest model, throw everything at it, watch the token bill climb.

That's not architecture. That's hiring a team of principal engineers and having the most expensive one format the changelog.

After enough trial and error with agentic workflows, I've landed on a structure that anyone who's run a real software team will recognize instantly. It's an org chart — the headcount just happens to be model tiers.

Token price is not the real cost

Pricing debates usually stop at the rate card. Model A is cheaper per million tokens, therefore Model A is cheaper. Wrong equation.

Real cost = unit price × tokens you actually burn before the job is done.

A cheaper model that over-engineers, drifts from instructions, or keeps forcing rework can end up costing more than a pricier one that gets it right the first time. Tokens spent on output you throw away are a cost the rate card never shows you.

And the most expensive thing in the system isn't tokens anyway. It's your time — spent reviewing work that went sideways.

Once you see it that way, the question stops being "which model is best" and becomes "which model belongs in which seat."

The three tiers

Three-tier AI orchestration diagram: human approver, frontier analyst, executor models

Pay for judgment where it matters, executor rates everywhere else — and nothing ships downstream until the thesis is committed.

Tier 1 — Human: the Approver. I don't write the code, and lately I don't even draft the plan. My job is to set constraints, weigh trade-offs, and approve. The reasoning is simple: human attention is the scarcest, priciest resource in the whole system. Spend it on decisions, never on execution.

Tier 2 — Frontier model: the Analyst. This one isn't a typist — it's a sparring partner. Its job is to argue with me: surface the trade-offs I missed, decompose the work, propose a plan. We go back and forth until the plan is solid, then we commit the thesis. That commit is a hard gate. No execution on an uncommitted plan, ever.

It's the architect-and-tech-lead dynamic. The value was never in how fast the tech lead types — it's in the quality of the argument before anyone types anything.

Tier 3 — Cheap models: the Executors. Once the thesis is locked, work fans out to cost-efficient subagents. Most execution work — CRUD, pattern-following refactors, implementing against a sealed spec — is bounded. Past a certain capability threshold, extra intelligence doesn't improve the output. It just improves the invoice.

Bonus: a highly obedient executor is exactly what you want here. The trait that drives everyone crazy in a top-level agent — doing precisely what was asked and nothing more — becomes a feature once the thinking has already happened upstream.

The trap nobody prices in: silent compliance

Every "cheap executor" strategy has one hole. A model below a certain capability level doesn't just fail to push back on a flawed spec — it executes the flaw cleanly and confidently. Your bug doesn't show up at generation time, where it's cheap to fix. It shows up at integration time, where it's expensive — and it lands right back on the approver's desk.

So you can't pick the executor tier on price alone. Every model in it has to be good enough to raise its hand inside domains it knows.

The test: plant a flaw, see who speaks up

Before any model joins my executor pool, it goes through a check that standard benchmarks skip entirely: does it raise its hand?

Planted-flaw capability gate diagram: testing whether an executor model flags a flawed spec

Hand it a spec with one deliberate flaw in its known domain. A model that executes a flawed spec flawlessly is more dangerous than one that fails loudly.

The test is dead simple. Take a realistic spec from the model's home turf. Plant one deliberate flaw — a contract mismatch, a missing edge case, two constraints that contradict each other. Hand it over like real work.

Flags it → qualified. It has enough domain grounding to be a safety net, not just a code printer. Complies silently → rejected. Whatever it costs per token, the integration risk makes it too expensive.

We do this with people instinctively. Before delegating anything important to a new colleague, you probe their understanding first. A model about to write production-bound code deserves no lower a bar.

What happens to the token bill

Frontier tokens only get burned during the highest-leverage phase — the trade-off argument and decomposition — a tiny slice of total volume. The bulk burns at executor rates. Rework drops, because every spec gets challenged twice before execution: once by the frontier analyst, once by an executor that's already proven it can flag flaws in its own domain.

The metric I actually track isn't tokens per task. It's rework rate — the percentage of executor output that comes back for fixes. That's the real SLA of a subagent. A low unit price with a high rework rate is a discount you pay for twice.

The part that isn't about AI

None of this is really about AI. It's the same discipline solution architecture has always demanded: match the resource to the responsibility, gate execution behind committed decisions, measure outcomes instead of inputs. The models will keep changing. The org chart won't.