`claude agents`: allow specifying a different model per background session at dispatch time

Status Fixed / completed

Reported on v2.1.170

Maintainer reply None cached

Activity 3 comments · opened Jun 10, 2026 · closed Jun 10, 2026

Body

What is Agent View?

claude agents opens a terminal dashboard (TUI) for managing multiple Claude Code background sessions at once. From this view you can dispatch new sessions (start a new task running in the background), monitor running ones, and step in to provide input. Each session runs independently and persists even if the terminal is closed.

Current behavior

When you open claude agents, every session you dispatch from within that view inherits a single model -- either the Claude Code default or whatever you passed at launch time (claude agents --model opus). There is no way to pick a different model for an individual session from inside the TUI dispatch flow.

Desired behavior

When dispatching a new background session from inside Agent View, allow specifying the model for that specific session -- so you can have session A on Opus for deep reasoning work and session B on Sonnet for faster/cheaper tasks, all managed from the same claude agents view.

Why this matters

The whole point of running parallel sessions is that each session is doing something different. Model cost and capability tradeoffs are task-dependent: a deep architecture refactor warrants Opus; running a test suite or generating boilerplate warrants Sonnet or Haiku. Tying all sessions to one model means either overpaying (everything on Opus) or under-powering the sessions that need it (everything on Sonnet).

Workaround that exists today

You can pre-launch sessions with --bg --model before opening Agent View:

claude --bg --model opus "refactor the auth module"
claude --bg --model sonnet "run and fix the test suite"
claude agents   # view + monitor both

This works and the sessions show up correctly in the TUI. The gap is that you have to step outside the TUI to do it. Once you are inside claude agents, there is no way to dispatch a new session with a model different from the view's default. The dispatch flow inside the TUI does not expose a model override.

Note: CLAUDE_CODE_SUBAGENT_MODEL sets a global default but does not help here -- it applies to all sessions and cannot be varied per-dispatch from within the TUI.

Proposed UX (preference order)

Flag in the dispatch input (preferred -- lowest scope): parse --model <alias> from the session prompt at dispatch time, e.g. type --model opus refactor the auth module in the dispatch field. The --model token is consumed by the TUI and does not reach the session prompt. This mirrors how claude --bg --model works at the CLI.

Model picker at dispatch (medium scope): show a model selector when creating a new session, similar in style to the /model picker accessible inside a running session via the /model command.

Post-dispatch switch (already partially works): allow /model inside an attached session to switch that session's model going forward without affecting others in the view. (This may already work in recent versions -- flagging in case it does not.)

Environment

claude --version: 2.1.170 (Claude Code)
OS: macOS 15.x
Shell: zsh inside tmux

View original on GitHub ↗

3 Comments

cnavarro165 · 4 months ago

Closing and refiling under my personal account. Apologies for the noise.

kcarriedo · 4 months ago

This surfaces a real pain in any non-trivial agent orchestration setup. The workaround (pre-launching sessions outside the TUI) is functional but defeats the point of having a unified agent view — you end up juggling two mental models at once.

One pattern I've seen work reasonably well in the meantime: wrapping the dispatch in a shell alias that infers model from a keyword prefix in the task description (e.g., [opus] or [sonnet] at the start of the task string), so you can still drive everything from one place without waiting for TUI support. Crude, but it preserves the session-dispatch workflow.

That said, first-class support for --model at dispatch time would be cleaner and removes the guessing game about which tasks warrant Opus vs. Sonnet. The per-session cost visibility gap (noted in #48040) makes this even sharper — you can't optimize what you can't see or control.

+1 on the inline --model <model> <task> parse approach as the preferred path. The UI picker adds friction at exactly the moment you're already context-switching between sessions.

github-actions[bot] · 2 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.