The Advisor Tool: The Question Code Review Can't Ask

My main session runs Sonnet 5. Sitting behind it is an advisor: a stronger model (Opus) that the session can consult mid-task. It takes no arguments. The entire conversation — the request, every tool call, every result, the reasoning — is forwarded automatically, and advice comes back.

The instruction that governs it is roughly: call the advisor before substantive work. Not after the code is written and the tests are green — before the approach crystallises. Orientation first (find the files, read what’s there), then advise, then build.

That timing is the whole point, and it’s also why the tool is nearly invisible.

What you see

Here’s what an advisor call looks like in the terminal:

This looks complete and correct. Given the scope of what's about to land (a breaking
change to a second repo, new CI/release infrastructure, a namespace-package
architecture), let me get a final advisor check before committing.

● Advising using Opus 5
✔ Advisor has reviewed the conversation and will apply the feedback

Good catch — let me verify the actual wheel build, not just the source-tree import,
before committing.

Two lines. A spinner and a checkmark. “Will apply the feedback” — which feedback?

The only signal that anything happened is the tonal shift on the other side. Good catch — catch of what? You can reverse-engineer it in this case, because the next sentence names the correction: test the built wheel, not the source tree. That’s a real bug class (a package that imports fine from the repo but ships broken), and the advisor caught it before a release went out.

But that’s the generous case, where one line of advice maps to one visible next action. Most of the time the trigger line reads as a generic let me get a second opinion, and the response reads as the agent simply continuing.

Three kinds of attention

I want to be precise about what the advisor calls add, because “AI catches bugs” is not the interesting claim.

There are three questions you can ask about a change. They get wildly uneven amounts of tooling:

The first two are well served, and getting better fast. The third has always been the easy one to skip, and the reason is structural rather than lazy: review happens after a diff exists, and the diff defines the frame. Every line you’re looking at sits inside the boundary the original request drew. Completeness is a question about what’s outside that boundary — and by the time there’s something to review, everyone looking at it has already accepted the boundary as given.

So the third question has traditionally been asked by whichever senior engineer happened to read the ticket and think that’s not going to be the whole of it. Tacit, unevenly distributed, no artifact left behind, and it only pays off if it happens before the code exists. After that it’s just rework.

Which is exactly the slot the advisor occupies. It sees the request and the codebase together, before a line is written, and can say: what you asked for is three-quarters of a fix, here’s the quarter that will bite you.

What comes back, in practice, is rarely a correction. It’s a list — the things that have to change alongside the thing I asked for, which I’d half-sensed were there without being able to name them.

The value isn’t catching a mistake in the request. It’s noticing that the request was a subset of the change.

The visibility gap

Here’s my actual complaint, and the reason this post exists.

The last time this properly earned its keep, a one-line request of mine came back with three further problems attached — one of them a pre-existing bug that had nothing to do with the task, sitting in the code path I was about to touch. In the terminal, all of that arrived as:

● Advising using Opus 5
✔ Advisor has reviewed the conversation and will apply the feedback

I only know what the advisor said because I was reading the session closely and watched the plan get bigger — files appearing in the change set that had no business being there if my request had been the whole job. The trigger line gave no hint. It read like housekeeping, not like there are three more real bugs adjacent to what you asked for.

This matters because it inverts a normal trust heuristic. Usually the loud output is where the value is and the quiet output is plumbing. Here, one of the highest-value tool calls in the session is also the quietest. If you’re skimming — and everyone skims eventually — the advisor call is exactly the kind of line your eye slides past.

Two practical things I do about it, neither of them satisfying:

• Watch what the session does next, not what the tool call says. A widening change set right after an advisor call is the tell. Good catch is a tell. New files appearing in the plan are a tell.
• Treat scope growth after an advisor call as signal, not scope creep. My instinct when a one-line request turns into six files is to push back. That instinct is wrong often enough here that I’ve had to retrain it.

Neither is a substitute for just showing me the advice. But until it’s surfaced, the tool’s real behaviour is: pays for itself in the cases you’ll never see, and costs you two lines of terminal output in the cases where it had nothing to add.

Worth it. Just don’t mistake the quiet for nothing happening.

Which model should advise?

The tempting answer is the most capable one available — at time of writing, Fable 5. That will deliver the goods. What’s less obvious is whether it delivers meaningfully more than Opus 5, at roughly twice the per-token cost.

There is one hard constraint worth knowing: the advisor has to be at least as capable as the model it’s advising. Pairing a strong executor with a weaker advisor is just a slower route to a worse answer. My own setup — Sonnet 5 in the main loop, Opus 5 advising — sits comfortably inside that rule.

This pairing is productized, not just a Claude Code convenience — there’s an advisor tool in the Claude API, and Anthropic has published benchmarks for it. They’re worth knowing before you reach for the top tier:

• On SWE-bench Multilingual, Sonnet with an Opus advisor scored 2.7 percentage points higher than Sonnet alone — while costing 11.9% less per task. Better and cheaper than the executor running solo, because the advisor is consulted at decision points rather than generating the bulk of the tokens.
• One tier down it’s starker. Haiku with an Opus advisor more than doubled its solo BrowseComp score — 19.7% to 41.2% — landing 29% behind Sonnet solo while costing 85% less per task.

Read that first bullet again, because it’s the counterintuitive one: adding a more expensive model to the loop made the whole thing cheaper. That only works because of the asymmetry the whole article rests on — the advisor is called rarely and says little.

Note what isn’t in that post, though: a comparison of executor-plus-advisor against running the big model end-to-end for the whole task. Every published number is measured against the executor running solo, not against the tier above. So the question “should I just run Opus for everything?” is one the benchmarks don’t answer.

Above that floor, then, it stops being a question about the leaderboard and becomes a question about your work. The advisor’s value here wasn’t raw capability; it was noticing that a request was a subset of a change. Whether the top-tier model is better at noticing that than the tier below is empirical, and the answer probably differs by codebase.

So test it. Run the same class of task with each candidate advising, and judge on what came back — not whether the advice was good, but whether it was better in a way that changed what you did. That’s the only measure that counts, and it’s the one a benchmark can’t hand you.

When in doubt, test — and pick the model that gives the most bang for the buck.