/usage suggests configuring per-subagent model overrides for skills that don't expose that control (e.g. code-review)

Status Open
Maintainer reply None cached
Activity 1 comment · opened Sep 14, 2026

Description

/usage surfaces generic advice whenever a chunk of token usage traces back to subagent-heavy activity, e.g.:

60% of your usage came from subagents under "code-review" If this runs frequently, consider configuring its subagents with a cheaper model or tightening their prompts.

This advice is sound for things that actually expose a model-selection knob - a custom subagent type defined in .claude/agents/*.md (which supports a model: frontmatter field), or a Workflow script's agent() calls (which take an opts.model). But the built-in code-review skill is neither of those: its finder sub-agents are spawned from logic compiled directly into the Claude Code binary, with no SKILL.md, settings.json field, or any other user-editable surface to pin those sub-agents to a cheaper model.

So /usage's suggestion here is advice that can't actually be acted on for this specific skill - a user following it will look for a config option that doesn't exist.

Expected behavior

Either:

  1. /usage should only surface the "configure a cheaper model" suggestion for subagent sources that actually expose a model override (custom agent types, Workflow scripts), or
  2. Built-in skills like code-review should expose a real model-override mechanism (e.g. an argument or settings key), so the advice becomes actionable everywhere it's given.

The more actionable lever available today for code-review specifically is its effort level (low/medium/high/etc.), which does scale sub-agent fan-out/cost - /usage could suggest that instead when the source is a skill without model-override support.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗