AI
Claude Code Advisor Tool: A Second Model at Key Moments
August 202612 min read
A server tool that lets Claude consult a second, typically stronger model at key moments during a task — before committing to an approach, when an error keeps recurring, or before declaring a task complete. The advisor receives the full conversation including tool calls and results, and returns guidance Claude applies before continuing.
Three ways: the advisor command sets it mid-session and saves it as your default, an advisor model settings key configures a persistent default, and a launch flag sets it for one session only. It requires a main model that supports the advisor, and it exits at launch if the pairing or your organisation's allowed models reject the choice.
The advisor must be at least as capable as the main model. A Sonnet main accepts Opus, Fable or Sonnet 5; an Opus 4.7 or later main accepts Fable or another Opus of that generation; a Fable main accepts only Fable. If the advisor is weaker it is simply not attached, and the command tells you.
Usually less. Each call has the advisor read the conversation and consumes tokens at its rates, but Claude calls it at decision points rather than every turn, so pairing a faster main model with a stronger advisor typically costs less than running the stronger model throughout. Advisor usage appears in your session totals.
Two requirements produce silence rather than an error. The advisor needs the Anthropic API, so it is unavailable on Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform and Microsoft Foundry. It is also enabled through a feature flag, so a session that disables feature-flag fetching leaves the advisor off.
Key Takeaway
The advisor tool pairs your main model with a second, typically stronger one that Claude consults at key moments — before committing to an approach, when an error keeps recurring, before declaring a task done. The advisor receives the full conversation including every tool call and result, and returns guidance Claude applies before continuing. It runs server-side and requires the Anthropic API.
I have watched a Sonnet session pick a plausible but wrong approach to a migration, execute it competently for twenty minutes, and only discover the problem at the point where the tests would not pass. Nothing about the execution was bad. The decision at minute two was, and there was no moment in that hour where a stronger model was asked to look at it.
That gap is what the advisor closes. This post covers what it is, the three ways to enable it, the pairing rules that decide which advisor a given main model accepts, what you see when a consultation happens, what it costs and why it is usually cheaper than upgrading the main model, its unusual prompt-cache behaviour, and how it compares with the other ways to get a second opinion.
The advisor is a server tool that runs on Anthropic's infrastructure, available to both subscription and API-billed accounts. You choose which model acts as the advisor; Claude decides when to call it. That division is the whole design — you are not configuring a second reviewer to run on a schedule, you are giving the model somewhere to escalate to.
It fits long, multi-step tasks where most turns are routine but plan quality decides the outcome: large refactors, debugging where the same error keeps returning, work you want independently checked before it is called done. It adds little on short tasks with nothing to plan, and on work where every turn needs the strongest model you should simply switch models instead.
A command sets it mid-session and saves it as your default, a settings key configures a persistent default without opening a session, and a launch flag sets it for one session only. Each enables the advisor for sessions whose main model supports it, and a notification tells you it is on once the session starts.
/advisor # picker of available advisor models
/advisor opus # set directly; saved as your default
/advisor off # clear it
{ "advisorModel": "opus" } # persistent default in settings
claude --advisor opus # one session only
# Aliases resolve to Claude Code's built-in default for that
# family and advance with releases. A full model ID works too.
# It EXITS at launch if the main model does not support an
# advisor, if the requested model cannot act as one, or if your
# organisation's allowed-models list excludes it. A background
# session starts WITHOUT the advisor instead of exiting.
CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1
# the command becomes unavailable, a configured advisorModel is
# ignored, and --advisor is accepted but does nothingTwo requirements catch people out. The advisor needs the Anthropic API — it is not available on Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform or Microsoft Foundry, and through a gateway it depends on whether the request is forwarded intact. And it is turned on through a feature flag Claude Code fetches, so in a session where a variable that disables flag fetching is set, the advisor silently stays off.
The advisor must be at least as capable as the main model, and the check happens before a request is sent. If the advisor is weaker, it is simply not attached and both the command output and a notification tell you so — subagents whose own model satisfies the pairing may still use it. The specific combinations matter more than the rule.
Pairings worth knowing:
| Pairing | When to use it |
|---|---|
| Sonnet main, Opus advisor | The default recommendation. Sonnet handles routine work and escalates planning, ambiguous failures and completion checks |
| Haiku main, Opus advisor | The lowest-cost main model with strong planning. More expensive than Haiku alone, cheaper than moving the main model up |
| Opus main, Opus advisor | A second Opus reviews the first. For high-stakes work where an independent check matters more than cost |
| Fable, either side | Fable is a higher tier, so a Fable main accepts only a Fable advisor. On some plans a Fable advisor also needs the one-time usage-credits consent first |
Claude decides the timing, and the transcript shows it happening. The behaviour after the guidance returns is the part worth reading carefully, because it is more sensible than a simple do-what-the-advisor-says rule would be.
# In the transcript, while the call is in flight:
Advising · opus
# When it returns, one of two things:
# reviewed -> Ctrl+O expands the advisor's full guidance
# declined -> "Advisor declined to advise on this request",
# with the reason behind Ctrl+O if it gave one
# Claude generally follows the guidance, but adapts when its own
# evidence contradicts it: if a recommended step fails when tried,
# or the file contents say otherwise, it surfaces the conflict
# rather than following the advice unconditionally.
# You can ask for a consultation like any other tool:
# "consult the advisor before you continue"
# There is no setting to cap or force calls — say it in the
# instructions instead.There is no setting to cap or force advisor calls, which surprises people looking for a knob. The lever is your instructions: asking Claude to consult the advisor before it continues works exactly like requesting any other tool, and telling it to consult more or less often during a task works too. If you want a guaranteed consultation at a specific point, say so in the prompt.
Each call has the advisor model read the conversation, so it consumes tokens at that model's rates on top of your main model's usage. With API billing you pay the advisor's input and output rates; on a subscription, advisor usage counts toward your plan's limits, with a Fable advisor billing to usage credits on plans where Fable usage does.
The economics work because Claude calls it at decision points rather than every turn. Pairing a faster main model with a stronger advisor typically costs less than running the stronger model throughout — which is the entire argument for the feature, and worth testing on your own workload rather than taking on faith. Advisor usage shows up in the session totals.
Toggling the advisor mid-session does not invalidate your main model's prompt cache. That is genuinely different from changing model or effort level, both of which do, and it means you can turn the advisor on partway through a long conversation without paying to reprocess the history. The advisor's returned guidance is then cached as part of the transcript on later turns.
The advisor's own read is not cached. Each call processes the full transcript anew, with no reuse between calls — so the cost of a consultation grows with the conversation, the same way any uncached read does. That is another argument for a stronger advisor on a shorter task rather than on a session that has been running all afternoon.
Four mechanisms combine model strengths, and they differ in when the stronger model runs rather than in what it can do:
Try it on the shape of task it was built for: a long refactor or a debugging session where the plan matters more than the typing. Watch the verdicts rather than the output — the advisor's guidance under the expand key tells you whether the escalation is earning its cost. And if it is not available at all, check the two requirements before anything else, because a disabled feature flag and a cloud provider both produce silence rather than an error.
Sources & further reading