[FEATURE] Show which model each background agent is running on, in the agents view and `claude agents --json`

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Jul 29, 2026

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

When I spawn background agents (claude --bg, backgrounding, or dispatching from the agents view), there is no way to see which model any of them is running on.

I deliberately run a mixed fleet: Opus for the hard design and debugging work, Sonnet or Haiku for cheap sweeps and mechanical edits. Once four or five agents are in flight, the agents view is a list of names and states with no indication of what any of them costs or how capable it is. That matters in three concrete ways:

  1. Cost. I cannot tell at a glance whether I have three Opus agents grinding on chores.
  2. Debugging quality. When an agent produces weak output, the first question is "what model is this actually on?" and today I cannot answer it without leaving the tool.
  3. Verifying the launch actually took. A model can be requested and not used. See the evidence below.

There is currently no supported surface that answers this, for a running agent or a finished one.

Proposed Solution

Surface the model each background agent is running on, in both places agents are listed:

  1. claude agents --json: add a model field per entry. Today the payload is:

``json
{
"pid": 59708,
"id": "d549bc5f",
"cwd": "/Users/me/Projects/dotfiles",
"kind": "background",
"startedAt": 1785333039522,
"sessionId": "d549bc5f-fca7-4ec7-9d75-ea1dd90c56fe",
"name": "review the agent config",
"status": "busy",
"state": "working"
}
``

The natural addition is "model": "claude-opus-5" reflecting the model actually serving the session, not just the alias it was launched with. If a session has switched models mid-run, the current model is the useful value.

  1. The interactive agents view: show the same value as a column or in the detail pane, so a mixed fleet is readable without dropping to the CLI.

Effort level would be a welcome bonus in the same place, since it is settable per dispatched session via --effort, but the model is the part I actually need.

Alternative Solutions

I went looking for a workaround and each one falls short:

  • claude agents --json returns pid, id, cwd, kind, startedAt, sessionId, name, status, state. No model. This is the surface that should have it.
  • ~/.claude/jobs/<id>/state.json contains respawnFlags, which includes the --model value:

``json
"respawnFlags": ["--agent", "claude", "--permission-mode", "default", "--model", "opus[1m]"]
``

Two problems. It is an undocumented internal file, so scripting against it is fragile. More importantly it is a respawn hint, not a record of what ran, and the two can disagree. One of my jobs has "--model", "sonnet" in respawnFlags while every single assistant turn in its transcript is claude-opus-4-8. Its updatedAt is 16 days after createdAt, so the flags were plausibly rewritten after the session finished. Either way, it is not a trustworthy answer to "what is this agent running on".

  • The session transcript at ~/.claude/projects/<slug>/<sessionId>.jsonl has .message.model on every assistant turn. This is the actual ground truth, but getting to it means a jq pass over a file that can be hundreds of megabytes, after resolving the mangled project directory name, and it still needs handling for <synthetic> entries and for sessions that span more than one model.
  • The statusline does show the model, but background sessions run headless, so nothing renders until I attach to the session. That is exactly the moment I no longer need a list.

I ended up writing a shell script that joins state.json against the transcript JSONL to print a table. That it takes a custom script and two undocumented file formats to answer "which model is this agent on" is the reason I am filing this.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

  1. I dispatch four background agents: two Opus for a refactor and a tricky bug, two Sonnet for a docs sweep and a test-flake hunt.
  2. Twenty minutes later I open the agents view to triage. All four rows show a name and a state.
  3. One agent has produced output that looks distinctly below par. I want to know whether it is on the model I intended, or whether it fell back to something else, before I spend time re-prompting it.
  4. With a model column I read the answer in one glance and either bump that agent up or accept the result.
  5. I also see immediately that I do not have an expensive model idling on a chore, which is the check I currently just skip.

Additional Context

  • Version: 2.1.220 (Claude Code), macOS 26.5.2 (Darwin 25.5.0)
  • Possibly related, though each is a different ask:
  • #65273 - claude agents --json returns a subset of the agents shown in the interactive view. Same command, adjacent gap in its output.
  • #75981 - hooks cannot detect the active model or /model runtime switches. Same underlying theme of the active model not being observable from outside the session.
  • #81562 - silent model substitution when the requested model is unavailable. That issue is about the substitution itself; this one is about being able to see which model a background agent ended up on, which would also make substitutions visible.

View original on GitHub ↗