One header, one tool definition, no orchestration code#

The advisor tool inverts the shape most people expect. In the familiar sub-agent pattern a large orchestrator decomposes work and hands pieces to smaller workers. Anthropic’s framing of the advisor strategy is the reverse: “a smaller, more cost-effective model drives and escalates without decomposition, a worker pool, or orchestration logic” [3]. A lower-cost executor runs the loop. When it hits a decision that needs deeper judgment, it calls a stronger advisor for guidance, then keeps going. The claimed payoff, in Anthropic’s words: “You get close to advisor-solo quality while the bulk of token generation happens at executor-model rates” [2].

Turning it on is two lines. Send the beta header anthropic-beta: advisor-tool-2026-03-01, and add one entry to your tools array [2]:

1
{
2
  "type": "advisor_20260301",
3
  "name": "advisor",
4
  "model": "claude-opus-5"
5
}

The type must be exactly advisor_20260301 and the name must be exactly "advisor" [2]. That is the whole integration. There is no second request, no queue, no worker pool, and nothing for your code to coordinate.

Status, stated plainly. The advisor tool is in beta, not generally available. Anthropic’s API reference says “The advisor tool is in beta” [2]. The Claude Code surface goes further and calls it experimental, warning that “Behavior, pricing, and availability may change” [4]. It shipped on April 9, 2026 [3]. Build on it accordingly.

On platform availability, one honest note: Anthropic’s own two pages disagree. The API reference lists Claude Platform on AWS as supported while the Claude Code page lists it as unavailable, and both said so on the same day we checked [2][4]. Treat the Claude API as the surface you can count on, and check the page for your own deployment target rather than trusting either summary, ours included.

Three vendor levers on advisor cost, and a fourth that is yours#

Advisor output is “typically 400 to 700 text tokens, or 1,400 to 1,800 tokens total including thinking” [2]. That is the baseline you are managing, and Anthropic documents three ways to manage it plus one that lives in your own code.

Cap the advisor’s output. max_tokens on the tool definition is the only thing that bounds the advisor, with a floor of 1024 [2]. Anthropic’s recommended starting point is 2048, and its measurement is the number that circulated widely: at that cap “this reduced mean advisor output by roughly 7x compared with leaving the cap unset, with near-zero truncation and no detectable quality degradation” [2]. That result came from 40 runs per configuration on a hard reasoning benchmark, and Anthropic scopes it explicitly. The uncapped output in that test ran 4,200 to 5,900 tokens, far above the typical 1,400 to 1,800, and Anthropic’s instruction is to “use this table to size the savings ratio, not as a universal baseline” [2]. Dropping to the 1024 floor cuts roughly 10x but truncates about 10% of calls [2].

Ask for brevity in the user message. The tested line is (Advisor: please keep your guidance under 80 words ...) [2]. It is a soft constraint rather than a hard cap, so ask for roughly 80% of your true ceiling. Anthropic notes something counter-intuitive here: that line also raised the consult rate, and net cost still fell, since you get more consultations that are each shorter [2].

Enable advisor-side caching, but only past a threshold. The caching parameter takes {"type": "ephemeral", "ttl": "5m" or "1h"} and defaults to off [2]. Anthropic’s guidance is to turn it on when you expect three or more advisor calls in a conversation, since without it each call re-reads the full transcript with no reuse [2]. Note the shape: “Unlike cache_control on content blocks, this is not a breakpoint marker. It is an on/off switch. The server determines where cache boundaries go” [2].

The fourth control is yours. max_uses caps advisor calls per request, not per conversation [2]. For a conversation-level budget you count the calls yourself and remove the advisor tool from tools when you hit your cap, and you do not need to strip the historical advisor_tool_result blocks to do it [2].

Figure 4 - The 7x, with its scope attached: Anthropic measured roughly a 7x reduction in mean advisor output from a 2048-token cap, at 40 runs per configuration, on a hard reasoning benchmark whose uncapped output ran 4,200 to 5,900 tokens [2]. Typical workloads sit at 1,400 to 1,800 tokens, where the same cap has far less to cut. Anthropic’s own instruction is to use the ratio for sizing, not as a universal baseline [2].

What Anthropic measured, and on which models#

Two separate measurement passes exist, four months apart, on different model generations. Mixing them is the fastest way to publish a wrong number.

The April 2026 launch figures were measured with an Opus 4.6 advisor [3]. On SWE-bench Multilingual with a Sonnet 4.6 executor, the pairing gained 2.7 percentage points over Sonnet alone while cost per agentic task fell 11.9%, across five trials of 300 problems in nine languages [3]. On BrowseComp with a Haiku 4.5 executor, the pairing scored 41.2% against 19.7% solo, which Anthropic describes as “more than double”, trailing Sonnet solo by 29% in score while costing “85% less per task”, over 1,266 problems at one attempt each [3].

Those are the numbers that get quoted. They were measured on Sonnet 4.6, Haiku 4.5, and an Opus 4.6 advisor, and both the capability gap and the price ratio have moved since. There is no published equivalent on the current generation, so do not interpolate one.

The August 2026 figures were measured on current models, and they are much less flattering [1]. On an internal agentic-coding benchmark of 370 repository tasks, an Opus 5 executor with a Fable 5 advisor was the most accurate configuration measured at 85.7% for $8.40 per attempt. The single-model baselines were Opus alone at its default effort scoring 84.4% for $8.50, and Fable alone at medium effort scoring 83.4% for $8.20 [1]. Anthropic’s own verdict on that spread: “which a single run does not separate from noise” [1]. One run per configuration, and the vendor says so.

Where the advisor did clearly earn its keep, the executor was weaker and the gap was real. On Chartography, an Opus 5 executor at low effort with a Fable 5 advisor scored 67.5 for $0.60 per task, above the line drawn through either model’s own effort curve, though the executor’s own medium and default settings still held the top scores at 1.6 and 3.3 times the price [1]. Across the charted pairings, “the advisor closed 50% to 90% of the gap to the stronger model” [1].

Anthropic states the governing variable directly. On GPQA Diamond, a Haiku 4.5 executor “gained a great deal” from an Opus 5 advisor, a Sonnet 5 executor “gained a few points”, and a frontier executor gained “almost nothing” [1]. The advisor can only hand over capability the executor lacks.

Two scope notes belong here before anyone builds a slide out of these. The SWE-bench Pro results referenced on that page are a 482-problem Anthropic-internal subset whose “scores are not comparable to the public leaderboard”, by Anthropic’s own statement [1]. On latency, the only published datum is “about two extra frontier-model calls per task on this benchmark, each on the task’s critical path”, with the advisor sub-inference not streaming [1]. There is no p50 or p99 figure anywhere, so do not quote one.

Figure 5 - Same feature, two generations, opposite conclusions: The April launch pairing lifted a Haiku 4.5 executor from 19.7% to 41.2% on BrowseComp with an Opus 4.6 advisor [3]. The August pairing at the top of the range put Opus 5 with a Fable 5 advisor at 85.7% for $8.40 against Fable alone at medium scoring 83.4% for $8.20, which Anthropic itself calls indistinguishable from noise on a single run [1]. The difference is the size of the capability gap, not the quality of the feature.

KEY INSIGHT: An advisor result without its executor model, its advisor model, its benchmark, and its run count attached is not a result. The same feature delivered “more than double” on one pairing and a difference inside noise on another, and the only thing that changed was how much capability the executor was missing.

The ladder you climb before you get here#

In August 2026 Anthropic published a page of measured cost levers for agent workloads, each with its number attached [1]. Numbering them as a ladder is ours, and we make one deliberate change to Anthropic’s section order: Anthropic discusses model choice before effort, and we put the effort sweep first because Anthropic’s own decision shortcut does, telling you to “Sweep effort on your current model first” because “most workloads end there” [1]. The ordering is the useful part, since it is close to the inverse of the order teams actually reach for them. Nobody’s first instinct is prompt caching. Everybody’s first instinct is to swap the model or build a router, and those sit at rungs 8 and 9.

Rung 1 is the one to sit with. Anthropic’s reasoning: “Turn on prompt caching before any other lever, because every turn of an agentic task resends the entire growing conversation … A 40-turn task sends its first turn 40 times, so task cost grows with roughly the square of turn count” [1][5]. The measured hit rates were 81% to 90%, and the summary line is blunt: “cache reads are routinely the largest single component of task cost, making caching worth more than most model-choice decisions” [1]. That quadratic resend is the same mechanism we walked from the context side in The Context Engineering Stack [6], where the growing transcript is the thing every other decision gets priced against.

We want to be careful about a claim we cannot support. We have no data on how many teams are running with caching off, and Anthropic publishes none either. What we can say is that Anthropic chose to open a cost-optimization page with an instruction to turn it on, which is at least suggestive of what its support conversations look like.

Rung 2 has the most quotable number on the page. Anthropic’s pasted-versus-uploaded row works out to 12 times the cost for a quarter of the accuracy, from a decision most teams make without noticing they made it [1]. Its compressed rule for answer length is worth writing on a wall: “Ask for the answer you will read, not the one that looks thorough” [1].

Rung 5 is where Anthropic says most workloads should stop. Long-horizon coding behaves differently from the four research and knowledge-work benchmarks in that row, with Opus 5 on SWE-bench Pro giving up about 2 points at medium for half the cost and about 8 points at low for a quarter [1]. You cannot tell which shape your workload has from its description, which is the entire argument for sweeping rather than guessing.

Figure 6 - Anthropic’s levers, numbered, in roughly the inverse of everyone’s instinct: Free levers occupy the first four rungs. The first real tradeoff appears at rung 5, where Anthropic notes that “most workloads end there” [1]. Multi-model architecture, the rung this article is nominally about, is ninth and carries a warning rather than a number.

The consult rate, which is the whole ballgame#

Every escalate-on-demand design has one number that decides whether it works: how often the cheap tier actually asks for help. Anthropic measured it directly and calls it “the fragile one” [1].

Here is the full sentence, since the second half of it is the part nobody repeats: “The second, and the fragile one, is whether the executor actually asks (the consult rate). An executor at low effort can stop detecting that it is stuck: a pairing that consults on most tasks at the default effort can fall to consulting on almost none when effort is lowered, and then scores below the executor alone” [1].

Below the executor alone, which is worse than not doing it at all: you added latency and a second model and got nothing back.

The measurement that makes the point uses one configuration on two benchmarks. On DeepSWE, a low-effort Sonnet 5 executor “kept asking and gained 23 points” [1]. On SWE-bench Pro, “the same executor stopped” asking [1]. Same executor, same advisor, same effort setting, a 23-point gain on one and nothing on the other, decided entirely by the task distribution. Where the pattern worked on Chartography, the rate was high and Anthropic names it: “The low-effort executor consulted the advisor on 86% of tasks, the condition the SWE-bench Pro pairing failed to meet” [1].

You cannot read which case you are in off a task description. That is why this is a production metric rather than a benchmark footnote.

Figure 7 - One configuration, two task distributions, +23 points then nothing: A low-effort Sonnet 5 executor kept consulting on DeepSWE and gained 23 points. The same executor stopped consulting on SWE-bench Pro, where Anthropic publishes no score for the pairing [1]. When the consult rate collapses, the pairing scores below the executor running alone, which is the failure mode the mechanism explainers leave out.

Anthropic’s compressed operating rule is three verbs: “So watch the consult rate: prompt for it, measure it, and restore the executor’s effort if it collapses” [1].

Prompt for it. The built-in tool description under-calls, “especially on coding work”, so Anthropic publishes a system-prompt block targeting “around two to three calls for each task” [1][2].

Measure it. Count server_tool_use blocks with name: "advisor" per task and put the rate on the same dashboard as cost per task and pass rate. This is a log-shaped problem, and which system holds those logs turns out to matter more than it looks, a point we made at length in The Log Is the Agent [7].

Restore effort if it collapses. Lowering the executor’s effort is precisely what causes the collapse. Cheapening the executor can silently switch off the escalation you are paying for, which is a genuinely unpleasant failure, since the bill goes down and the quality goes down with it.

Four places to put the routing decision#

Once you see the consult rate as the fragile part, the field of related products stops looking like a product roundup and starts looking like a design space with one axis: when is the routing decision made? Four documented positions exist, and each one trades away a different thing.

Before generation. Cursor Router picks one model for the whole request using Compass, a trained complexity predictor that scores each turn between 0 and 1 against a threshold [9][10]. The reusable idea is what it trains on: “Compass estimates the complexity of each turn by predicting whether the user will be satisfied with Cursor’s response” [10]. Complexity is learned from what the developer does next rather than from a labeled rubric. Cursor reports that “Turns that Compass rated as most likely to succeed received a positive performance signal 96% of the time, while turns it rated as least likely to succeed received one 71% of the time” [10]. The classifier was trained on more than 600,000 live requests and validated with online A/B tests across production traffic rather than offline evals [9].

Cursor reports its payoff in cost per finished commit, which is the right unit: $4.63 in Balance mode and $6.76 in Intelligence mode, against $7.34 for unrouted Opus 4.8 and $12.69 for unrouted Fable 5 [9]. Its August update reports Intelligence running at 68% lower cost than the top model and Balance at 41% lower cost than Opus 4.8, with satisfaction up 3% [10]. Every one of those is Cursor measuring Cursor’s own traffic, and Cursor Router is available on Teams and Enterprise plans only, on by default for Teams when Auto is selected and off by default for Enterprise [11]. It is not something a small team switches on.

The tradeoff of deciding first: the router never sees any of the work before committing to a model.

During generation. The advisor tool. The executor decides mid-turn, having seen its own progress, which is the elegant part and also the fragile part, since it is the executor’s self-assessment doing the deciding [2].

After generation. NVIDIA’s NeMo Switchyard ships an escalation router that inverts the timing: route to the weak tier first, buffer the reply, hand the completed turn to a judge model, and escalate to the strong tier only if the judge says the weak model failed [12][13]. Reading the source rather than the blog surfaces the parts that decide the economics: a confirmations latch defaulting to 2 consecutive escalate verdicts before latching to the strong tier, and fail-open behavior where a judge timeout or unparseable verdict serves the buffered weak reply and holds the streak rather than resetting it [13]. The judge is not free, so an unlatched non-escalating turn still costs a weak call plus a judge call.

At the completion claim. Switchyard’s newest router, advisor_gate, occupies a fourth position that did not exist a month ago. Every turn that makes tool calls passes through unreviewed. The first terminal turn, the one where the executor stops calling tools and claims it is finished, gets buffered and shown to a stronger advisor with the full transcript. APPROVE releases the turn unchanged, and REDO appends the discarded text plus the advisor’s plan as feedback and re-invokes the executor [13]. Its default advisor output cap is 2048 tokens, the same number Anthropic recommends for the advisor tool, arrived at independently [2][13].

Switchyard is worth reading and is not worth deploying. Its README says “Experimental software. Not for production use.” [13]. Its blog also describes a prefill router reading residual-stream signals that we confirmed is still absent from the shipped routing algorithms [12][13]. Treat it as the readable open-source counterpart to a closed feature, which is genuinely valuable, rather than as a tool you adopt.

Figure 9 - One axis, four answers: Deciding before generation is cheap and blind. Deciding during generation is informed and depends on the cheap model’s self-assessment. Deciding after generation is informed and pays for a judge on every turn. Deciding at the completion claim reviews only the turn where a mistake becomes final [2][10][12][13].

The axis explains the failure modes better than any product comparison does. Position 1 cannot see the work. Position 2 depends on the executor knowing it is stuck, which is the thing that degrades when you cheapen the executor. Positions 3 and 4 escalate on an external judgment rather than self-assessment, which removes the consult-rate problem and replaces it with a judge you have to pay for and evaluate.

Two vendors measured the same question and disagreed#

Here is the part we found genuinely surprising, and as far as we can tell it has not been written up anywhere.

Anthropic’s suggested advisor system prompt tells the executor to consult early: “Call advisor BEFORE substantive work, before writing, before committing to an interpretation, before building on an assumption” [1][2].

Switchyard’s advisor gate does the exact opposite, deliberately, and states a measurement as the reason in a source comment: “Front-loading advice was measured to suppress the executor’s own test-and-iterate loop, so no advice is injected up front” [13]. Its gate waits until the executor first claims to be done.

Two vendors, both claiming measurement, reaching opposite conclusions about early advice, and neither published the data behind their claim. We are not going to pick a side, and we would be suspicious of anyone who does. Both positions are plausible and they are plausible for different workloads: front-loaded advice plainly helps when the failure mode is committing to a wrong interpretation early, and plainly hurts when the executor would have found the answer by running its own tests. That is a hypothesis to run on your own traffic, not a settled practice, and it is cheap to test, since the intervention is a system-prompt line.

Figure 10 - An open question presented by both sides as settled: Anthropic’s suggested prompt front-loads advice deliberately [1]. Switchyard’s advisor gate refuses to, citing a measurement [13]. Neither published the underlying data, which makes this a test to run rather than a practice to adopt.

The version with no beta header#

If none of the above clears your risk bar, three shipped, documented, non-beta versions of the same lever are already sitting in Claude Code, and Anthropic’s own comparison table lines all four up by when the stronger model runs [4].

/model switches the stronger model on for all subsequent turns. opusplan runs the stronger model during plan mode only, then drops back for execution [14]. A subagent with model set runs the stronger model for the whole delegated subtask, where the field accepts sonnet, opus, haiku, fable, a full model ID, or inherit, which is the default [15]. The advisor tool is the fourth entry in that table, the one that escalates mid-turn.

The advisor surface in Claude Code is the /advisor command, the advisorModel setting, or the --advisor flag [4]. Two operational details are easy to trip over. It requires feature-flag fetching, so setting DISABLE_TELEMETRY silently disables it, and CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1 turns it off outright [4]. Subagents inherit the configured advisor and apply the same pairing check against their own model, and toggling the advisor mid-session does not invalidate the main model’s prompt cache [4].

That last detail is a small kindness. Given that rung 1 of the ladder is caching, a feature that quietly broke your prompt cache every time you toggled it would cost more than it saved.

Figure 11 - The same lever at four granularities: Claude Code’s own table places /model, opusplan, subagent model, and the advisor tool side by side by when the stronger model runs [4]. Three of the four are documented, shipped, and need no beta header, and one of them is a line of subagent frontmatter [14][15].

What we would actually do on your traffic#

Anthropic published its measurement method alongside its numbers, and it is a better consulting protocol than most consulting protocols. All four steps are quoted [1].

1. “Pull a few tasks from production logs, weighted like real traffic, and write outcome checks for each: tests pass, ticket closed, row count correct. Record cost per task beside the score.”
2. “Baseline the model tiers across effort levels, not only the default, and plot score against spend. A multi-model configuration must beat the single model’s whole curve.”
3. “If the curve shows a gap effort can’t close, add the multi-model strategy that fits and re-run the suite.”
4. “Run the winner in shadow on a traffic slice before cutover, then keep the suite running.”

Step 2 is where most engagements should end, and step 4 is the one that gets skipped. Shadow-running a routing change against live traffic before cutover is an infrastructure problem more than a model problem, and it is the same discipline we walked through in Scaling Agents to Production [16].

One instrumentation note sits above all of this. Anthropic’s own guidance is to price the tail rather than the median: “compare models on the hardest tenth of your tasks, not the typical one”, since “a failed task still bills its tokens, then the retry, then whatever the failure costs downstream” [1]. On a 20-problem WideSearch run, two problems carried 43% of the spend [1]. Median-task benchmarking makes the cheapest model look best every time, and the bill is decided somewhere else entirely.

That is the shape of the audit we run: work the ladder in roughly Anthropic’s published order, measure cost per completed task on your own traffic weighted the way your traffic actually is, and stop at the first rung that clears your bar. Most workloads stop before the architecture change, and telling a client that is worth more than selling them rung 9.

If you are already running an advisor pairing, the single highest-value instrument to install is the consult rate. It is the number almost nobody is measuring, and without it there is no way to tell “the advisor is not helping on this workload” from “the advisor is never being called”. Those two problems look identical on a cost dashboard and have completely different fixes.

Conclusion#

The advisor tool is real, it is documented down to the error codes, and the mechanism deserves the attention it got. One beta header and one tool definition remove an entire category of orchestration code.

What the coverage of it left out is that Anthropic itself ranks the feature last among cost levers, warns that a multi-model configuration in its own measurements cost more than the same model at lower effort, and shows the top-of-range pairing sitting inside noise against a single frontier model [1]. Those are not reasons to ignore the feature. They are the conditions under which it pays: a real capability gap between executor and advisor, a task distribution where the executor keeps asking, and a baseline you actually measured rather than assumed.

The consult rate is the number that decides it, and it is the number that will be missing from any pairing you inherit. A 23-point gain on one benchmark and a collapsed consult rate on another, from one configuration, is not a benchmarking curiosity, it is a warning that this lever can quietly go negative. Instrument it first, prompt for it, and treat a drop in it as an incident rather than a saving.

The wider lesson is the axis rather than the product. Routing decisions can be made before generation, during it, after it, or at the moment the model claims to be finished, and each position buys information at a different price. Deciding early is cheap and blind. Deciding late is informed and costs a judge. Deciding mid-generation is the only one of the four that depends on a cheap model correctly assessing itself, which is worth remembering the next time someone proposes lowering the executor’s effort to save a little more.

References#

[1] “Optimizing for cost and intelligence,” Anthropic Claude Platform Documentation, 2026. https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligence

[2] “Advisor tool,” Anthropic Claude Platform Documentation, 2026. https://platform.claude.com/docs/en/agents-and-tools/tool-use/advisor-tool

[3] Anthropic, “The advisor strategy: Give agents an intelligence boost,” Anthropic, Apr 2026. https://claude.com/blog/the-advisor-strategy

[4] “Escalate hard decisions with the advisor tool,” Claude Code Documentation, 2026. https://code.claude.com/docs/en/advisor

[5] “Prompt caching,” Anthropic Claude Platform Documentation, 2026. https://platform.claude.com/docs/en/build-with-claude/prompt-caching

[6] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The Context Engineering Stack: Compression, Retrieval, and Decision Memory,” 2026. /insights/ai-16-context-engineering-stack/

[7] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The Log Is the Agent: Why Whoever Hosts It Owns What You Built,” 2026. /insights/ai-24-log-is-the-agent/

[8] Hyperautomation Labs, “The Advisor Tool: Make a Cheap AI Model Think Like Opus (Anthropic Advisor Tool),” YouTube, Jul 2026. https://www.youtube.com/watch?v=Xi5dkriokHk

[9] Cursor, “Introducing Cursor Router,” Cursor, Jul 2026. https://cursor.com/blog/router

[10] Cursor, “How Cursor Router chooses the right model for the task,” Cursor, Aug 2026. https://cursor.com/blog/how-cursor-router-works

[11] “Cursor Router,” Cursor Docs, 2026. https://cursor.com/docs/cursor-router

[12] T. Varshney, C. Alexiuk, A. Agarwal, A. Surla, and M. Chung, “Route AI agent workloads across models with NVIDIA NeMo Switchyard,” NVIDIA Technical Blog, Aug 2026. https://developer.nvidia.com/blog/route-ai-agent-workloads-across-models-with-nvidia-nemo-switchyard/

[13] NVIDIA, “NVIDIA-NeMo/Switchyard,” GitHub, Apache-2.0, 2026. https://github.com/NVIDIA-NeMo/Switchyard

[14] “Model configuration,” Claude Code Documentation, 2026. https://code.claude.com/docs/en/model-config

[15] “Subagents,” Claude Code Documentation, 2026. https://code.claude.com/docs/en/sub-agents

[16] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Scaling Agents to Production: Four Infrastructure Patterns, and Why the Second Agent Is the Hard One,” 2026. /insights/ai-23-scaling-agents-to-production/