Let a subagent choose its own advisor model (per-agent advisorModel, or one rung above the caller)
Problem
advisorModel is one global setting. Every subagent inherits it, and the only guard is
"the advisor must be at least as capable as the base model", which skips the advisor when
it is weaker but happily runs it as a peer.
In practice that means:
- With
advisorModel: opus, an Opus subagent gets an Opus advisor. A peer shares the
worker's blind spots; the second opinion is mostly a second sample.
- With
advisorModel: fable, a Sonnet subagent gets a Fable advisor, and the advisor reads
the full transcript, so a cheap worker asking a routine question spends top-tier tokens
where Opus would have done the job.
There is no setting that gives both Sonnet -> Opus and Opus -> Fable in the same session.
Verified on 2.1.259: advisorModel is read once from settings, subagents receive the
parent's value (getAdvisorSetting), the agent-definition frontmatter has no advisor key,
and the advisor call is server-side, so a PreToolUse hook cannot see or rewrite it.
Request
Either of these would solve it; the first is simpler and fully explicit.
- Per-agent frontmatter key. Let
.claude/agents/*.mddeclareadvisorModel:,
overriding the session setting for that agent only. Example:
````
---
name: opus-owner
model: opus
advisorModel: fable
---
- A relative value. Accept
advisorModel: "escalate"(or similar) meaning "the next
model up from the caller's own model, capped at the top". Sonnet -> Opus,
Opus -> Fable, Fable -> Fable. This needs no per-agent configuration and matches how
the capability check already ranks models.
Why it matters
Teams that route work by model tier (Haiku lookups, Sonnet implementation, Opus ownership,
Fable for architecture and security calls) want the advisor to follow the same ladder. Today
the choice is between a peer advisor for the strongest workers or an over-provisioned one
for the cheapest, session-wide.
Workaround in use
A user-defined advisor subagent plus a PreToolUse hook that injects the escalated model
through updatedInput. It works for the harness advisor but cannot touch the native one, so
Opus workers are steered away from the native advisor by prompt text only.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗