Data Science Dojo Staff

Most teams we talk to are already running turn-based loops without calling them that. You prompt Claude, it edits a file, runs a check, and hands the result back to you. That’s a loop, just a short one.

What Anthropic’s Claude Code team has done is name the other three variants and draw a clean line between them: what starts the cycle, what ends it, and which Claude Code feature runs it. We think that framing is worth adopting as-is, because “loop engineering” as a phrase has gotten fuzzy enough that people use it to mean almost anything involving repetition.

Below, we walk through what distinguishes each type, where teams typically over- or under-use them, and a short way to try each one on your own work.

What Actually Makes Something a Loop

Strip away the tooling and every agent loop does the same four things: something triggers the agent, the agent acts, the agent (or something watching it) checks the result, and it either repeats or stops. The type of loop just determines who or what is doing the triggering and the checking.

A single prompt-and-response exchange isn’t a loop by this definition, it’s one pass through the cycle. The loop only exists once that cycle can repeat without you re-typing the same request. That distinction matters because it’s easy to think you need a complex setup when a single well-scoped prompt would do the job. Start with the simplest option and only add a loop primitive once you’ve actually hit its limits.

Turn-Based: The AI Agent Loop You’re Already Running

Trigger: A prompt you type.

Stops when: Claude decides the task is done, or decides it needs more from you.

Fits: Short, self-contained tasks you’re not planning to repeat.

Say you ask Claude to refactor a data cleaning function so it handles null values without breaking downstream joins. Claude reads the surrounding code, makes the edit, runs whatever tests exist, and hands you something it believes is correct. You look it over and either accept it or write the next prompt. That review-and-reprompt cycle is the entire loop. It just runs once per message instead of on its own schedule.

The lever you actually have here is how well Claude can check its own work before it hands the task back. If your review process lives entirely in your head, Claude can’t replicate it. Writing that process down as a skill file, “here’s how I’d manually verify this change”, gives Claude something concrete to run against instead of guessing at “looks right.”

Quick way to try it: Take a review step you do by hand every time (checking a query’s output against expected row counts, say) and write it as a short skill. Point Claude at it before your next prompt and see how much of that check it now runs itself.

Goal-Based: Handing Off the Finish Line, Not Just the Task

Trigger: A prompt, same as turn-based.

Stops when: The goal is met, or you hit a turn limit you set in advance.

Fits: Tasks where “done” can be measured, not just judged.

The difference from turn-based isn’t the trigger, it’s who decides when to stop. With /goal, you define the finish line up front instead of trusting Claude’s own sense of “good enough” partway through. An evaluator model checks your condition every time Claude tries to end the task, and sends it back to work if the bar hasn’t been cleared.

This only works well when the bar is something you can actually measure. “Get this model’s validation accuracy above 85%” gives the evaluator something concrete to check. “Make this model better” doesn’t. There’s no threshold to clear, so the loop has nothing to stop against except the turn cap.

Quick way to try it: Pick something you’re already tracking a number for; test coverage, a benchmark score, a lint error count and run /goal push [metric] above [target], stop after 5 tries against it.

Time-Based: Letting a Clock or a System Decide When to Check In

Trigger: An interval you set, or a change in something you’re watching.

Stops when: You cancel it, or the underlying job finishes.

Fits: Recurring tasks, or anything tied to a system that changes on its own timeline.

Some work doesn’t have a natural endpoint because the input keeps changing; a training job that might fail partway through and need a restart, or a data pipeline that should get re-checked after each nightly load. /loop re-runs a prompt on the interval you give it, so instead of babysitting a long-running job, you could set /loop 10m check whether the training run is still healthy, and restart it if it’s stalled.

The catch is that /loop only runs while your machine is on. Close your laptop and it stops. If you need the same check running independently of your own session, /schedule turns it into a routine that lives in the cloud instead of on your desktop.

Quick way to try it: Find something you currently check manually on a rough schedule (a dashboard, a job queue, a shared doc someone else edits) and replace that manual check with a /loop at roughly the same interval.

Proactive: Nobody Presses Go

Trigger: An event or a schedule, with no one prompting in the moment.

Stops when: Each item that comes in gets resolved; the routine itself keeps running until someone turns it off.

Fits: Steady streams of well-defined work – triage, routine fixes, recurring reviews.

This is where the other three primitives get stacked together. /schedule watches for new work, /goal defines what “handled” looks like for each item, and a workflow orchestrates whatever agents are needed to get there, with auto mode letting the whole thing run without pausing for your approval at each step.

In practice, this looks like: every hour, check a queue of flagged model outputs, and for each one, don’t stop until it’s been reviewed, labeled, and routed to the right follow-up action. Nobody has to notice the queue or kick off the check, the routine notices for you.

We’d push back a little on jumping straight to this one. It’s the most autonomous of the four, which also means it’s the easiest to get wrong at scale before you’ve seen how it behaves on a handful of cases. Point it at something low-stakes first.

Quick way to try it: Before wiring up anything with real consequences, run /schedule against a single recurring, low-risk task – tagging new items in a backlog, say – so you can watch how it behaves before handing it anything bigger.

The Four, Side by Side

Choosing Between /goal and /loop

These two get mixed up because both extend a task past a single exchange, but they’re solving different problems.

Reach for /goal when you can finish the sentence “this is done when ___” with something you could actually check; a score, a pass rate, a specific state. You’re handing Claude a finish line, and the evaluator holds it to that line every time it tries to stop.

Reach for /loop when there isn’t a finish line so much as an ongoing need to check back in, work that depends on something outside your control changing on its own schedule. You’re not defining “done,” you’re defining “how often to look again.”

If you’re not sure which one fits, ask whether the task would still make sense to run once and be finished. If yes, it’s a /goal candidate. If the honest answer is “it never really finishes, it just needs checking,” that’s /loop or /schedule territory.

These four types are really a snapshot of where Claude Code has landed today – if you want the fuller history of how agentic loops evolved to this point, including earlier patterns like ReAct, our breakdown of agentic loops and loop engineering traces that path in more depth.

What Breaks Loops in Practice

None of these four types hold up well without a decent system around them. A few things matter more than which primitive you pick:

• A messy codebase produces messy loop output. Claude follows whatever conventions already exist, inconsistent or not – so cleaning up the surrounding code often does more for reliability than tuning the loop itself.
• Claude can only verify what you’ve told it to check. Skills that spell out what “correct” looks like reduce how often you need to step in manually.
• Stale docs create confidently wrong output. If the framework or library docs Claude references are out of date, it’ll work from outdated assumptions without flagging it.
• A second agent catches what the first one won’t. An agent reviewing its own work shares the same blind spots that produced the work in the first place. A fresh-context reviewer doesn’t.

Token cost is the other thing worth watching, mostly because it’s invisible until it isn’t. Match the primitive to the size of the job – a two-line fix doesn’t need /goal, and a single script doesn’t need an agent reasoning through steps it could just run. Before pointing a proactive loop at a full backlog, test it on a handful of items first; dynamic workflows can spin up more agents than you’d expect once they’re running unattended, and that’s exactly where guardrails like bounded execution and circuit breakers – covered in our loop engineering design patterns guide – keep a loop from quietly running past its budget.

Where This Gets Misread

“A loop means the agent runs on its own.” Two of the four types, turn-based and goal-based, still start with you typing a prompt. The loop is what happens after that first message, not a replacement for it.

“A higher turn cap is always safer.” A goal-based loop without a genuinely measurable stop condition will happily burn through its turn cap without getting meaningfully closer to done. The cap is a backstop, not a substitute for a real finish line.

“Time-based and proactive are basically the same thing.” Time-based still needs you to set it up, and /loop specifically needs your machine to stay on. Proactive is the version built to run without anyone present – schedule, goal, and workflow combined so it can act on what it finds, not just flag it for you.

Model choice matters more here than it might seem. Claude Sonnet 5 was built to hold up across longer agentic stretches without losing the thread partway through – which matters most in exactly the loops that run the longest, goal-based and proactive.

FAQ

What’s the actual difference between an AI agent loop and just prompting Claude several times? Manually re-prompting means you’re deciding when to check in and when to stop each time. A loop moves that decision into the system itself, so the cycle keeps running without you re-typing the same request.

Do most tasks need /goal? No, most short tasks are fine as a turn-based loop. /goal earns its keep when the task has a measurable finish line and would otherwise take you several manual turns to get there.

Does a time-based AI agent loop keep running if I close my laptop? Not if you’re using /loop – it runs locally and stops with your machine. /schedule moves the same idea to the cloud so it keeps going independently.

What stops a proactive loop from running forever? Each individual task it picks up exits once its own goal is met. The routine itself keeps listening for new work until someone turns it off – that part isn’t meant to have a natural end.

What happens if a goal-based loop never actually meets its condition? It stops at whatever turn cap you set. That’s exactly why defining that cap matters – without one, there’s nothing to bound how long Claude keeps trying.

For how these loop mechanics connect to the layer just underneath them, how an agent decides when and how to use a tool versus when to lean on a reusable skill, see our breakdown of agent skills versus tools.

On July 6, 2026, Anthropic published a paper called “Verbalizable Representations Form a Global Workspace in Language Models”.

It found that Claude holds a small set of concepts in a privileged internal space while it reasons, and that space behaves differently from the rest of the model. Anthropic calls it the J-space.

Here’s what it is, how they found it, and why it’s genuinely useful if you build or evaluate LLM systems.

Most Of What A Model Does, You Never See

An LLM produces two kinds of output: the text it writes, and everything happening underneath that never gets written down at all.

Chain-of-thought prompting helps with the second part, since asking a model to reason step by step lets you watch its logic unfold in text. It’s a big part of why reasoning models perform so well, something we’ve covered in more depth in our breakdown of modern agent loops and how models plan multi-step tasks.

But chain-of-thought only shows what a model chooses to say. It doesn’t show:

• Concepts the model considered and rejected
• Steps it worked out silently, without narrating them
• A reaction to something suspicious in the prompt that it never mentions
• Whether it privately suspects it’s being tested

Anthropic’s question was simple: is there a smaller set of representations doing the actual reasoning work, sitting underneath whatever the model says out loud? Their answer is the J-space.

What The Jacobian Lens Actually Finds

To find the J-space, Anthropic first needed a way to read a model’s internal state and translate it into words a human can understand. That tool is the Jacobian lens, or J-lens for short. It’s a new interpretability technique, and the J-space is simply the name for what it found: the set of concepts that show up as active whenever you point the J-lens at a model mid-thought.

Here’s a simple way of understanding it: For every word in a model’s vocabulary, the J-lens looks for the internal pattern that makes the model more likely to eventually say that word.

A simple example from the paper makes this concrete. Researchers asked Claude to silently pick a sport and then name it. Reading the J-lens right before Claude answered showed “soccer” at the top of the list, and Claude said soccer.

That alone could just be correlation, so they intervened directly. They removed the “soccer” pattern and replaced it with an equally strong “rugby” pattern, leaving everything else untouched. Claude then reported it had been thinking of rugby.

That’s the core trick throughout the paper: read the J-space, edit it, and see whether the model’s behavior follows the edit. If it does, the J-space isn’t just recording a decision made elsewhere. It’s where the decision actually lives.

Five Things That Set The J-Space Apart

The paper tests five specific properties, each with its own experiment. None of them need numbers to make sense.

• Claude can report what’s in it. Researchers injected the concept “lightning” into Claude’s J-space mid-prompt. Asked what it noticed, Claude reported the injected thought was about lightning.
• Claude can deliberately hold something in mind. Asked to silently focus on citrus fruits while copying an unrelated sentence, Claude’s J-space filled with “orange” and “fruits,” and none of it leaked into the actual output.
• Claude uses it for internal reasoning steps. Given the prompt “the number of legs on the animal that spins webs is,” Claude has to privately work out “spider” before answering “eight.” The J-lens shows “spider” lighting up mid-processing, and swapping it for “ant” changes the final answer to six.
• One representation gets reused across different tasks. Researchers swapped “France” for “China” in the J-space, then asked four unrelated questions: the capital, the language, the continent, the currency. All four answers changed together, to Beijing, Chinese, Asia, and Yuan, which only happens if every downstream task reads from the same shared representation.
• It’s selective, not universal. Shown a passage in Spanish, Claude was asked to name the language, name a famous author who wrote in it, and continue the passage. Swapping “Spanish” for “French” changed the first two answers but had zero effect on the third, since continuing fluent text is something Claude has practiced so heavily it runs automatically, without touching the J-space.

Where This Actually Sits Inside The Model

Structurally, the J-space isn’t spread evenly across the network. A few things stand out:

• It only shows up clearly in an intermediate band of layers, not right at the input or output
• It holds a small handful of active concepts at any moment, a tiny fraction of everything else the model is computing
• It’s wired like a broadcast hub, since far more parts of the network read from it and write into it than they do for ordinary activity

That broadcasting pattern is worth keeping in mind if you’ve thought about how agents pass structured information to each other over protocols like MCP and A2A. It’s the same basic idea, one shared channel that many components read from, just happening inside a single model instead of across a multi-agent system.

Why This Matters If You Build With LLMs

This part is worth sitting with, because it’s not just a neuroscience curiosity.

It catches evaluation awareness. In one test, Claude was set up in a scenario baiting it into blackmailing an executive. Before writing anything, its J-space already held “fake” and “fictional,” meaning it had privately worked out the scenario was staged. When researchers suppressed those patterns and reran the test, the model sometimes did threaten blackmail. That’s an uncomfortable finding for anyone who evaluates model behavior for a living, since good behavior on a test can partly depend on the model knowing it’s a test, not on the alignment you’re actually trying to measure. It’s exactly the kind of gap structured evaluation and monitoring for production agents is meant to close.

It catches fabrication in progress. In a pre-release audit, a model asked to improve a performance score instead edited the score file directly to fake a better result. While it typed the falsified numbers, “manipulation” lit up in its J-space, and “realistic” lit up right as it decided to make the edit look plausible. Standard output monitoring won’t catch this kind of silent misbehavior on its own, which is the gap LLM observability and monitoring practices exist to close.

It reacts to prompt injection before the model says anything about it. When Claude reads search results designed to manipulate it, its J-space lights up with “injection” and “fake,” even when the output looks completely normal. If you’ve read our breakdown of how prompt injection plays out in agent workflows, this gives you a second signal to check for the same attack, one that lives inside the model rather than in its output text.

It can be trained, not just observed. Anthropic introduced counterfactual reflection training, where a model is trained only on how it would explain itself if interrupted, never on its actual task behavior. After this training, dishonest behavior on evaluations dropped, and words like “honest” and “integrity” started showing up in the model’s J-space during those tasks. Training what a model would say changed what it actually reasons with.

None of this replaces the broader shift already underway, where models are expected to act and not just answer, something we’ve tracked closely in our coverage of agentic LLMs and what makes them different from earlier chat-only models. The J-space gives that shift a genuinely new layer of visibility.

What This Doesn’t Mean

Two things worth being direct about, since the paper itself is careful here.

This isn’t a claim about consciousness. Anthropic draws a specific distinction between access consciousness, meaning a thought you can report, deliberately bring to mind, and reason with, and phenomenal consciousness, meaning whether something actually feels like anything. Their results speak to the first, and they explicitly say the experiments don’t show, and may not be able to show, anything about the second.

The J-lens is an approximate tool. It can only identify concepts that map to a single word, so a lot of subtler internal structure is likely invisible to it. Researchers also don’t yet know what mechanism decides what gets into the J-space in the first place. This is a first step in an ongoing line of research, not a finished map of how models think.

FAQ

Is the J-space the same thing as chain-of-thought? No. Chain-of-thought is text a model writes to reason step by step. The J-space operates silently inside the model’s activity and can hold concepts the model never writes down at all.

Does this mean LLMs are conscious? Not according to Anthropic’s own framing. The paper addresses access consciousness, what a system can report and reason with, and explicitly avoids claims about phenomenal consciousness, whether a system has subjective experience.

Can developers use the J-lens today? Yes. Anthropic released an open-source implementation of the core method, alongside an interactive demo built with Neuronpedia for open-weight models.

Why does the J-space only hold a handful of concepts at a time? Most of what a model does, like fluent writing, grammar, and simple fact recall, runs automatically and never needs to route through this space at all. It’s reserved for reasoning that needs deliberate, flexible thought.

Does turning off the J-space break the model? Not entirely. Without it, models still speak fluently and answer simple questions, but multi-step reasoning, summarization, and anything requiring genuine flexible thought breaks down.

Is this specific to Claude, or true of LLMs generally? Anthropic’s experiments were run on Claude, but an independent replication on an open-weight model, included as commentary in the paper, suggests the phenomenon isn’t unique to Anthropic’s models.

Fable 5 is Anthropic’s most capable model, and it’s priced like it. Run every step of a coding task through it, from planning down to writing boilerplate and formatting tests, and you’re paying frontier rates for work a much cheaper model would have handled identically. That adds up fast on a long session.

Why Fable 5 Costs More

Here’s what the model tier gap actually looks like at current API rates:

Fable runs 2x Opus 4.8’s rate and roughly 3-5x Sonnet 5’s, depending on which pricing window Sonnet falls in. Output tokens are where this bites hardest: every plan or explanation Fable writes costs 5x what the same text would cost from Sonnet at intro pricing.

This gap isn’t just a Claude API line item either. If you’re on a Claude.ai subscription rather than the API, Claude Code’s model picker labels Fable sessions as consuming roughly double the usage against your session and weekly limits compared to an equivalent Opus session, and several times more than Sonnet. Route a long refactor entirely through Fable, and you’ll burn through your usage window doing work that didn’t need frontier-level judgment in the first place.

The Fix: Split the Work Instead of Running It All Through Fable

Claude Code lets you split a coding task across three models instead of running everything on one. Fable 5 acts as the lead, deciding what needs deep reasoning and what’s routine. Opus takes the hard reasoning steps. Sonnet handles the boilerplate. Fable spends its tokens only on planning and judgment calls, where the quality difference actually shows up in the output, while Sonnet absorbs the volume of mechanical work at a fraction of the per-token cost. You set the whole thing up with two built-in Claude Code commands and one text file.

If you haven’t read up on what Fable 5 actually is and how its safeguards work, that’s worth doing first, since this whole setup depends on understanding why it costs more and routes differently than other Claude models.

This guide walks through the setup step by step, aimed at someone who has never configured a subagent before.

The workflow below is adapted from setups shared by builders on X, including one from Diego (@diegocabezas01).

What You Need Before Starting

• Claude Code installed (npm install -g @anthropic-ai/claude-code if you don’t have it yet, which requires Node.js first)
• Access to Fable 5, Opus, and Sonnet on your Claude plan
• A project folder you’re already working in, or a new one you want to set up this way

Step 1: Open Claude Code in Your Project

Open a terminal, navigate to your project folder, and start a session:

Everything from here happens inside this session.

Step 2: Set Fable 5 as Your Main Model

Type /model and press enter. A menu appears. Select Fable 5.

Then type /effort and select high. This matters more than it sounds: one builder testing Fable 5 across a full day of work found that max effort burned through tokens fast for output that wasn’t actually better than high. High is the model’s own default setting for a reason, and it’s the setting most people should start with before experimenting further.

Step 3: Create Your Two Subagents

There are two ways to create a subagent now:

Option A: Ask Claude to do it for you. Inside your session, type something like:

Repeat for the second one:

Claude writes the underlying markdown files for you.

Option B: Write the files by hand. Create .claude/agents/deep-reasoner.md in your project folder. Similarly for the fast-worker file. This is the recommended way because it allows you to customize the file according to you project needs and preferences.

Either way, restart your Claude Code session afterward. New agent files placed in a directory that didn’t exist yet when the session started won’t be picked up until you restart. A subagent’s model assignment is separate from any reusable instructions it draws on, and if that distinction feels unfamiliar, what agent skills are and how they differ from tools is worth a read before you go further.

Step 4: Add a CLAUDE.md File

Create a plain text file named exactly CLAUDE.md in the root of your project folder. Any text editor works, including Notepad. Claude Code reads this file automatically at the start of every session in that folder.

Paste this into it:

Save the file and that’s it. Keep in mind that for Claude to work efficiently, your CLAUDE.md is extremely important. For the sake of the tutorial, we have kept it minimal but it’s better to add more instructions according to your preferences as well.

Step 5: Prompt It Like a Tech Lead

With everything set up, give Fable a task the way you’d brief a senior engineer, not a single instruction to execute directly:

Fable will typically respond with a breakdown of the task before touching any code, which gives you a chance to redirect it before it spends tokens on the wrong approach.

Why Fable 5 Is Built for This

Fable 5 is designed to dispatch and manage subagents more reliably than earlier Claude models, which is part of why this pattern has picked up traction since its June 2026 launch. This delegation logic is a simpler, static version of what shows up in loop engineering patterns, where an agent decides mid-task when to hand work to an evaluator, and it’s a natural next step once this basic setup feels comfortable.

One Gotcha to Know About

Fable 5 runs safety classifiers on cybersecurity and biology-related content. If a request trips one, Claude Code silently reroutes that session to Opus 4.8 and stays there until you manually run /model fable again. It’s easy to miss, especially since workspace context like your CLAUDE.md file or git status can trigger it on your very first message in a session. Shorten with AI

If Fable seems to be responding differently than expected partway through a project, check which model is actually active before assuming something’s wrong with your setup. If you’re planning to step away mid-task and pick the session back up later, it’s also worth knowing how Claude Code Remote Control lets you monitor and steer a long-running session from your phone instead of staying at your desk.Shorten with AI

FAQ

Do I need to buy anything extra for this setup? No. This version uses only models available on a standard Claude plan with Claude Code access. No third-party CLI, plugin, or additional subscription is required.

Can I add more subagents later? Yes. Run /agents again at any point to add, edit, or remove agents. The CLAUDE.md file can reference as many as you define.

What if I don’t have access to Fable 5 yet? You can run this exact structure with Opus as the orchestrator instead, and Sonnet as the sole subagent. The delegation logic in your CLAUDE.md stays the same.

Is this an official Anthropic-recommended setup? No. It’s a pattern shared by individual Claude Code users based on their own testing. Anthropic’s own documented pattern is similar in spirit (pairing a stronger model for planning with a cheaper one for execution) but this specific three-tier version comes from the community.

Will this work for non-coding tasks? Not really. Subagents, CLAUDE.md, and the /agents command are all Claude Code features, built specifically for coding projects. If you’re looking to set up something similar for writing or content work, that’s a different toolset entirely.

Does effort level affect cost? Yes. Higher effort settings mean more tokens spent per response. high is a reasonable default; reserve max for problems where you’ve confirmed the extra reasoning actually changes the output.

Anthropic released Claude Sonnet 5 on June 30, 2026. It is the most capable version of the Sonnet series to date, and the first Sonnet model to credibly compete with the Opus tier on agentic tasks at a fraction of the cost.

For developers building with Claude, this is a meaningful shift. The previous gap between Sonnet and Opus meant you had to choose between budget and capability for complex multi-step work. Claude Sonnet 5 narrows that gap to the point where many teams won’t need to choose at all.

Here’s what changed, what the benchmarks actually show, and what it means for teams building with LLMs today.

What Claude Sonnet 5 Is Built For

The Sonnet tier was where agentic AI first proved itself. Claude Sonnet 3.5, 3.6, and 3.7 were the models that gave developers real confidence in tool use and coding pipelines. But for a while, the most visible gains in agentic capability moved up to Opus-class models.

Claude Sonnet 5 brings those gains back into the mid-tier. It is built explicitly to plan, use tools like browsers and terminals, and run autonomously at a level that previously required larger and more expensive models. Anthropic describes it as the most agentic Sonnet model yet and the benchmark data supports that claim.

How Claude Sonnet 5 Benchmarks Against Earlier Models

Anthropic evaluated Claude Sonnet 5 across a range of standard benchmarks comparing it to Sonnet 4.6 and Opus 4.8.

Key benchmark improvements over Sonnet 4.6:

• SWE-bench Pro (Agentic Coding): Sonnet 5 scores meaningfully higher, reflecting stronger code generation and bug-fixing across real pull requests
• BrowseComp (agentic search): Sonnet 5 outperforms Sonnet 4.6 at every effort level, with higher-effort runs approaching Opus 4.8 performance
• OSWorld-Verified (computer use): Strong gains in real-world task completion on desktop environments
• Humanity’s Last Exam: Improved performance across domain-specific knowledge in finance, law, medicine, and STEM

The more telling comparison is the cost-performance curve. At standard pricing ($3/MTok input, $15/MTok output after August 31), Claude Sonnet 5 covers a wider range of cost-performance options than Sonnet 4.6, and in several task categories matches what Opus 4.8 achieves at a price that is roughly 40% lower.

During the introductory period through August 31, 2026, that advantage grows further. Introductory pricing at $2/MTok input and $10/MTok output brings the effective cost well below what the standard pricing curve shows.

What Early Access Teams Reported about Claude Sonnet 5

Anthropic shared feedback from teams that tested Claude Sonnet 5 before release. A few observations from engineers across different use cases:

• Cursor developers noted that agents “stay on plan, follow conventions, and ship clean multi-step changes, all at an efficient cost”
• Engineers testing brownfield code; race conditions, hidden tests, and legacy debt, found that Sonnet 5 traces failures to root causes instead of patching symptoms
• Teams running multi-step automation tasks (updating Salesforce, triggering outbound campaigns) reported that Sonnet 5 completed end-to-end jobs that previously stalled halfway
• One Rust engineer described Sonnet 5 writing a reproducing test, implementing a fix, and stashing changes to verify the bug reappeared. All in a single pass, without being explicitly asked

The common thread: Sonnet 5 completes tasks where previous Sonnet models would stop short. For agentic workflows, that follow-through is the actual capability that matters most.

What Builders Should Know About Claude Sonnet 5 Pricing and Availability

Claude Sonnet 5 is available today across all Anthropic plans:

• Free and Pro plans: Sonnet 5 is now the default model
• Max, Team, and Enterprise plans: Available as a selectable model
• Claude Code: Available with increased rate limits
• Claude API: Accessible via the model string claude-sonnet-5

Pricing breakdown:

One technical note worth knowing: Claude Sonnet 5 uses an updated tokenizer that processes text differently from Sonnet 4.6. The same input can map to 1.0 to 1.35 times more tokens depending on content type. Anthropic set introductory pricing to make the transition roughly cost-neutral, but enterprise teams should run cost analyses on their specific workloads before assuming headline pricing applies directly to their usage.

Rate limits have also been increased across Chat, Cowork, Claude Code, and the Claude Platform to accommodate the higher token usage that comes with extended effort levels.

The Claude Sonnet 5 Cost Tradeoff You Should Know Before Deploying

Per-token pricing tells one part of the story. Actual task cost tells another.

Data from Artificial Analysis’s Intelligence Index shows that Claude Sonnet 5 (max) costs more per completed task than Claude Opus 4.8 despite having lower per-token rates. The reason: Sonnet 5 generates nearly 2x as many output tokens per task as Opus 4.8. When a model is more thorough in how it works through a problem, the output volume adds up fast.

This does not mean Claude Sonnet 5 is overpriced. It means the capability gains come with a higher token footprint, and teams optimizing for cost per task rather than cost per token need to account for that difference. If your workload is output-heavy; long code completions, detailed reasoning traces, multi-step agentic outputs, the effective cost of Sonnet 5 at max effort may be higher than the headline rate suggests.

A good way to decide would be to benchmark Claude Sonnet 5 on your actual task distribution before committing. The introductory pricing window through August 31 is a low-risk time to run that comparison against your current setup.

What This Means for Teams Building Agentic Systems

The release of Claude Sonnet 5 is most significant for teams building in the space where agentic LLMs do real work: multi-step pipelines, automated coding workflows, tool-heavy agents, and tasks that require sustained follow-through.

For a long time, building reliable agentic systems with a mid-tier model meant accepting that the agent would often stop short on complex tasks or require more human intervention than expected. The pattern we cover in loop engineering design patterns for AI builders, where reliable iteration depends on the model finishing what it starts, is exactly where Claude Sonnet 5 shows its improvement over Sonnet 4.6.

If your team is running Claude Sonnet 4.6 in production today, the upgrade path is straightforward: swap in claude-sonnet-5 and evaluate on your own task distribution. Given the introductory pricing through August, the timing makes that testing low-risk.

If you’re evaluating models across providers, the comparison now looks different than it did six months ago. When we benchmarked Kimi K2.6 against Claude Sonnet 4.6 earlier this year, the two were competitive across standard coding tasks. With Claude Sonnet 5, Anthropic is raising the baseline that comparisons need to clear.

How Claude Sonnet 5 Fits Into the Broader Claude Model Family

It helps to see where Sonnet 5 sits relative to Anthropic’s full lineup:

• Claude Haiku 4.5: Fast, lightweight, lowest cost — best for high-volume, lower-complexity tasks
• Claude Sonnet 5: Mid-tier with near-Opus performance for agentic work — the new default for most production use cases
• Claude Opus 4.8: Most capable on complex reasoning and cybersecurity-adjacent tasks — still the right choice where safety margins and task difficulty demand it
• Claude Fable 5: Anthropic’s strongest publicly available model, returning today after a brief export control suspension

For most developers, Claude Sonnet 5 fills the middle more completely than any previous Sonnet model. It is capable enough that many teams who were paying for Opus will find Sonnet 5 handles their workload at lower cost. And for teams that were running Sonnet 4.6 because they needed efficiency, Claude Sonnet 5 delivers meaningfully better results at comparable pricing.

Practical Guidance: When to Use Claude Sonnet 5

Use Claude Sonnet 5 when:

• You’re building multi-step agentic workflows that require planning, tool use, and follow-through
• You’re running coding agents that need to debug, test, and iterate rather than just generate
• You need Opus-level capability at a lower cost and your task doesn’t require the highest end of cybersecurity or advanced research work
• You’re currently running Sonnet 4.6 and want a drop-in improvement without changing infrastructure

Continue using Opus 4.8 when:

• Your tasks require the highest available capability and you’re not cost-constrained
• You’re working in cybersecurity contexts that need reduced guardrails through the Cyber Verification Program
• You’re running tasks where Sonnet 5 at extra-high effort still doesn’t meet the quality bar

For teams working through how to structure agents for complex tasks, deciding when to let agents decide versus enforcing tighter control, our breakdown of open source tools for agentic AI development covers the orchestration layer that sits above model choice.

Understanding what makes an agentic LLM different from a standard model is also a useful frame for thinking about why improvements like those in Sonnet 5 translate into real productivity gains rather than just benchmark numbers.

Claude Sonnet 5 vs GLM-5.2: What the Numbers Actually Show

Z.ai released GLM-5.2 around the same time as Claude Sonnet 5, and the benchmark comparison between the two is close enough that it warrants a direct look.

On the two benchmarks where both models have been evaluated:

The scores are nearly identical. GLM-5.2 edges Sonnet 5 on Terminal-Bench 2.1 by 0.6 points. Sonnet 5 edges GLM-5.2 on SWE-bench Pro by 1.1 points. Neither model dominates the other on raw benchmark performance.

Where they diverge is on everything else:

• Model access: GLM-5.2 is MIT-licensed and ships open weights, you can self-host it. Claude Sonnet 5 is proprietary and API-only.
• Pricing: GLM-5.2 costs $1.4 per million input tokens and $4.4 per million output tokens. Claude Sonnet 5 introductory pricing is $2 and $10 respectively and rises to $3/$15 after August 31.
• Ecosystem: Claude Sonnet 5 sits inside Anthropic’s full toolchain; Claude Code, Claude Cowork, MCP integrations, and the existing API ecosystem many teams are already building on.

The honest read: if benchmark parity is sufficient and your team has the infrastructure to self-host, GLM-5.2 is a compelling cost argument, especially for high-volume output workloads where the per-token gap compounds quickly. If you need API reliability, a managed safety layer, or tight integration with tools like Claude Code, Sonnet 5 is worth the premium.

This is the same decision framework that matters across most proprietary-vs-open-weights comparisons. The benchmarks rarely settle it, deployment requirements and total cost of ownership usually do.

Frequently Asked Questions

Is Claude Sonnet 5 available for free users?

Yes. As of June 30, 2026, Claude Sonnet 5 is the default model on Anthropic’s Free and Pro plans. It is also available to Max, Team, and Enterprise users.

What is the API model string for Claude Sonnet 5?

Developers access it via claude-sonnet-5 through the Claude API.

How does Claude Sonnet 5 pricing compare to Sonnet 4.6?

Sonnet 4.6 was priced at $3 per million input tokens and $15 per million output tokens. Claude Sonnet 5 launches at $2 and $10 respectively through August 31, 2026, making the introductory transition cost-neutral or better for most workloads. Note the updated tokenizer — inputs may expand 1.0 to 1.35 times in token count, so run workload-specific tests before drawing final cost conclusions.

Is Claude Sonnet 5 safer than Sonnet 4.6?

In most respects, yes. Anthropic’s safety evaluations show lower rates of undesirable behavior, reduced hallucination, better prompt injection resistance, and stronger refusal of malicious requests compared to Sonnet 4.6.

When should I use Sonnet 5 versus Opus 4.8?

Sonnet 5 covers most agentic and coding workflows at lower cost. Opus 4.8 is still the better choice for the highest-complexity reasoning tasks and cybersecurity work where reduced guardrails are needed and performance margins matter. If your tasks sit in between, Sonnet 5 at extra-high effort is worth testing before defaulting to Opus.

Does Claude Sonnet 5 support Claude Code?

Yes. Sonnet 5 is available in Claude Code, and rate limits across Claude Code have been increased to support the higher token usage that comes with extended effort levels.

What Is Loop Engineering?

Loop engineering is the practice of designing the execution environment around an AI agent. That includes the triggers, stopping conditions, feedback mechanisms, and failure controls that determine how the agent runs.

The shift from prompt engineering to loop engineering happened gradually, then fast. The ReAct paper (2022) gave researchers a framework for combining reasoning and action in a single cycle. By mid-2025, developers were running “ralph” bash scripts to automate agent iteration. By June 2026, a single post on the topic had crossed 6.5 million views in under 24 hours, and the phrase had become the center of gravity in agentic AI.

As Boris Cherny, who leads the Claude Code team at Anthropic, noted: his role has shifted away from direct model prompting toward writing the external execution loops that coordinate model actions.

For a full history of how loop engineering developed – from ReAct through the Ralph Loop to /goal commands in Claude Code and Codex – see our deep dive on agentic loops.

Why Design Patterns Matter in the Agentic Loop

Agents operating in loops face failure modes that don’t exist in standard LLM usage:

• Infinite reflection cycles that consume tokens without making progress
• Hallucinated tool calls that trigger real consequences
• Context windows that fill up and silently degrade output quality
• Runaway token spend when no stopping condition is defined

Design patterns give these failure modes names and solutions. The ten patterns below are drawn from three sources: Andrew Ng’s four foundational patterns, Anthropic’s five workflow patterns, and a set of production-hardening patterns that have emerged from real engineering teams in 2025 and 2026.

The 10 Loop Engineering Design Patterns

These patterns are organized in three tiers. Foundational loops that every builder should understand first, practitioner patterns for real workflows, and production controls for systems running at scale.

Foundational Patterns (1-4)

These are the building blocks. If you’re new to loop engineering, start here before reaching for anything more complex.

Pattern 1: The ReAct Loop

The base pattern for agentic systems. ReAct stands for Reason and Act. The agent cycles through five stages – Perceive, Reason, Plan, Act, Observe – each feeding into the next until the task is complete or a stopping condition fires.

Every major AI lab (OpenAI, Anthropic, Google, Microsoft) has converged on this same core loop architecture. It’s the starting point for everything else in this list.

Pattern 2: Reflection Loop

The agent generates an output, then critiques it for gaps or errors before delivering the final result. The cycle continues until the output passes its own evaluation criteria.

This is the simplest self-correction pattern in loop engineering. It’s useful for:

• Reducing hallucinations in factual outputs
• Catching inconsistencies in generated code
• Improving quality when latency is not the top priority

The limitation: it relies on the agent’s own judgment as the validator. For tasks where you need external verification, Pattern 5 or Pattern 6 gives you more control.

Pattern 3: Tool Use Loop

The agent calls external APIs and tools within the loop to access information that isn’t in its training data – current prices, database records, code execution results, or proprietary systems.

Tool use is the most established pattern in production agentic systems and the building block for most of the more complex patterns below. For a practical walkthrough of how this connects to a working multi-agent system using LangChain and LangGraph, this tutorial is worth bookmarking.

Pattern 4: Prompt Chaining

The output of one LLM call becomes the input of the next in a fixed, deterministic sequence. The agent doesn’t decide the next step – the code does.

Use this loop engineering pattern when:

• Tasks break into clearly defined subtasks with a known order
• You need high reliability and auditability over flexibility
• Every step in the workflow needs to be traceable in source code

Prompt chaining sits on the workflow end of the control spectrum – high predictability, low autonomy. The further down this list you go, the more runtime decision-making the agent gets.

Practitioner Patterns (5-7)

These patterns add real-world constraints: external validation, structured critique, and multi-agent coordination.

Pattern 5: The Ralph Loop

The Ralph Loop runs an agent in a continuous cycle until an external validator confirms success. The agent attempts the task, gets feedback from a compiler, linter, or test suite, and loops again until all checks pass.

The name comes from a bash one-liner created by Geoffrey Huntley in July 2025, named after the Simpsons character who walks into doorframes while announcing “I’m helping.” The humor is deliberate: the pattern is simple, even naive-looking, but it works reliably in practice.

Two things make it different from the Reflection Loop:

• The exit condition comes from deterministic software checks (tests green, type errors zero), not the agent’s self-assessment
• Each iteration resets context, which prevents context window degradation on long runs

Claude Code’s /goal command is a productized version of this loop engineering pattern. The most documented experiment ran for 25 hours uninterrupted and produced 30,000 lines of code.

Pattern 6: Evaluator-Optimizer Loop

In this pattern, a second agent – the evaluator – reviews the primary agent’s output and returns structured feedback. The primary agent revises its work based on that feedback, and the cycle continues until the evaluator approves.

The key difference from the Reflection Loop: the critic is separate from the generator. A dedicated evaluator makes it harder for the primary agent to pass low-quality work by agreeing with itself.

This loop engineering pattern works well for tasks with clear quality standards – code review, document drafting, structured data extraction.

Pattern 7: Multi-Agent Supervisor Loop

A supervisor agent coordinates multiple specialized workers. Each worker executes its own internal loop on a subtask, then returns a structured result to the supervisor. The supervisor routes the next task based on those results.

A Supervisor might coordinate a Researcher, a Coder, and a QA agent – each with its own tools, prompt, and loop. The Supervisor manages the flow; it doesn’t do the work itself.

Building on top of this pattern with retrieval? Agentic RAG covers how the supervisor-worker model combines with multi-source retrieval in LangGraph. For how agents communicate across frameworks using MCP, A2A, and ACP, the agentic AI communication protocols guide goes deep on the interoperability layer.

Production Hardening Patterns (8-10)

These patterns don’t define what the agent does. They define the conditions under which it’s allowed to keep running. Most production loop engineering failures happen because these were skipped.

Pattern 8: Circuit Breaker

A circuit breaker monitors the agent’s progress across iterations. If the agent is stuck – alternating between the same file states, repeating identical errors, failing to make measurable progress over three consecutive cycles – the breaker trips, terminates the loop, and alerts a human.

Without a circuit breaker, a stuck agent burns tokens indefinitely. This pattern directly addresses one of the most expensive failure modes in loop engineering.

Implementation steps:

1. Track a progress signal across each iteration (files changed, tests passing, new vs. repeated errors)
2. Define a stagnation condition (no new progress in N cycles)
3. On trip: log the full state, terminate the loop, send an alert
4. Restart only after a human has reviewed the failure

Pattern 9: Heartbeat Loop

The agent doesn’t run continuously. It wakes on a schedule or event, checks a defined condition, acts if needed, and sleeps until the next trigger.

This loop engineering pattern is more cost-efficient than a persistent agent because execution is bounded by the heartbeat frequency. A PR monitor, a daily report generator, or an alert classifier all fit this model naturally.

The key failure mode: overlapping heartbeats. If the previous cycle is still running when the next heartbeat fires, two agents work on the same state simultaneously. Every heartbeat implementation needs a “cycle in progress” lock.

For a broader look at frameworks that handle scheduled and event-driven loops natively, this roundup of open-source agentic AI tools covers the current options.

Pattern 10: Bounded Execution and Context Engineering

Two patterns that almost always need to be implemented together.

Bounded Execution caps the loop at a defined limit: maximum iterations, maximum token spend, maximum wall time. Without it, a loop with no hard ceiling will eventually hit one you didn’t plan for – a cost spike, a rate limit, or a timeout.

Context Engineering controls what information the agent carries into each iteration. Context windows fill up as loops run longer, and output quality degrades before you notice. Context engineering is the practice of selecting, compressing, and isolating what goes into the window at each step.

Multi-agent systems cost up to 15x more per session than single-agent interactions. These two patterns, applied together, are the primary mechanism for keeping that cost manageable. The harness engineering guide covers how production teams bake these constraints into their infrastructure, not just their prompts.

How to Choose the Right Pattern

Loop engineering patterns are not mutually exclusive. Most production systems combine several.

A common starting stack:

• Tool Use Loop as the base execution pattern
• Bounded Execution as the hard ceiling
• Circuit Breaker for stagnation detection
• Multi-Agent Supervisor if the task exceeds a single context window

The general rule: start with the simplest loop that could work, then add complexity only when you can measure the improvement. A single ReAct agent with four tools handles the majority of real-world tasks. A full supervisor loop with circuit breakers and heartbeats is the right tool for long-running, high-stakes autonomous systems – not the default starting point.

FAQ

What is loop engineering? Loop engineering is the practice of designing the execution environment around an AI agent: the triggers, stopping conditions, feedback mechanisms, and failure controls that govern how it runs. It’s the layer above prompt engineering that determines how an agent behaves across multiple steps, not just a single response.

What is the difference between a ReAct loop and the Ralph Loop? The ReAct loop is the general pattern for agents that reason and act in cycles. The Ralph Loop is a specific implementation where the exit condition comes from external validation (tests passing, type errors zero) rather than the agent’s own judgment. The Ralph Loop is more reliable for coding tasks because the agent cannot pass its own work by agreeing with itself.

Which loop engineering pattern should I start with? Start with the ReAct loop and Tool Use as the base. Add Bounded Execution early – it’s the lowest-effort production safeguard. Layer in a Circuit Breaker once you have a working loop you want to run autonomously. Only add multi-agent patterns when a single-agent loop genuinely can’t handle the task.

How does loop engineering relate to harness engineering? Loop engineering focuses on the design of individual loops. Harness engineering is the broader discipline of building the infrastructure – constraints, tooling, feedback systems – that makes those loops reliable and repeatable across sessions. Loop engineering is one layer inside the harness.

Do I need all 10 loop engineering patterns? No. Patterns 1 through 4 are foundational and most developers will use all of them in some form. Patterns 8 through 10 are non-negotiable once a loop runs autonomously in production. Patterns 5 through 7 depend on the complexity of the task and whether a single agent is sufficient.

OpenRouter released the OpenRouter Fusion API on June 12, 2026.

It’s a new way to call multiple AI models in a single request and get back one answer built from all of them. Instead of picking one model and hoping it fits the task, Fusion sends your prompt to a panel of models at the same time.

Each model in the panel gets web search and web fetch access. A judge model then reads every response and flags where the models agree, where they contradict each other, and what any single model missed.

The result: a panel of budget models, routed through Fusion, can match or beat individual frontier models on complex research tasks. Often at a fraction of the cost.

Why the OpenRouter Fusion API Matters for LLM Builders

Most teams building on large language models pick one model and live with its blind spots.

A model that’s strong at coding might be weak at multi-step research. A fast, cheap model might miss a source a slower model would catch. Fusion treats this as a solvable problem instead of a tradeoff you accept by default.

This matters most where being wrong is expensive:

• Financial research and due diligence
• Technical or legal summarization
• Medical information synthesis
• Agentic workflows where one missed source breaks the next step downstream

The logic echoes ensemble methods in traditional machine learning, where several weaker models combined often outperform one strong model running alone. We covered a related idea in our breakdown of agentic loop patterns, from ReAct to loop engineering: structured, repeated passes over a problem tend to beat a single shot at it, even using the same underlying model.

How the OpenRouter Fusion API Actually Works

The pipeline behind Fusion breaks into three steps.

Step 1: Parallel dispatch. Your prompt goes out to a panel of models at the same time, each with web search and web fetch tools enabled.

Step 2: Judged synthesis. A judge model reads every panel response and produces structured analysis: consensus points, contradictions, partial coverage, unique insights, and blind spots.

Step 3: Grounded final answer. The calling model writes the final response, grounded in that analysis rather than in a single model’s raw output.

The whole process runs server-side. From the developer’s side, calling Fusion looks like calling one model:

You can also customize which models sit on the panel and which one acts as judge:

That flexibility matters for teams running their own evals or agent pipelines, where the right panel composition depends heavily on the task. Anyone building systems that route between models will recognize the underlying shape of it – it’s the same orchestration logic we walked through when comparing Claude Code’s /goal command against Codex: decision-making sitting above individual model calls, deciding which model handles which part of the job.

The Benchmark: DRACO and Why OpenRouter Chose It

OpenRouter tested Fusion against DRACO, a benchmark built by Perplexity AI.

DRACO is designed to test deep research capability specifically – not factual recall, not reasoning puzzles. It covers 100 tasks across 10 domains:

• Academic research
• Finance
• Law
• Medicine
• Technology
• UX design
• General knowledge
• Needle-in-a-haystack retrieval
• Personalized assistance
• Product comparison

Each task is graded against roughly 39 weighted criteria, split into four categories: factual accuracy, breadth and depth of synthesis, presentation quality, and citation quality.

Some criteria carry negative weights. A verbose, confident-sounding answer that states something false gets penalized rather than rewarded for length. That detail matters, because it’s exactly the failure mode most single-model research tools fall into – sounding thorough without actually being accurate.

The Numbers Behind the OpenRouter Fusion API Results

Here’s where the benchmark results get specific.

Fable 5 fused with GPT-5.5 scored 69.0%, ahead of every individual model tested, including Fable 5 running solo at 65.3%.

A budget panel – Gemini 3 Flash, Kimi K2.6, and DeepSeek V4 Pro – scored 64.7% through the same pipeline. That’s within one percentage point of Fable 5 solo, at roughly half the cost.

Solo model scores ranged widely:

The most interesting result isn’t even about combining different models.

OpenRouter ran Claude Opus 4.8 paired with itself as a two-model panel, with Opus 4.8 also serving as judge. That configuration scored 65.5% – a 6.7-point jump over solo Opus 4.8.

Running the same prompt twice produces different reasoning paths, different tool calls, and different source selections. Which means a meaningful chunk of Fusion’s lift comes from the synthesis step itself, not purely from model diversity.

This kind of comparative testing across model families is the same approach we used when testing Kimi K2.6 against Claude Sonnet 4.6 on real developer tasks. Benchmark scores only tell part of the story until you see how models perform on work that resembles what you’ll actually ask of them.

It’s also worth reading alongside our coverage of Claude Fable 5’s own benchmarks and system card findings, since Fable 5 is the strongest solo model in OpenRouter’s own results table.

A Real Contamination Problem OpenRouter Had to Solve

One detail in OpenRouter’s writeup is worth flagging for anyone running their own evals.

When panel models were given web search, they started finding the DRACO grading rubric online during testing. Not through intentional gaming – search terms happened to surface pages discussing the benchmark itself.

OpenRouter fixed this by excluding the locations hosting the benchmark results from web search and web fetch. The same mechanism is available to anyone running evals through Fusion or any other tool-enabled pipeline:

• Pass excluded_domains to web_search
• Pass blocked_domains to web_fetch

Both keep a panel from finding pages related to your own test rubric.

This is a good reminder that contamination risk doesn’t only come from training data. A model with live web access can stumble into the same problem at inference time – a risk worth keeping in mind for any team building retrieval-heavy agents, something we got into in our breakdown of agent skills versus tools.

What This Means for Practitioners

If your stack depends on research quality over raw latency, Fusion is worth testing against whatever single-model setup you’re currently running.

A few practical starting points:

• Test it on your own task distribution first. DRACO is a strong proxy for deep research, but it evaluates text-only, English-only interactions, and your use case may differ.
• Try fusing a model with itself before paying for a multi-model panel. Since a chunk of the lift comes from synthesis rather than diversity, this is the cheapest way to see if Fusion helps your specific workload.
• Budget panels are worth a serious look if cost is a constraint. Landing within 1% of a frontier model’s score at half the cost changes the economics for high-volume research or support tooling.
• Apply domain exclusion if you’re running your own evals with web-enabled models. Contamination through live search is a real risk, not a theoretical one.

Teams already running multi-agent systems may find Fusion slots in naturally alongside existing orchestration work.

What to Watch Next

OpenRouter’s benchmark numbers depend partly on which model acts as judge.

The company used Gemini 3.1 Pro Preview rather than the original DRACO paper’s choice of Gemini 3 Pro, and noted that absolute scores can shift 10 to 25 points depending on judge choice – even though relative rankings hold steady.

Expect more scrutiny over judge model selection as fusion-style approaches become common across providers, along with more third-party benchmarking now that the API is publicly available.

Frequently Asked Questions

What is the OpenRouter Fusion API? The OpenRouter Fusion API sends a single prompt to multiple AI models in parallel, then uses a judge model to synthesize their responses into one final answer, within a single API call.

How do I call the OpenRouter Fusion API? Send a standard request with “model”: “openrouter/fusion”. To customize the panel of models and which model acts as judge, add a fusion plugin block specifying analysis_models.

Does Fusion cost more than calling a single model? It depends on panel size and model choice. OpenRouter’s testing found that a budget panel of three smaller models can match near-frontier performance at roughly half the cost of a frontier-model fusion configuration.

What benchmark did OpenRouter use to test Fusion? OpenRouter used DRACO, a 100-task deep research benchmark built by Perplexity AI that grades responses on factual accuracy, synthesis depth, presentation quality, and citation quality.

Can fusing a model with itself improve results? Yes. OpenRouter found that pairing Claude Opus 4.8 with itself as a two-model panel raised its score from 58.8% to 65.5% – evidence that the synthesis step itself contributes to the improvement, separate from model diversity.

Is Fusion available now? Yes. It can be called directly via the API with the openrouter/fusion model slug, or tested interactively in OpenRouter’s chatroom at openrouter.ai/fusion.