[FEATURE] Expose sub-agent model in the subagentStatusLine payload
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
Sub-agents can run on a different model than the main session (an agent definition with a model override, a Task-tool spawn on a specific tier, forked sub-agents, etc.). When several sub-agents are running, I want to see which model each one is on directly in the agent panel, but there is no way to surface it: the model is not passed to subagentStatusLine.
The main statusLine payload does not help either — its model object reflects only the top-level session and does not change when a sub-agent is focused. So no custom status line can display a sub-agent's model today.
Current behaviour (verified on Claude Code 2.1.199)
The subagentStatusLine command receives a tasks array where each task object has exactly these fields:
id, type, status, description, label, startTime, tokenCount, tokenSamples, cwd
There is no model field on the task object, and no model information anywhere else in the per-task payload.
Proposed Solution
Add a model object to each entry in the subagentStatusLine tasks array, mirroring the shape already used by the main statusLine payload:
{
"id": "a265ffabe55c12d85",
"type": "local_agent",
"status": "running",
"description": "...",
"label": "...",
"startTime": 1783036392619,
"tokenCount": 56805,
"tokenSamples": [56805],
"cwd": "/path/to/worktree",
"model": {
"id": "claude-haiku-4-5-20251001",
"display_name": "Haiku 4.5"
}
}
Reusing the existing { id, display_name } shape keeps it consistent with model in the main statusLine payload, so the same rendering logic works in both places.
Alternative Solutions
None are viable today. The model is absent from both the main statusLine payload (per-session only) and the subagentStatusLine tasks array, so there is no data a custom status line could use to derive or display a sub-agent's model.
Priority
Low - Nice to have
Feature Category
Configuration and settings
Use Case Example
- A coordinator session spawns several sub-agents, some on Haiku for cheap mechanical work and some on Opus for harder reasoning.
- A custom
subagentStatusLinescript renders one row per running sub-agent (name, status, token count). - With this feature, that row could also show the model, so at a glance I can confirm each sub-agent is on the intended tier.
Additional Context
Related: #65792 requests per-agent context-window usage in the same panel - same area, different field. Adding model alongside would fit naturally into the same per-task payload.
4 Comments
+1 — this would directly help model-routing workflows.
My setup: Opus as the planner/reviewer in the main session, with implementation delegated to Haiku sub-agents (e.g. a
code-implementeragent with a model override). During a task I'll have several sub-agents running across tiers — Haiku for mechanical edits, Opus for the harder reasoning.The gap I keep hitting: there's no way to confirm at a glance which sub-agent is actually on which model. When I navigate into a sub-agent, the main
statusLinestill shows the top-level session's model (Opus), so it looks like the Haiku implementer is running on Opus. Addingmodel: { id, display_name }to each entry in thesubagentStatusLinetasksarray (as proposed here) would let a custom status line render the tier per sub-agent and make the routing visible.The per-task
model(andcontextWindowSize) shipped in v2.1.205, so the tasks-panel half of this is resolved. Verified by dumping thesubagentStatusLinestdin: each task now carries the resolved model id, including per-call model overrides.The other half from the issue body is still open: when you navigate into a subagent, the main
statusLinecommand keeps receiving the unchanged top-level payload. I captured payloads across a focus switch to be sure:model,agent, and every other identity field stay constant, and neither payload has any focused/selected indicator. So a custom statusline still can't tell which subagent you're looking at. Mine shows Opus 4.8 while I'm inside a Sonnet 5 executor transcript.Either of these would close the gap:
statusLinewith the focused task's context when a subagent view is open, e.g. afocused_task: {id, type, model}field in the payload, orfocused: trueflag to the corresponding entry in thesubagentStatusLinetasks array.Option 1 covers the fullscreen transcript view where the tasks panel isn't visible; option 2 lets the row renderer at least mark the selection. With
modelalready plumbed into the task objects, focus state looks like the last missing piece.Closing for now — inactive for too long. Please open a new issue if this is still relevant.
@github-actions this isn't stale