Claude Code Advisor Command: How to Turn It On and Off

Claude Code 2.1.300 added an /advisor slash command, but only on Claude Platform on AWS, and it does nothing until you pick an advisor. There are three ways to pick one: type /advisor inside a session, set advisorModel in your settings, or start Claude Code with the --advisor flag. If you want the advisor tool gone entirely, set CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1 in the environment Claude Code starts in.

That's the whole story as the release notes tell it. If you typed /advisor and got an unknown-command error, you're most likely on a build older than 2.1.300 or on a provider the note doesn't cover. The rest of this page walks through each switch, the order I'd try them in, and the handful of ways this goes wrong.

What the advisor command actually is#

The only official text about /advisor right now is one bullet in the v2.1.300 release notes, published on 14 October:

Added /advisor on Claude Platform on AWS; no advisor runs until you pick one with /advisor, advisorModel or --advisor, and CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1 turns it off

That sentence carries three facts worth separating.

• It's scoped to Claude Platform on AWS. The note doesn't say the command exists anywhere else. Don't read that as a promise it's absent elsewhere, but don't expect it either.
• It's opt-in. Installing 2.1.300 doesn't start an advisor. Nothing runs until you choose one through one of the three mechanisms.
• There's a hard off switch. The environment variable CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1 turns the tool off, which is the right answer for locked-down or cost-sensitive setups.

What the note does not say is just as useful to know. It doesn't describe what the advisor does with the model you pick, when Claude consults it, or what it costs. Blog posts that fill those gaps in are guessing, and I'd treat them accordingly until the Claude Code docs cover it. Everything below sticks to the documented switches.

Turn it on with the /advisor command#

The smallest thing that works: start Claude Code against Claude Platform on AWS and type the command at the prompt.

/advisor

The release note describes this as the way to "pick one," so expect to be asked which advisor you want rather than have one silently chosen for you. This is the route I'd start with. It's interactive, it's scoped to the current session, and it tells you immediately whether your build and provider support the feature at all. If the command is recognized, the other two mechanisms will work too.

If you get an unknown-command response instead, skip ahead to the troubleshooting section before touching settings or flags. Neither of those will help if the command itself isn't present.

Set advisorModel in settings for a persistent choice#

Once you know which advisor you want every time, put it in your Claude Code settings file under the advisorModel key. The release note lists this key alongside the slash command and the flag as an equivalent way to pick an advisor.

{
  "advisorModel": "<your-advisor-model>"
}

Replace the placeholder with the advisor your deployment serves. The note doesn't publish a list of accepted values, so use whatever /advisor offered you when you ran it interactively.

Two practical notes on scope. The changelog refers to both project settings and managed settings in other bullets, so the usual layering applies: a project-level setting is a good fit when one repo should always use the same advisor, and a user-level setting is better for a personal default. And remember this is a separate key from your main model choice. Setting advisorModel doesn't change which model handles your conversation.

Here's a small script that produces the settings fragment plus the matching flag and off switch from a single advisor name, handy for pasting into a team README:

const advisor = process.argv[2] || "<your-advisor-model>";

const settingsFragment = { advisorModel: advisor };

console.log("Settings file fragment:");
console.log(JSON.stringify(settingsFragment, null, 2));
console.log("");
console.log("One-off session flag:");
console.log(`claude --advisor ${advisor}`);
console.log("");
console.log("Turn the tool off entirely:");
console.log("CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1 claude");

Start with --advisor for a single session#

The third mechanism is the command-line flag. The note lists --advisor as another way to pick an advisor, which makes it the natural choice for scripts, one-off experiments, or trying a different advisor without editing a settings file.

claude --advisor <your-advisor-model>

Since the note names it as a picker, expect to pass the advisor you want after the flag. If you want to confirm the exact argument form on your build, claude --help prints the current flag list. The 2.1.300 notes mention that help text was corrected in this release, so it's a reasonable source of truth for what your installed version accepts.

When would I reach for the flag over settings? Mostly in CI-style or wrapper-script contexts where the invocation is already explicit, and when comparing two advisors back to back. For day-to-day interactive work, advisorModel in settings is less typing.

Disable it with CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1#

If you'd rather the advisor tool not exist in your sessions at all, set the environment variable to 1. The release note is specific about the value: CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1 turns it off.

For a single run:

CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1 claude

For every run from your shell, export it in your profile:

export CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1

This is the switch I'd recommend for shared machines, containers, and any environment where someone might otherwise enable an advisor through settings without realizing it. Because it's an environment variable, it also travels cleanly into CI runners and Dockerfiles.

The variable is easy to forget about once it's buried in a profile, so a quick check is worth having. This script reports exactly what Claude Code would see:

import os

value = os.environ.get("CLAUDE_CODE_DISABLE_ADVISOR_TOOL")

if value == "1":
    print("CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1 is set: the advisor tool is turned off.")
elif value is None:
    print("CLAUDE_CODE_DISABLE_ADVISOR_TOOL is not set: the advisor is available, but nothing runs until you pick one.")
else:
    print(f"CLAUDE_CODE_DISABLE_ADVISOR_TOOL={value!r}: only the value 1 is documented as turning the tool off.")

Run it in the same shell you launch Claude Code from. If it reports the variable as set and you didn't expect that, grep your shell startup files, your container image, and your CI job definitions in that order.

Unknown command advisor: why it's missing#

The most common search that leads here is some variant of "claude code unknown command advisor." Work through these in order.

1. Your build predates 2.1.300. The command was added in that release. Anything older simply doesn't have it. Check the releases page for the current version and update.
2. You're not on Claude Platform on AWS. The note scopes the addition to that platform. If your session runs against a different provider, the absence of the command is consistent with what's documented, not a bug on your end.
3. The off switch is set somewhere. CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1 turns the tool off. A profile export, a container environment, or a CI variable can do that without you noticing. The Python check above tells you quickly.
4. A typo. It's /advisor, singular, no trailing s.

If all four check out and the command still isn't recognized, the claude-code repository is the place to report it, with your version and provider in the report.

Gotchas and common mistakes#

Expecting an advisor to run after upgrading. It won't. The release note is explicit that no advisor runs until you pick one. If you upgraded and see no change in behavior, that's by design, not a broken install.

Setting the kill switch and then wondering why nothing works. With CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1 in place, the tool is off. Picking an advisor through /advisor, advisorModel, or --advisor won't bring it back while the variable is set. Clear the variable first.

Confusing advisorModel with your main model. These are different keys for different jobs. advisorModel selects the advisor. It doesn't change the model that handles your conversation, and changing your main model doesn't pick an advisor.

Filling in undocumented behavior. The note doesn't say what the advisor does, how often it's consulted, or what it adds to your bill. Don't plan a budget or a workflow around assumptions. Try it on a small project first and watch what happens.

Mixing scopes without a plan. A project setting and a personal setting can disagree, and a flag on the command line is its own layer again. Pick one mechanism per environment so that the answer to "which advisor is active?" is obvious. For teams, I'd put the choice in project settings and reserve --advisor for experiments.

Treating the flag as a toggle. The note lists --advisor as a way to pick one, not a bare on/off switch. Pass the advisor you want, and use claude --help on your build if you're unsure of the form.

Quick reference#

Before you file a bug or rewrite your settings, run down this list:

• You're on Claude Code 2.1.300 or later.
• Your session runs against Claude Platform on AWS.
• CLAUDE_CODE_DISABLE_ADVISOR_TOOL isn't set to 1 in the shell, container, or CI job.
• You've picked an advisor through exactly one of /advisor, advisorModel, or --advisor, and you know which one.
• You haven't assumed anything about the advisor's behavior that the release note doesn't state.

If each line holds, /advisor is on and doing whatever it does, and you have a clean way to turn it off when you need to.

Quick answers