opusplan, subagents, /advisor: which Claude Code routing knob does what

If you’ve used Claude Code for more than a week you’ve probably bumped into all three of these and wondered whether they’re the same thing. They aren’t. They look similar because they all involve picking models, but each one fires on a different signal, and you can run all three at the same time.

Short version:

• /model opusplan switches based on plan mode. Opus while you’re planning, Sonnet once you exit plan mode. Set it once at the start of a session.
• Subagents have their own model field. Claude routes to them based on the agent description, so this is the closest thing to “look at the prompt and pick a model.”
• /advisor keeps a cheap executor (Sonnet or Haiku) and lets it consult Opus when it decides it needs a second opinion. The executor decides, not you.

They compose. opusplan sets the main model, subagents bring their own model when delegated to, and /advisor sits on top as an escalation path regardless of what’s running underneath.

opusplan

Run /model opusplan and you’re done. Plan mode (Shift+Tab toggles it) uses Opus, everything else uses Sonnet. The trigger is the mode itself, not the content of what you’re typing.

This works well if your workflow already has a planning phase. Refactoring something nontrivial, scoping out a new feature, deciding how a service should be split. You think out loud with Opus, hit Shift+Tab, and Sonnet handles the actual edits.

What it does not do is notice when execution gets unexpectedly hard. If you’re halfway through implementing something and you hit a weird race condition or some library doing something it shouldn’t, opusplan will keep you on Sonnet. You have to manually /model opus for that stretch and then switch back. Not a big deal, just know it’s not adaptive.

Subagents

This is the one that actually inspects the request. You define a subagent with /agents, give it a description, set its model and tool permissions, and Claude delegates to it when something matches the description.

A setup that works well on microservices projects:

• exploration agent on Haiku, read-only, for “where is X defined” type questions
• test writer on Sonnet, scoped to test files
• security review on Opus, only triggered for auth and data-handling changes

Cost savings are real but the bigger win for me is context. Subagents run in their own conversation window and only return the summary. So your main thread doesn’t get clogged with the 40 file reads it took to find one helper function.

What makes or breaks this setup is the description. “For exploration tasks” is too vague and Claude won’t route to it consistently. Something like “use proactively when the user asks where something is defined or wants to understand the structure of an unfamiliar module” routes much more reliably. If two of your agents have overlapping descriptions, routing gets unpredictable, so it’s worth being deliberate about scope.

Files live in .claude/agents/ for project scope or ~/.claude/agents/ for user scope.

/advisor

This one’s in beta and it’s a different shape from the other two. Instead of switching the executor, you keep a fast executor (Sonnet or Haiku) and pair it with a smarter advisor (Opus). The executor decides on its own when to call the advisor.

/advisor

Pick the advisor model from the list and it’s enabled for the session. You don’t invoke it manually. The executor tends to reach for it before locking in an approach on something complex, when test results contradict its mental model, or before declaring something done that has real stakes.

Two properties matter in practice. First, advisor responses stay in session memory, so later turns see earlier advice. If the advisor said one thing and the test output says another, Claude flags the conflict instead of quietly going with whichever feels more recent. Second, billing is separate: the advisor sub-call uses the advisor model’s rates, and your executor’s max_tokens doesn’t bound advisor output. A session that looks cheap because Sonnet is doing the bulk work can still spend Opus tokens through advisor calls. Worth knowing if you’re tracking quota.

Picking which to use

	trigger	layer
opusplan	plan mode toggle	session-wide
subagents	description match	per-delegation
/advisor	executor’s own judgment	per-turn

In practice I run opusplan as a default, define a few subagents for things I do repeatedly (exploration, security review, test writing), and turn /advisor on for sessions where I expect to hit hard problems. They don’t fight each other.

If you’re only going to set up one of these to start, I’d go with subagents. You get the most control over what gets routed where, and the context-isolation benefit kicks in even if you don’t care about cost. opusplan is faster to enable but coarser. /advisor is the most interesting once you’re already comfortable with the other two.