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

An engineer at Anthropic has developed a multi-model playbook for Claude Code, arguing that the biggest leverage comes from loop engineering—designing agentic loops that use cheaper, faster models for routine steps and reserve expensive models for critical judgment calls. The approach categorizes loops into four types (turn-based, goal-based, time-based, and proactive) and emphasizes routing routine work to smaller models while using the most capable model for decisions that determine whether the loop stops.

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. 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 https://medium.com/@surajkhaitan16/i-tried-100-claude-skills-these-are-the-best-639e419b0325 on the pieces — Skills, MCP servers https://medium.com/@surajkhaitan16/i-tried-100-mcp-servers-these-are-the-only-12-worth-installing-687268bfbf59 , 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. 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 /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries. Each time Claude tries to stop, an 3. Time-based loops /loop and /schedule — a /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 | 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: 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. 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. 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: 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. 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: 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. Concrete guidance, because "use it for judgment" is easy to say and easy to over-apply: Spend Opus / Fable on: Do NOT spend it on: 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. Multi-model loops are cheaper than brute-forcing everything on Opus, but a runaway workflow can still spawn hundreds of agents. Guardrails: /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. 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 /goal 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. 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. Don't build a hundred-agent workflow on day one. Climb the ladder: /goal . /loop to a /schedule routine and route the routine to a small model, reserving the big one for the judgment call.Then observe where it stalls or over-reaches, and iterate. The loop is a system; treat it like one. 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. 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. Suraj Khaitan — Gen AI Architect | Building scalable platforms and secure cloud-native systems Connect on LinkedIn https://www.linkedin.com/in/suraj-khaitan-501736a2/ | 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.