Using Claude's Advisor Strategy to Optimize the Balance Between Performance and Cost

Coding-agent-based development is no longer unusual, and as it becomes more common, the discussion around cost becomes impossible to ignore. More capable AI models can handle more complex tasks, but they also cost more. In principle, it would be ideal to use lightweight models such as Haiku or Sonnet for simple tasks and high-performance models such as Opus for more complex ones. In practice, though, designing how to assign each task to the right model is itself a complicated challenge.

The newly added Advisor tool in Claude addresses that performance-versus-cost tradeoff. It allows routine work to be handled by lightweight models such as Haiku or Sonnet, while enabling the executor to "consult" a higher-performance model such as Opus when it encounters a complex problem it cannot resolve on its own. When Opus receives that consultation, it can access the shared context and return plans, revisions, or stop signals. In a sense, this inverts the usual idea of delegating work to a sub-agent in large-scale agent orchestration. Because the high-performance model is called only when needed, you can keep costs down while still making full use of its capabilities.

In Claude Code, the /advisor command is also available starting from v2.1.101. By using this command, you can apply the Advisor tool directly inside Claude Code. In this article, I will walk through how the Advisor tool can be used in Claude Code.

Trying the Advisor Strategy in Claude Code

To try the Advisor tool in Claude Code, use the /advisor command. When you run it, Claude Code shows a set of options for which model to use as the advisor. In this example, we will choose Opus. Sonnet will handle the main task execution, and Opus will be consulted only when necessary.

Once you select an advisor, Claude Code can use the advisor tool. When I asked Claude Code itself to explain the advisor tool, it said the following usage rules applied:

Call it before doing substantial work - It is fine to do light investigation such as reading files first, but the best timing is before writing, editing, or declaring the answer.

Save deliverables before finishing - Make sure your work remains even if the session ends while the advisor call is in progress.

Take the advice seriously - If you followed the advice but it failed empirically, or if it conflicts with the evidence you have locally, call the advisor again to resolve the contradiction.

Call it multiple times for long tasks - A good rule of thumb is once before locking in the approach and once before declaring completion.

Let's try running a task as usual with the advisor tool enabled. In this example, Card.svelte has three responsibilities mixed into it, so we will run a task asking Claude Code to refactor it to follow the single-responsibility principle.

Card.svelte currently has three separate concerns packed into its onMount logic:
- inserting copy buttons for code blocks
- handling the image modal behavior
- loading baseline-status
 
Please fix the issue of mixed responsibilities in Card.svelte.

When this task runs, you can see Opus being consulted to help formulate an implementation plan. This is where the advisor tool is called.

The advisor tool takes no arguments. You simply call it. When it is invoked, the entire conversation history is automatically transferred, so Opus can return feedback on the implementation plan with the full context in mind. At the point where Sonnet had just received the task, its thinking appeared to look something like this (translated into Japanese in the original article):

I understand the structure. There is no existing actions directory. I will create Svelte actions for the two more complex onMount blocks:

app/src/lib/actions/codeBlockCopy.ts - A Svelte action for code block copy buttons

app/src/lib/actions/imageModal.ts - A Svelte action for the modal used to enlarge images on click The baseline-status import is only a simple one-liner, so I will keep it in Card.svelte. About Svelte actions:

They receive the target node as the first argument

They can optionally return a { destroy() } object for cleanup

The code block action will query pre elements inside the target node

The image modal action will query img elements inside the target node Looking more closely at the current code:

Code blocks: document.querySelectorAll("pre") - queried globally

Images: document.querySelectorAll("#contents img") - queried inside #contents Also, the m import from $paraglide/messages is used in the code block copy action. There are two possible approaches:

Import m directly inside the action file

Pass it as a parameter to the action To keep the action simple, I will go with the direct import approach.

Opus then returns feedback on that implementation plan based on the conversation history. Its response is returned to the executor as an advisor_tool_result block. Because Opus's thought process is discarded while producing the result, only the result itself is returned.

The plan is sound. There are three important points to keep in mind during implementation:

If you use $paraglide/messages in a .ts action file - Confirm that this import resolves correctly outside a .svelte component. If it does not resolve because of SvelteKit aliases or Vite plugin behavior, it is safer to pass { copyLabel: string, copiedLabel: string } as the second argument to the action instead of importing m inside the action. Parameterization is recommended.

Scope queries to node, not document - The current code uses document.querySelectorAll("pre") and document.querySelectorAll("#contents img"), which perform global queries. Inside the action, use node.querySelectorAll(...) instead. This is the essence of the refactor, so be careful not to leave the global queries in place by mistake.

Clean up codeBlockCopy properly - The current code inserts buttons and popups as siblings of pre by using insertAdjacentElement. In the destroy function, you need to remove not only event listeners but also the inserted elements. Otherwise, stale copy buttons may remain after HMR or SvelteKit navigation. Track them in an array during setup and remove them during destroy.

Keep the one-line baseline-status logic inline in Card.svelte - Extracting a one-line onMount would just add unnecessary indirection.

Opus pointed out the following three risks that Sonnet had missed in its initial reasoning:

Uncertainty around resolving the $paraglide alias in a .ts file -> switch to passing parameters
Global document queries -> change them to node.querySelector
Missing DOM cleanup in destroy -> track inserted elements in an inserted array and remove them

Summary

By using Claude's Advisor tool, you can optimize the balance between performance and cost. The idea is to let lightweight models handle routine tasks while consulting a high-performance model only when needed.
By using the /advisor command in Claude Code, you can enable the advisor tool. This allows the executor to ask a high-performance model for feedback when necessary while working through a task.
The rules for using the Advisor tool in Claude Code include calling it before substantial work, saving deliverables before completion, taking its advice seriously, and calling it multiple times during long tasks.
The advisor tool itself takes no arguments. You simply call it, and the full conversation history is automatically transferred so Opus can return feedback with the prior context in mind.