Insights·2026-07-04

What Is the Advisor Strategy, and How Does It Differ from opusplan

The Advisor Strategy hands execution to a low-cost model and calls in a stronger model on demand only when judgment stalls. Claude Code CLI's opusplan applies the same idea but fixes the handoff at the plan-to-execution boundary, with no loop that lets the stronger model step back in and re-check mid-execution.

What Is the Advisor Strategy

The Advisor Strategy is a structure Anthropic announced officially. Execution is handled by a low-cost model such as Sonnet or Haiku, and that model calls Opus via API, on demand, only at the moment it judges itself stuck. Opus is not standing by at all times -- it appears only when summoned.

The analogy is an organization. An intern handles the day-to-day work and asks a manager only when genuinely stuck. The manager is not seated at the desk the whole time -- they step in, read the situation, and advise only when called.

Structurally, the executor and the advisor share the same context -- conversation history and tool history. Advice the advisor gives is written back into that shared context, and the executor reads it before its next move. Because everything happens inside a single API call, the whole loop stays simple to manage, and the advisor's tokens are reported separately, so cost tracking stays split too.

Why This Announcement Matters Now

The cost gap is real. Opus costs 25 dollars per million output tokens; Haiku costs 5 dollars -- a fivefold difference. Running a service that handles thousands of requests a day entirely on Opus carries a real cost burden.

But running everything on the cheapest model alone hurts performance. The point of this strategy is finding the spot that lowers cost while holding performance, or improves both at once.

What Does the Benchmark Show

These are results Anthropic itself published on April 9, 2026, in the official blog post "The advisor strategy: Give Sonnet an intelligence boost with Opus." In that launch, the executor models were Sonnet 4.6 and Haiku 4.5, and the advisor was Opus 4.6.

On the SWE-bench Multilingual benchmark, adding an Opus advisor to Sonnet raised performance by 2.7 percentage points over Sonnet alone, while cutting cost per agentic task by 11.9 percent. Performance rose while cost fell.

On BrowseComp, Haiku alone scored 19.7 percent; adding an Opus advisor more than doubled that to 41.2 percent. That pairing trails Sonnet alone by 29 percentage points in score, but costs 85 percent less per task. The table below summarizes Anthropic's published figures.

BenchmarkConfigurationPerformance changeCost change
SWE-bench MultilingualSonnet alone -> Sonnet + Opus advisor+2.7pp-11.9%
BrowseCompHaiku alone -> Haiku + Opus advisor19.7% -> 41.2%-
BrowseCompHaiku + advisor vs Sonnet alone-29pp-85%

Comparing Four Strategies

The practical choices break down into four: running Opus alone from start to finish, the Advisor Strategy just described, opusplan on Claude Code CLI, and leaving a low-cost executor alone without an advisor.

What actually separates the four isn't model tier -- it's who holds the wheel on judgment, and whether re-verification happens mid-execution.

StrategyWho drives judgmentWhen the stronger model steps inRe-check mid-executionBest fit
Opus aloneOpusAlwaysNot needed (already top tier)Ambiguous, complex, one-off judgment
Advisor StrategyExecutor modelOn demand, only when stuckYes, every callRepeated work at scale, improving cost and performance together
opusplan (CLI)Plan = Opus / Execution = SonnetOnce, at planningNoWork where a precise plan is enough
Executor aloneExecutor modelNeverNoSimple tasks; risk of runaway trial-and-error once complexity rises

How Is opusplan Different from the Advisor Strategy

The way to apply the same idea inside Claude Code CLI is /model opusplan. In plan mode, Opus handles the design; once execution mode starts, Sonnet automatically takes over.

The decisive difference is this: with the Advisor Strategy, Opus can be called back in at any point execution stalls, and each call has the advisor re-review the executor's work. With opusplan, Opus steps in once at the planning stage and does not look again until execution finishes. The re-verification loop is structurally absent.

So opusplan is enough when the plan is already tight and the risk of drifting off course during execution is low. When judgment keeps swinging mid-execution, that gap stays as real risk.

How Should You Choose in Practice

Two questions decide it: is the task within what a low-cost model can actually handle, and is it a one-off or a long multi-step job that accumulates work.

If ambiguous, complex judgment keeps coming up, it's safer to let Opus hold the wheel the whole way. If the task is well-defined labor at scale over a long run, the Advisor Strategy can cut cost substantially. If all that's needed is one precise plan, opusplan is enough.

What to avoid is leaving a low-cost executor alone on a complex task with no advisor. It doesn't know when to stop on its own, trial and error can spiral, and the paradox is that total cost can end up higher than running Opus alone.

What This Means from an AX Perspective

This structure isn't really new technology -- it's a familiar organizational design. A practitioner asks a superior when stuck, and the superior isn't standing by at all times, stepping in only when called. It's the same delegation structure organizations have used for decades, moved into an AI pipeline.

What's different is that the boundary of that delegation, and the rule for when to call, can now be written into code. How many times it can be called, under what condition, and how to track the cost of each call -- all of it becomes a configurable setting.

For any organization evaluating AI adoption, the question should shift from 'which model do we use' to 'where do we place this judgment.' Role design, more than model choice, is what now decides cost and quality together.