[FEATURE] Show active model in status line when skills/subagents override the session model
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Skills can specify a model field in their YAML frontmatter (e.g., model: haiku) to run with a lighter/heavier model than the session default. This works great for cost optimization.
When a skill launches with a different model, there is an inline notification:
Skill(cc-utils:skill-updater)
Successfully loaded skill · claude-haiku-4-5-20251001
However, this notification is inconsistent (doesn't always appear), and more importantly, the status line keeps showing the session's default model (e.g., Sonnet) while the skill is actively running on a different model (e.g., Haiku).
This means users have no real-time visibility into which model is processing their request. The only way to verify is parsing *.jsonl session logs after the fact.
Proposed Solution
Show the active model in the status line when a skill or Task-spawned agent uses a model different from the session default.
For example, if the session runs on Sonnet and a skill forces Haiku:
- Before skill: status line shows
Sonnet 4.5 - During skill: status line shows
Haiku 4.5(orSonnet 4.5 → Haiku 4.5, or↓ Haiku 4.5) - After skill: status line reverts to
Sonnet 4.5
The indicator should only appear when the model differs from the session default (no noise when models match).
As a secondary fix, the inline launch notification (Successfully loaded skill · model-name) should be made consistent — it currently doesn't always display.
Context
Related but distinct from:
- #16385 — Addressed the opposite problem (status bar incorrectly replacing the user's model with the subagent model)
- #23722 — Status line model display shared across multiple instances
This request is about observability of model routing: the model: frontmatter feature exists and works, but there's no real-time indicator of which model is actively handling the request.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗