[Feature Request] Add per-subagent observability (model, effort) to /agents Running tab and agent JSON output

The observability gap you're describing is the same problem from a different angle than the cost runaway issues (#72127, #72080): in all three cases, the root cause is that the operator has no live view of what agents are consuming or how they're executing.

Per-subagent model + effort visibility matters specifically because subagents can silently run at a higher model tier than the parent (or inherit effort settings that weren't meant for a background sweep). Without it, the only signal you get is the final token count after the session ends.

A few things that would make the /agents Running tab genuinely useful here:

1. Model column - which model each agent was actually dispatched with, not just what the parent requested. Useful for catching cases where a Workflow tool auto-selects Opus for a subtask that doesn't warrant it.

1. Effort level - showing "high effort" next to a background agent doing a 3-file diff is a clear prompt to reconsider the configuration.

1. Token-so-far - even a rough running count would let you catch a looping agent before it completes.

The out-of-process claude agents path is the right place to expose this for in-session subagents too, since that's where external monitoring tools hook in. The JSON output gap matters there - without model/effort in the struct, anything building on top of claude agents --json has to scrape UI or wait for the session to close.

For context: we've been working around this at the orchestration layer (Claudeverse) by writing per-agent metadata to a spend_log at spawn time and again at completion. It works but it shouldn't need to be a userspace concern - the platform has all this information and it should surface it.

Strong +1 on this feature request.

This gap is real and it compounds fast. Once you have 4+ subagents running in parallel, you lose the ability to make informed decisions mid-session: you don't know whether to wait (the agents are burning through tokens productively) or intervene (one is stuck in a reasoning loop at xhigh effort).

The model column is particularly useful for mixed-model workflows - running some subtasks on Haiku for speed while reserving Opus for synthesis - because right now you can't verify the routing worked without blocking to query each agent individually.

A few things that would make this actionable:

• Surface model + effort in /agents Running tab (as you described)
• Include a live token estimate per subagent (even a rough running total)
• Make claude agents --json include in-session subagents so external monitoring scripts can read it without interrupting the session

On the out-of-process vs in-session split: this is an architectural constraint but worth solving. The cleanest path might be a lightweight IPC socket the main session advertises that external processes can query for the current agent roster + stats without needing to parse tmux pane output.

+1 for the fleet-table case specifically: running many background sessions via claude agents, model + effort are the two settings that most affect cost/behaviour yet aren't shown — you must open each session to see them. Two read-only columns appended after age (or a toggle) would fully cover it. Same data the harness already has from --model/--effort.