🔁 Stop Running Opus for Everything: Loop Engineering and the Multi-Model Playbook in Claude Code

The Biggest Leverage in Claude Code Right Now

The biggest leverage in Claude Code right now isn't a better prompt or a bigger model - it's the loop you build around them, and which model you put at each node.

This is a field guide to loop engineering: the four kinds of loops, the two dials that actually control cost and quality, and the multi-model pattern that lets you spend expensive models exactly where they pay off - and nowhere else.

Why I Went Down This Rabbit Hole

There's a phrase making the rounds on X right now: loop engineering. "Stop prompting, start designing loops." Like most good ideas it's been repeated into mush - ask ten people what a "loop" is and you'll get ten answers. But underneath the noise is something real, and it's the most important shift I've made in how I use Claude Code this year.

I spent the last few deep dives on the pieces - Skills, MCP servers, subagents. This one is about the system those pieces snap into: the loop. And specifically, the thing nobody was doing a year ago and everybody serious is doing now - running more than one model inside a single loop, so the expensive intelligence lands only on the decisions that need it.

Here's the punchline up front, because it's the whole article: the maximum benefit isn't from a bigger model. It's from a well-designed loop that uses a bigger model sparingly. The teams getting outsized results aren't the ones running Opus (or Fable) on every turn. They're the ones running a cheap, fast model for the ninety mechanical steps and reserving the expensive model for the ten judgment calls - the plan, the hard bug, the adversarial review that decides whether the loop is allowed to stop.

Let me show you how to build that.

TL;DR

A loop is an agent repeating cycles of work until a stop condition is met. There are four kinds - turn-based, goal-based, time-based, and proactive - and they differ by how they're triggered and stopped.

Two dials control everything: model and effort.

• Model = how capable (which frozen weights).
• Effort = how thorough (how many files it reads, how much it verifies, how far it pushes before checking in).

They're independent.

The mental model: Fable is the specialist, Opus the expert, Sonnet the really good generalist, Haiku the fast hands. Most real loops need some of each.

The multi-model loop is the core move: cheap/fast models do the high-volume iteration and mechanical execution; expensive models do the judgment - planning, the genuinely hard step, and the verifier/judge that gates the loop.

Counterintuitively, the expensive model is sometimes cheaper. On hard, multi-step work it reaches the quality bar in far fewer iterations than a small model grinding toward its limit.

Dynamic workflows make this scale - Claude writes a JavaScript harness that spawns dozens of subagents, picks a model per agent, and keeps the orchestration plan in script variables instead of the context window.

A 30-Second Refresher: What Actually Is a Loop?

Every prompt you send already starts a loop. Ask Claude to add a button and it gathers context, makes the edit, runs the tests, checks its work, repeats if needed, and hands something back. That cycle - gather → act → verify → repeat → respond - is the agentic loop.

Loop engineering is just deciding, deliberately, how that cycle is triggered, how it stops, and what runs at each step.

The Claude Code team categorizes loops four ways. You climb this ladder as the work gets less interactive and more autonomous:

1. Turn-based loops - You are the stop condition. Triggered by a prompt; stops when Claude judges the task done (or needs you). Best for short, one-off tasks where you're exploring or deciding. You improve it by tightening the verification step - encoding "what good looks like" as a Skill so Claude can check its own work end-to-end instead of handing back a hopeful guess.

2. Goal-based loops (/goal) - A stop condition is the boss. Triggered manually, but instead of letting Claude decide when it's "good enough," you define done: /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries. Each time Claude tries to stop, an evaluator model checks your condition and sends it back to work until the goal is met or the turn cap is hit. Deterministic criteria - tests passing, a score threshold - are what make this sing.

3. Time-based loops (/loop and /schedule) - A clock is the trigger. /loop 5m check my PR, address review comments, and fix failing CI re-runs a prompt on an interval. /loop runs on your machine (turn it off, it stops); promote it to the cloud with /schedule and it becomes a routine. Best for recurring work or reacting to external systems.

4. Proactive loops - An event triggers it, with no human in real time. The top of the ladder: routines that watch a queue - bug reports, incoming feedback, dependency upgrades - and act on each item until its goal is met.

And here's the line from Anthropic's own guidance that this entire article expands on: you manage these by "routing routines to smaller, faster models and using the most capable model for judgment calls." That sentence is the thesis. Everything below is how to execute it.

The Two Dials: Model and Effort

Before we mix models, you have to understand the two settings that look like they both "make the answer better" - because they don't do the same thing.

Model = capability. Choosing a model swaps which set of frozen weights handles your request. The weights are where everything the model "knows" lives; they're read-only by the time you're calling the API. A bigger model isn't thinking longer - it's a fundamentally more capable brain. It also sets the per-token price.

Effort = thoroughness. Effort controls how much work Claude does on your request: how many files it reads, how much it verifies, how far it pushes through a multi-step task before checking in with you. High effort can generate roughly 7x more tokens than low effort for the same prompt, because Claude plans more, double-checks more, and pursues more hypotheses before declaring done.

The clearest way I've seen it framed (courtesy of the Claude Code team) is a cast of characters:

• Fable - the specialist who's seen problems almost no one else has. Even glancing at the thing everyone else is stuck on, it spots what nobody else would.
• Opus - the expert. Deep experience with problems like yours; brings patterns and gotchas that aren't anywhere in your codebase.
• Sonnet - the really good generalist. Give it a whole afternoon (high effort) and it'll read everything, run it, and understand your specific code thoroughly.
• Haiku - the fast hands. Quick, cheap, more than enough for mechanical work.

Model is roughly how capable; effort is roughly how thorough. And the single most useful diagnostic when Claude gets something wrong: did it not know enough, or did it not try hard enough?

• Not enough knowledge → reach for a bigger model.
• Not enough diligence (skipped a file, didn't run tests) → raise the effort.

Two different failures, two different dials.

The Core Move: The Multi-Model Loop

Now put it together. The instinct, when a loop matters, is to run your best model on the whole thing. That instinct is expensive and, more often than not, worse - because most of the steps in any loop are mechanical, and a specialist doing mechanical work is just a costly generalist.

The move is to decompose the loop into roles and assign each role the cheapest model that does it well.

A loop has a handful of recurring node types:

Look at where the expensive models go: the planner and the judge. The two nodes that require taste, ambiguity-tolerance, and the "I've seen this before" recognition you can't get from context alone. Everything in between - the ninety turns of reading files, editing, and running tests - rides on Haiku or Sonnet.

You're paying specialist rates for specialist work, and fast-hands rates for everything else.

This is the shape of a proactive loop done right: a cheap model triages each incoming item and executes the routine fix; the expensive model is invoked only when a judgment call surfaces - an ambiguous bug, a design decision, a "is this actually done?" gate. The bill drops and the quality goes up, because each decision lands on the model built for it.

The Counterintuitive Part: Expensive Can Be Cheaper

Here's the bit that breaks people's mental model, and it's important for knowing when to spend up.

On routine work, a small and a large model both get it right. The large one just burns more tokens on extra verification at a higher per-token price. So for routine stretches, drop to the smaller model and save real money at no quality cost. This is the default, and most of your loop should live here.

On hard, multi-step work, the math flips. The small model has to grind toward the edge of its ability - burning iteration after iteration, each one costing tokens - while the large model reaches the same bar in far fewer steps. You pay more per token, but on a task that genuinely stretches the small model, the total cost per task can come out lower with the big model. And Fable pulls furthest ahead here: in Anthropic's own testing it finished jobs Opus and Sonnet couldn't reach at any effort level.

So "use the expensive model in the loop" isn't extravagance - it's precision. The waste isn't running Opus on the hard node; the waste is running Opus on the easy nodes, or running Sonnet in circles on a node that was always beyond it.

The skill is telling the two apart:

• Small model grinding and failing on a genuinely hard step → promote that node to Opus/Fable. Cheaper and it actually finishes.
• Big model cruising through trivial edits → demote that node to Haiku/Sonnet. Same result, a fraction of the cost.

Multi-Model Loop Patterns (Steal These)

These are the compositions I reach for. Each maps naturally onto a mix of models - cheap fan-out, expensive judgment.

Generator → Verifier. A cheap model produces the work; a separate agent verifies it against a rubric. The separation matters: a reviewer with fresh context is less biased than the agent that just wrote the code and is quietly in love with it. Cheap generate, moderate verify.

Proposer → Judge (Tournament). Instead of dividing the work, have several agents compete - spawn N attempts using different approaches, then a judge model compares them pairwise until a winner emerges. Comparative judgment ("A or B?") is far more reliable than absolute scoring, so this is how you sort or select on quality. Cheap proposers, expensive judge.

Fan-out → Synthesize. Split a big task into many independent sub-tasks, run a cheap agent on each in its own clean context so they don't cross-contaminate, then a synthesis step (a barrier that waits for all of them) merges the structured outputs. Cheap fan-out, capable synthesize.

Classify → Route. A cheap classifier inspects the task and routes it - to a different agent, a different behavior, or a different model. This is intelligence routing: a classifier does the cheap research ("how big is the auth module, how tangled is it?") and then dispatches to Sonnet or Opus based on the expected complexity. The router itself is cheap; it decides when to spend.

Loop-until-done. For work of unknown size, keep spawning agents until a stop condition (no new findings, no errors left) instead of a fixed number of passes - the goal-based loop, generalized.

Adversarial verification. For each agent's output, spawn a separate agent whose job is to attack it against a rubric. This is where an expensive judge earns its keep, because catching the flaw the generator missed is exactly the "know enough" problem a bigger model solves.

The through-line: generation and iteration are cheap; judgment is where you spend.

Scaling It: Dynamic Workflows

Turn-based mixing you can do by hand - switch models between prompts. But the real multi-model machinery shows up in dynamic workflows, where Claude Code writes its own JavaScript harness on the fly (trigger it with ultracode) to spawn and coordinate dozens - sometimes hundreds - of subagents.

Two properties make this the natural home for multi-model loops:

• A workflow can pick the model per agent and decide whether each runs in its own git worktree. Claude chooses the intelligence level and isolation each sub-task needs - cheap Haiku workers fanning out, an Opus judge at the barrier.
• The orchestration plan and intermediate results live in script variables, not the context window.

That's the unlock. It sidesteps the three failure modes that wreck long single-context loops:

• Agentic laziness - stopping at 35 of 50 items and declaring victory.
• Self-preferential bias - the model preferring its own output when asked to judge it (which is why the judge should be a separate agent, often a stronger model).
• Goal drift - the lossy erosion of the original objective across many turns and compactions.

Isolated agents with focused goals and an external orchestrator don't drift, don't get lazy, and don't grade their own homework.

This is how Bun got rewritten from Zig to Rust with workflows - fan a subagent out per callsite/test/module to make the fix, an adversarial agent to review it, then merge. And it's not just code: root-cause investigations, triaging support queues, ranking 80 resumes, verifying e