The Architect Doesn't Lay Bricks: Splitting AI Coding Between Expensive and Cheap Models
We banned our most expensive AI model from writing code. Token receipts from 606 real sessions show how the architect–implementer split cuts AI coding costs.
A few days ago Anthropic made Fable a permanent part of Max plans. The timing tells the story: it landed right after OpenAI shipped GPT-5.6 Sol, and — more to the point — right after Kimi K3 dropped its weights. It took an open-source model to force the biggest AI lab into a reality check and end the marketing fuss around its flagship. That alone deserves a toast from anyone who pays these invoices.
But “included in your subscription” is not the same as “cheap,” and it is definitely not the same as “cheap forever.” Which is why, while Fable was still metered, we rebuilt our workflow so that the expensive model is mechanically blocked from writing code. It thinks, plans, and reviews. Cheaper models type. This post shows how that works, and what it actually measured out to across every transcript we have — 606 real sessions spanning a production SaaS monorepo, a drone-operations app, a marketing site, and the CI agents that serve them.
Part 1 — The trap, and the principle
Here’s our honest starting position: we can no longer operate without frontier models. Nobody on the team could sustain current output without them — and that dependency is exactly the leverage the big labs hold. In our reading, today’s AI subscriptions deliver markedly more compute than they cost; they are land-grab prices, and land-grab prices end. When they do, whoever built their engineering culture around “unlimited frontier tokens” pays whatever is asked.
There are two defenses. The first is keeping a credible exit: open models like DeepSeek and Kimi are what forced this week’s price correction, and they only stay leverage if we actually keep our workflows portable to them. The second is workflow discipline: spend frontier tokens only where nothing cheaper works. This post is about the second — because it’s the one you can start on Monday.
The principle is old enough to have a building named after it: the architect doesn’t lay bricks. A frontier model’s edge over a mid-tier model is enormous in design, decomposition, and review — and close to zero when typing out a rename across forty files. So split the roles. The price ladder says the same thing in dollars:
How the fable-architect pattern works
The fable-architect skill is a ~100-line markdown file plus one shell hook, loaded whenever a Claude Code session runs on the frontier model. It enforces a division of labor:
The architect does: interrogate the requirement, explore the codebase, make every design decision — approach, data flow, names, signatures, edge cases — decompose the work into independent slices, review the returned diffs, run verification, and write all prose (plans, briefs, PR bodies, commit messages).
The architect never does: write or edit a source file. No code in chat beyond short signatures inside a brief.
Three things make this work in practice rather than on a slide.
1. The brief is the interface
Each slice gets one implementation brief. The implementer starts with a fresh context window — anything not in the brief, it must rediscover or guess. That constraint is a feature: it forces the architect to finish deciding before delegating. A brief contains decisions, not options.
## Implementation brief: <slice>
Goal: one sentence, observable outcome
Context: what exploration already found — excerpts, the nearest
pattern to mirror, line anchors, gotchas
Files: paths to create/modify — this slice's exclusive ownership
Design: the decided approach — data flow, names, signatures, edges
Constraints: project rules that apply: style, layers, security
Out of scope: what not to touch, including files owned by other slices
Delegation: may this slice spawn sub-implementers, and how many
Verify: exact commands and expected outcome
Two of those lines are newer than the rest, and they exist because the implementer tier changed under us — see the update below.
2. Enforcement, not vibes
A PreToolUse guard hook watches the session: if the architect tries to edit a non-prose file, a permission prompt fires. Approving the prompt is the documented exception for trivial edits (a typo, a version bump — cases where delegation overhead costs more than typing). Friction is the policy. Without the hook, “the expensive model shouldn’t code” lasts exactly until the first deadline.
3. The review loop closes the quality gap
The architect reads the agent’s report and the actual diff — trusting neither alone — and re-runs the key verification commands when the claim matters. Found a problem? The correction goes back to the same agent, which still holds its full working context. No hand-fixing, no fresh respawn.
Note that this is the architect’s verification, and it stays. What we’ve started removing is the verification we used to write into briefs — instructions telling the implementer to double-check itself. Newer implementer models do that unasked, and telling them to do it again buys a second pass you already paid for.
Ready to grow your business?
Start your free trial today and see results within days.
To check whether this is a real economic mechanism or just a pleasing ritual, we mined every Claude Code transcript across our projects, deduplicating API requests and pricing every token at current list rates. Three hypotheses, registered before looking at the per-session numbers:
H1 — The implementers do the typing. If true, implementer subagents should produce more output tokens than the architect’s main loop in delegated sessions.
H2 — Delegation is cheaper. If true, repricing the implementers’ work at the architect model’s rates should come out meaningfully more expensive than what we actually paid.
H3 — Quality holds. The hard one: delegated code should not need more rework than architect-typed code.
Ground rules. One API request spans many transcript lines that repeat the same usage object — we grouped by request ID, counted input and cache tokens once per request, and took the max output snapshot (naive per-line summation overcounts 2–3×). Costs use current Anthropic list prices — Fable $10/$50, Opus $5/$25, Sonnet $3/$15 per million input/output tokens — with cache reads at 10% of input price and cache writes at their per-TTL rates. 31 of 354 interactive-store sessions qualify as fable-architect sessions under a conservative classifier; figures show the eight most expensive. We report ratios and percentages rather than our absolute spend.
Part 2 — The receipts
H1 — Mixed… said the first accounting. In the biggest delegation sessions the hypothesis holds decisively — up to 2.3× more implementer output than architect output. But across all 31 fable-architect sessions the architect still out-produced the implementers, 3.59M to 3.15M tokens. Partly that’s fair — the architect’s output includes all the plans, briefs, and review prose, which is exactly its job — and partly it looked like sessions delegating one slice and keeping the rest. Then we remembered that our site redesign hadn’t felt architect-heavy at all, and went looking for the tokens the subagent accounting couldn’t see.
Join our newsletter
Get latest tips, trends, and deals for free.
The second channel: the issue tracker as a delegation bus
Subagent accounting has a blind spot: it only sees delegation that happens inside a session. The site-redesign session — the biggest line in the chart above — turned out to be something else entirely: a single architect loop session that ran for 107 hours straight (292 scheduled wakeups), broke the redesign into GitHub issues, tagged them for our CI pipeline, and then supervised: polling runs, reviewing the pipeline’s pull requests, filing follow-up issues as QA surfaced bugs.
The typing happened somewhere our per-session mining hadn’t even looked: a separate fleet of self-hosted runners, where the pipeline’s plan → implement → gap-evaluation → review stages executed as 252 independent Opus sessions over 4.5 days, touching 48 distinct issues and PRs.
H1, revisited — Confirmed at project scale. Count both channels and the picture inverts: the pipeline typed 10× more output tokens than the architect loop that dispatched it (9.07M vs 877k), all at Opus rates. Running that implementation wave on the architect’s model would have cost 2.1× as much — on one redesign, in one week, before counting the in-session subagents. An issue is just a coarser-grained brief: same interface, same economics, one level up.
H2 — Confirmed, with a twist. Repricing the implementers’ exact token volumes at the architect model’s rates makes every session more expensive — from +2% to +54%, 17% across the top eight. Real money, but smaller than the 2× output-price gap suggests. The twist: output isn’t where the money goes. In the largest session, the architect’s cache reads cost about 13× as much as everything it typed — the dominant spend is the expensive model holding and re-reading a large orchestration context, not typing. Delegation caps the output bill; the next lever is keeping the architect’s context lean.
H3 — Not measured here. Token accounting can’t see code quality. What we can say observationally: the review loop is load-bearing — reports and diffs disagree often enough that reading both is non-negotiable — and corrections routed back to a context-warm agent converge fast. If you replicate this and measure rework properly, we want to see it, especially if it refutes us.
What the wider data taught us
Adoption is a gradient, not a switch. On the drone-ops app — smaller, faster-moving — 18% of sessions run the fable-architect pattern; on the older SaaS monorepo it’s 9%. The project that delegated hardest did it at both grains at once: in-session implementer briefs and 252 pipeline sessions dispatched through the issue tracker.
The CI fleet doesn’t run the skill — because it is the implementer. Our automated runner sessions never spawn an implementer subagent, and at first that read as non-adoption. The prompts say otherwise: every one is a pipeline stage — verify, review, gap-evaluation — and roughly six in ten work against a specific issue or PR. At project scale, the pipeline runners are the implementer tier.
The cheapest tier hasn’t had its first day at work yet. All 78+ implementer runs were Opus-class; the Sonnet mechanical-edit tier was only added recently and hasn’t been invoked. Whatever savings this measures, they’re a floor.
The interface is the point: brief in, diff out — issue in, PR out. The day the price hike lands, you swap the bricklayer, not the process.
Full disclosure. Models verified from transcript strings, not assumed. We corrected ourselves twice (a per-line token overcount, then a placeholder price table). The counterfactual assumes the architect would have spent the same token volumes the implementers did — error bars run both directions. The pipeline sessions live in a transcript store our first two mining passes didn’t scope; an accounting boundary hid a 9M-token delegation channel from us, and yours probably has one too. One engineer’s projects, mostly review-and-fix and feature work — not a controlled benchmark. The corpus also closes before Opus 5 shipped: every figure above is Fable-as-architect over Opus-4-class implementers. The rung prices didn’t move when Opus 5 landed, so the measured ratios stand — but see the next section for what did move.
Update — the ladder moved under us
Opus 5 shipped after these measurements closed, and nothing in the price ladder changed: Opus is still $5/$25 per million input/output tokens, Fable is still $10/$50, and the chart above is still correct. What changed is the capability at each rung. Anthropic positions Opus 5 as a step-change on deep reasoning and long-horizon agentic work — which is to say, on exactly the work the architect role is made of, at half the architect tier’s price.
That points straight at our own H2 twist. If the dominant architect cost is cache reads, and cache reads bill at 10% of input price, then an architect running on Opus 5 re-reads its orchestration context at $0.50 per million tokens instead of Fable’s $1.00. The line item that cost 13× everything the architect typed gets cut in half. We have not measured this — it is arithmetic under the same equal-token-volume assumption we flagged for the 2.1× counterfactual, and it is the next thing we intend to test. If it holds, the interesting question stops being which model types and becomes whether the architect needs the top rung at all.
Three things about the new implementer tier change the pattern itself, not just its price:
It reaches for subagents readily — the reverse of its predecessor, which had to be talked into delegating at all. An implementer that quietly spawns its own implementers multiplies the bill with nobody watching. Hence the Delegation: line in the brief: a slice now states whether it may fan out, and how wide.
It verifies its own work unprompted. Verification instructions written for older models now buy a redundant second pass, so they come out of the briefs. The architect’s review loop is untouched.
It expands scope.Out of scope: stops being boilerplate and becomes the line that keeps a slice a slice.
And the rung we never used got sharper while we weren’t looking: Sonnet 5 arrives near Opus quality on coding work at $3/$15, with introductory pricing below that through the end of August. “Whatever savings this measures, they’re a floor” was a hedge when we wrote it. It reads like an understatement now.
Part 3 — Where this is deliberately going
We are steering, on purpose, toward a split that we think every engineering team will eventually be forced into: expensive frontier models for brainstorming, architecture, and review only; increasingly cheap models for the programming itself. Today our implementers are Opus-class. Nothing in the workflow changes when they become Sonnet-class, DeepSeek-class, or Kimi-class — the interface is model-agnostic by construction. That is the entire strategic value: the day the subsidy ends and the invoice doubles, teams with this discipline change one config line. Teams without it renegotiate their whole cost structure under duress.
Fable-architect is a baby step — adoption is partial and the cheapest tier hasn’t seen its first run. But it’s the step that builds the muscle: writing briefs that fully specify a slice, reviewing diffs you didn’t type, treating the expensive model’s attention as a budget. And the redesign wave shows where the muscle leads: once briefs work, issues work, and the expensive model stops attending the implementation at all.
What you can do on Monday
Split the roles in your agent harness. One session-level rule: the frontier model plans and reviews; delegate all file edits to a cheaper implementer agent. In Claude Code this is a skill plus subagent definitions — an afternoon of setup.
Make the boundary mechanical. Add a pre-edit hook that challenges the expensive model’s own file writes. A rule that costs nothing to break will be broken by Friday.
Write briefs with a fixed template. Goal, context, files, design, constraints, out-of-scope, delegation budget, verify. The template is the discipline — and the delegation budget is what stops an implementer from silently hiring its own.
Review both the report and the diff. Never trust either alone; re-run the verification commands that matter.
Measure your own split. Your transcripts already contain the data — group by request, price by model, and see who’s actually typing. Ours showed us an unused cheap tier and a 9M-token delegation channel we didn’t know about.
Widen the interface from briefs to issues. A brief delegates an hour of work; an issue delegates a day of it. Once your issues carry acceptance criteria a pipeline can act on, the expensive model can file work into the tracker and supervise instead of sitting in the loop for every slice.
Keep an exit warm. Run a cheap or open model as an implementer for one low-risk slice a week. Portability you never exercise is portability you don’t have.
Re-price the architect, not just the bricklayer. Every model release moves the rungs without moving the ladder. If most of your architect spend is context rather than typing, a cheaper architect tier is worth more than a cheaper implementer tier — check which one your own transcripts say you’re buying.
The labs will keep telling us their top models are worth any price, and — infuriatingly — for judgment work they’re mostly right. The move isn’t to abstain. It’s to stop paying frontier prices for for-loops.
Frequently asked questions
It's a division of labor between AI models: an expensive frontier model acts as the architect — exploring the codebase, making design decisions, decomposing work into slices, and reviewing results — while cheaper models act as implementers that write the actual code from detailed briefs. The expensive model is mechanically blocked from editing source files, so its tokens buy judgment rather than typing.
In our measurements, repricing the implementers' work at the architect model's rates made sessions 2–54% more expensive, and one week-long implementation wave would have cost over twice as much on the frontier model. The gap is bounded by output share: most of an architect session's cost is context (cache reads), not typing, so delegation caps the output bill while context hygiene remains the bigger lever.
Token accounting can't measure quality directly, but the pattern includes a review loop designed to protect it: the architect reads both the implementer's report and the actual diff, re-runs verification commands, and routes corrections back to the same agent, which retains its full working context. Fully specified briefs — decisions, not options — are the other quality safeguard.
A short structured document the architect writes for each work slice: goal, context from exploration, exact file ownership, the decided design, project constraints, what's out of scope, and verification commands. Because the implementer starts with a fresh context window, anything not in the brief must be rediscovered or guessed — which forces the architect to finish deciding before delegating.
Yes — that's much of its strategic value. The interface is model-agnostic: a brief goes in, a diff comes out. Swapping the implementer tier from a commercial mid-tier model to an open-weights model is a configuration change, not a workflow change, which keeps your engineering process portable if frontier model prices rise.
It sharpens it. When a new tier lands at half the top tier's price with strong long-horizon reasoning, the question shifts from which model types to whether the architect needs the top rung at all — because the dominant architect cost is cache reads on input, and cache reads bill at 10% of input price. Halving the architect's input rate halves the largest line item in the session. Two practical adjustments come with newer implementer models: give each brief an explicit delegation budget, since they spawn subagents readily, and remove self-verification instructions they now follow unprompted.
With a pre-edit guard hook in the agent harness: whenever the architect model tries to write or edit a non-prose file, a permission prompt fires. Approving the prompt is the documented exception for trivial edits where delegation overhead would cost more than typing. Making the boundary mechanical rather than aspirational is what keeps it alive under deadline pressure.
Štefan is an AI and software engineer building FlowHunt. Beyond the product itself, he designs agentic software-engineering workflows for developers that cut development costs while raising code quality.
Štefan Moravík
AI & Software Engineer
Orchestrate Multi-Model AI Teams with FlowHunt
Build AI agent workflows that route each task to the right model — frontier reasoning where it matters, efficient models for the volume work.
Why OpenAI Can't Justify Its $500B Valuation—and How Anthropic Is Winning the Only AI Market That Matters
OpenAI's $500B valuation faces scrutiny as commoditized AI models and open-source alternatives level the playing field. Discover why Anthropic's enterprise-firs...
What a Context Engine Actually Buys You: We Ran 22 AI Code Reviewers Five Different Ways
Same pull request, same prompt, same model — only the context loading differed. A context-engine digest plus one policy-file read beat reading the docs on both ...