Suraj Khaitan

Posted on Jul 12

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

#ai #claude #agents #aws

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.

Loop	What you control	Use when	Primitive
Turn-based	The check	You're exploring or deciding	Verification Skills
Goal-based	The stop condition	You know what "done" looks like	`/goal`
Time-based	The trigger	Work happens on a schedule	`/loop`, `/schedule`
Proactive	The prompt	Work is recurring and well-defined	All of the above + dynamic workflows

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:

Node	What it does	Model to use
Router / classifier	Looks at the task and decides where it goes	Haiku / Sonnet
Planner	Breaks the goal into steps, picks the approach	Opus / Fable
Executor	Does the mechanical work — the edit, the query, the fix	Haiku / Sonnet
Verifier	Runs the tests, checks the output, catches the miss	Sonnet
Judge / evaluator	Decides, adversarially, whether the loop may stop	Opus / Fable

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 every claim in a draft against the source — all the same shape.

Pair a workflow with /loop to run it continuously and /goal to give it a hard completion bar, and you've got a proactive, self-verifying, multi-model system.

Where to Actually Spend Your Expensive Model

Concrete guidance, because "use it for judgment" is easy to say and easy to over-apply:

Spend Opus / Fable on:

The plan at the top of a hard loop — the decomposition sets the ceiling for everything downstream.
The genuinely hard node — the subtle bug, the unfamiliar domain, the architecture call where a smaller model is confidently wrong no matter how much context you give it.
The judge / evaluator that gates a goal-based loop or an adversarial-verification step. This is the highest-leverage expensive call you can make: it decides whether all the cheap work was actually good.
Ambiguity. Larger models handle "figure out what I mean" far better; smaller models want precise instructions.

Do NOT spend it on:

Mechanical edits you can describe precisely.
Running tests, fetching docs, grepping the repo — pure execution and I/O.
Routine triage where the pattern is well-defined.
"Just in case." Reserve the recognition you're paying the most for (that's Fable's whole pitch) for the tasks that genuinely need it.

The heuristic again: if a smaller model has full context, clearly tried, and still got it wrong — that node needs a bigger brain. If it got it wrong by being lazy, that node needs more effort, not more model.

Managing Token Usage (So the Loop Doesn't Bankrupt You)

Multi-model loops are cheaper than brute-forcing everything on Opus, but a runaway workflow can still spawn hundreds of agents. Guardrails:

Choose the right primitive and model for the job. Small tasks don't need a loop, a workflow, or a panel of five reviewers. Most traditional coding tasks just need one good turn.
Define clear success and stop criteria. Specific "done" gets Claude there sooner (but not too soon) and stops the loop spinning.
Pilot before a large run. Workflows can fan out enormously — gauge cost on a small slice first.
Use scripts for deterministic work. Running a script is cheaper than reasoning through the steps every time. A form-filling script beats re-deriving the code on each iteration.
Match the interval to reality. Don't run a routine every 5 minutes if the thing it watches changes hourly.
Set token budgets. You can literally tell a workflow "use 10k tokens" and it will cap itself. Budgets are advisory guidance the model is trained to respect, not a hard wall.
Watch the meters. /usage breaks down spend by skills, subagents, and MCPs; /goal with no arguments shows turns and tokens so far; /workflows shows each agent's token usage and lets you kill one mid-run.

Your model and effort choices are the biggest levers on what a loop costs. The whole multi-model discipline is, at heart, a cost-control discipline that happens to also raise quality.

A Worked Example: A Proactive Multi-Model Feedback Loop

Here's the shape end to end, the way Anthropic sketches it:

/schedule every hour: check #product-feedback for bug reports.
/goal: don't stop until every report found this run is triaged,
actioned, and responded to. When fixing a bug, use a workflow to
explore three solutions in parallel worktrees and have a judge
adversarially review them.

Trace the models through it:

/schedule wakes the routine hourly — no human in the loop.
A cheap classifier (Haiku) triages each report: dupe? real bug? feature request?
For a real bug, a workflow fans out three executor agents (Sonnet) into parallel worktrees, each attempting a different fix — isolated so they don't contaminate each other.
An expensive judge (Opus/Fable) adversarially reviews the three candidates against a rubric and picks the winner — the one node where you want the specialist.
/goal refuses to let the loop stop until every report is triaged, actioned, and responded to — no agentic laziness at "35 of 50."
Auto mode keeps it running without stopping to ask permission for routine steps.

One loop. Four different model tiers. The expensive brain touches exactly one node — the judgment call — and the rest runs on fast, cheap hands. That's the whole game in miniature.

A Word on Security

Autonomous, multi-agent loops touch untrusted input (public bug reports, scraped pages, incoming email), so borrow the quarantine pattern: bar the agents that read untrusted content from taking high-privilege actions, and let a separate, privileged agent act on their sanitized findings. Keep your PreToolUse hooks (exit code 2 to block) on the executor nodes, scope credentials to least privilege, and remember that a loop running unattended overnight is exactly when a prompt injection would love to fire. Delegation and automation don't remove your responsibility for the blast radius — they raise the stakes on getting it right.

How to Get Started

Don't build a hundred-agent workflow on day one. Climb the ladder:

Tighten one turn-based loop. Take a task where you're the bottleneck on verification and encode the check as a Skill. Now Claude self-verifies instead of handing back hopeful work.
Add a /goal. Pick a task with a deterministic finish line — tests green, a score threshold — and let the evaluator hold the loop open until it's truly met.
Mix two models. Run the loop's execution on Sonnet and hand the review to Opus (or vice-versa on effort). Feel the difference in the judgment node.
Schedule it. When the work recurs, move /loop to a /schedule routine and route the routine to a small model, reserving the big one for the judgment call.
Reach for a workflow only when the task is long, massively parallel, or adversarial — and pilot it small first.

Then observe where it stalls or over-reaches, and iterate. The loop is a system; treat it like one.

FAQ

Is "loop engineering" just a fancy word for prompting?
No. Prompting shapes one turn. Loop engineering designs the cycle around many turns — how it's triggered, how it stops, what verifies the work, and which model runs each node. It's the difference between asking well and building a system that keeps working after you walk away.

Why not just run everything on the most capable model?
Cost and, surprisingly, quality. Most nodes in a loop are mechanical, and a bigger model does them at a higher price with no benefit. Worse, a single model in one long context is prone to laziness, self-preference, and goal drift. A multi-model loop with isolated agents avoids all three.

When is an expensive model actually the cheaper choice?
On hard, multi-step work that stretches a smaller model. The small model burns iterations grinding toward its limit; the big model hits the bar in fewer steps, so total cost per task can be lower — and some tasks it simply can't reach at any effort.

Model or effort — which do I change first?
Ask: did Claude not know enough, or not try hard enough? Not enough knowledge (confidently wrong with full context) → bigger model. Not enough diligence (skipped a file, didn't run tests) → higher effort. But check your context first; often the real fix is upstream in CLAUDE.md or how the task was scoped.

Do I need dynamic workflows for a multi-model loop?
No. You can mix models across turns by hand, and /goal already introduces a separate evaluator model. Dynamic workflows are for scale — dozens of agents, per-agent model choice, and keeping orchestration out of the context window. Reach for them on long, parallel, or adversarial tasks, not everyday coding.

Final Take: The Loop Is the Product

Three deep dives into Claude Code's pieces — Skills, MCP servers, subagents — and this one finally names the thing they all serve: the loop. And the lesson rhymes with everything before it. The leverage isn't in more — more prompting, more model, more agents. It's in architecture: the smallest loop that closes the work, with the expensive intelligence placed at exactly the nodes that need it.

Loop engineering is really cost-and-quality engineering wearing a trendier name. Route the mechanical ninety percent to fast, cheap models. Reserve the specialist for the plan, the hard bug, and the judge that decides whether the loop is allowed to stop. Let a /goal hold the line against laziness, let separate agents kill self-preference, and let script-variable orchestration hold the objective steady against drift.

Do that, and something genuinely new falls out: a system that runs while you sleep, verifies its own work, spends your money where it counts, and gets the hard calls right because a specialist — not a tired generalist thirty turns deep — is making them.

The models keep getting better. The scarce skill is still yours: knowing which one to spend, and where. Cheap hands for the many, expensive judgment for the few.

Less model, sharper loop. That's the whole game.

About the Author

Suraj Khaitan — Gen AI Architect | Building scalable platforms and secure cloud-native systems

Connect on LinkedIn | Follow for more engineering and architecture write-ups

What does your best loop look like — and where do you draw the line on spending the expensive model? Drop your setup in the comments. I'm always hunting for a sharper loop.

DEV Community