The most useful thing I can tell you about Claude Code's /advisor command is what it is not: it is not a way to ask a smarter model questions. You never talk to the advisor. Your executing model does, on its own judgment, at the moments it decides it might be wrong. That inversion — the model auditing itself with a second brain — is the whole feature, and it is why my opinion of it swung from skeptical to convinced over one weekend of deliberately trying to break it.
My test bed was real: a Laravel 11 billing service I had been refactoring for weeks, full of the edge cases that expose AI coding models — prorated upgrades, mid-cycle downgrades, dunning logic that has to survive partial Stripe webhook failures. The advisor caught two issues I had personally stared at for three days: a logic flaw in the proration window and a timezone bug in the renewal calculation. Sonnet was executing; when it hit a stall pattern, it consulted Opus through the advisor and came back with an analysis that read like a senior engineer's review.
Here is how the feature actually behaves, which configuration wins, and where I still reach for subagents instead.
What /advisor Actually Does
Run /advisor inside Claude Code and pick a model from the list. From then on, your primary model can invoke that secondary model when it judges it needs a second opinion. There is also a persistent advisorModel field in settings.json if you want the pairing configured rather than chosen per session. Anthropic has since written this up as the "advisor strategy," and their own measurement is worth quoting because it matches my experience directionally: pairing a cheaper executor with a stronger advisor cut cost about 12 percent while slightly improving SWE-bench accuracy versus running the cheap model alone.
Three mechanics matter more than anything in the announcement copy:
The advisor sees the full transcript. Your request, every tool call, every file read, every failed attempt — the advisor receives all of it. No filtering, no summary. This is its strength and, as we will get to, its structural weakness.
The advisor cannot touch the world. No file system, no shell, no web, no MCP servers. It reasons over the conversation and returns guidance. Hard boundary, not a permission.
The advice persists in shared context. Later advisor calls see earlier advice, and if empirical results contradict a recommendation, Claude Code surfaces the conflict rather than silently overriding it. That third behavior is the one that changed my mind — it turns the advisor from an oracle into a participant whose claims get checked.
When the Advisor Actually Fires
The docs are thin on triggers, so I ran controlled scenarios and watched. Four patterns reliably invoke it:
- Before substantive work — about to write a significant chunk of code or make an interpretive leap from requirements to implementation, the model sanity-checks first. Trivial edits skip this.
- At the perceived finish line — a completion check before declaring success. This one caught a missing proration edge case my executor had convinced itself was resolved.
- Recurring errors — same fix attempted, same tests failing, approaches oscillating. The loop-breaker. This is the trigger that pays the rent, because non-converging loops are precisely where solo models burn afternoons.
- Multi-step checkpoints — tasks with a to-do list get at least a before-commit and an at-completion consultation.
The design tension to be honest about: the decision to consult the advisor lives inside the model whose judgment you are auditing. An overconfident executor will not call for help at exactly the moments it should. You can nudge it — "consult the advisor before committing" measurably raises the call rate — but you cannot force a call, and you should watch for the opposite failure too: advisor loops, where repeated consultations produce drifting advice and shrinking conviction. When you see that, step in. The metacognitive layer supplements human judgment; it does not replace it.
The Pairing That Wins
I ran the same billing refactor under three configurations. The results were lopsided enough to give a clear recommendation.
Cheaper executor, stronger advisor (Sonnet main, Opus advising). The intended design, and the clear winner. The executor is fast and inexpensive for the majority of turns; the premium model enters only at the moments that matter. My weekend session ran about 42 executor turns with 6 advisor calls, and came out cheaper than running the premium model throughout — with comparable output quality, because every decision that mattered had the stronger model in the loop. Anthropic's published numbers tell the same story.
Stronger executor, cheaper advisor. Tested out of curiosity; do not bother. When the strong model is stuck, the weaker advisor either agrees or offers surface suggestions the executor already discarded. It is a junior engineer code-reviewing a senior's architecture.
Same model as both. Less useless than it sounds — the forced reflective pause helps even without fresh cognition — but you lose the different-angle effect that makes the feature work. It beat an unchaperoned run on my recurring-error test, and lost to the mixed pairing everywhere.
The general rule survives model generations, which matters because the lineup keeps moving: pair your everyday executor one tier down from the best model you can afford, and put the best model in the advisor seat. The specific names will change; the shape will not. For picking the executor tier itself, my Sonnet-versus-Opus decision framework covers that math, and the Opus 5 benchmark breakdown covers the current top of the range.
One Real Advisor Call, Step by Step
The cleanest sequence from my billing test, because the abstract description undersells the experience:
My executor proposed a fix for an off-by-one in prorated-days calculation. Fourteen of sixteen tests passed; the two timezone-boundary tests failed. Second attempt, same failures. Third attempt, same. The recurring-error trigger fired, visible in the console as an advisor invocation, and the advisor came back with two findings the executor had missed: the proration logic used the server's timezone instead of the subscription's, so renewals near UTC midnight landed in the wrong billing period — and the test fixtures the executor kept "fixing against" were themselves encoding the bug, which is why correct-looking fixes kept failing.
The part that sold me was what the executor did next. It rewrote the timezone handling, but it did not silently rewrite the fixtures. It flagged them: the advisor believes these tests validate incorrect behavior; review before I change test semantics. That is exactly the escalation behavior you want from a junior engineer, produced by the interaction between two models. From first failed fix to green suite: under four minutes, on a bug I had been circling for days.
Where Subagents Still Beat the Advisor
For my own daily work with a strong model executing, I still default to subagents over /advisor, and the reason is context. The advisor reads the full transcript — so if the executor is stuck because it framed the problem wrong, the advisor inherits the wrong framing and may never escape it. A subagent starts clean: only the prompt you give it, none of the accumulated bias.
I tested this directly with a deliberately mis-framed architecture question. Advisor configured with the same strong model: agreed with the framing. Fresh subagent given only the original requirements: reframed immediately and proposed a different, better solution. Same model, same problem, different answer — purely a function of context freshness. The mechanics of spinning up those clean-context workers are covered in my forked subagents guide.
So the working rule: advisor when your executor is the cheaper model and you want a stronger safety net; subagents when your executor is already the strong model and the risk is framing, not capability. Both, on anything high-stakes. And either way, watch the ledger — advisor calls appear as separate line items, so you can see exactly what the second brain costs, which pairs well with the broader token-management habits that keep long sessions affordable.
The Prediction I Got to Check
When I first tested /advisor, I argued it looked less like a convenience feature and more like scaffolding for a model tier too expensive to run as an everyday executor. That tier then shipped: Fable 5 arrived in June 2026 at $10 per million input tokens and $50 per million output — double Opus pricing. Nobody sane runs that as the executor on routine work. Escalation architectures — advisor calls, subagent consultations, tiered routing — are precisely how frontier-priced capability becomes affordable at the moments it earns its cost. Learning the advisor's rhythms on today's pairings is practice for that world, which has now plainly arrived.
If you run Claude Code on a cheaper executor, enable /advisor with the strongest model available and give it one real project this week. Pay attention to when it fires — that pattern recognition, not any single caught bug, is the durable value.
The prompts I use to steer these multi-model sessions — including the advisor-nudge phrasings and the escalation templates — live in my prompt library, free to lift for your own workflow.
