Show the active model (Opus / Sonnet / …) per agent in the sidebar

[sadayuki-matsuno]

What I want

When I run several Claude Code panes side by side, the agents sidebar shows each one as claude with its status (working / blocked / done). What it doesn't show is which model each pane is running — Opus vs. Sonnet vs. Haiku.

I'd love the sidebar to surface the active model per agent, so I can tell at a glance which pane is on which model.

Why

I deliberately run different models for different jobs at the same time — e.g. a heavier model doing implementation in one pane and a cheaper model handling mechanical PR/CI cleanup in another. Right now every row just says claude, so I can't distinguish them without focusing each pane and checking.

Seeing the model in the row would make this kind of mixed-model workflow readable at a glance, which is exactly the situation herdr's sidebar is great for.

Note

The active model can change mid-session (Claude Code's /model command), so ideally the displayed model would follow those switches rather than only reflecting the model at launch.

Thanks again for herdr.

[Daniel-Steinberger]

+1, and I'd widen this a bit: the same screen text that reveals the active model in Claude Code also reveals the reasoning-effort level and, separately, a persistent permission-mode badge (plan / auto / manual / accept-edits). All three are "which pane is doing what, without focusing it" information, so I think they belong in the same feature.

Proposed approach

Extend the existing per-agent screen-detection manifests (src/detect/manifests/<agent>.toml) with a second, independent rule set, call it [[attributes]], alongside the existing [[rules]] state matching. Where [[rules]] picks one winning idle/working/blocked/unknown state, [[attributes]] extracts free-form values (model name, mode, effort) from the same screen text, with the same priority-wins-per-id semantics [[rules]] already uses. Each attribute rule is either a static value (e.g. mode = "plan" when a known badge string is present) or a capture_group pulled from a named regex group, so two attributes can share one region+regex and each grab a different piece of the same line (Claude Code prints model + effort together: "Sonnet 5 with high effort"). That answers the "follow /model switches" point too: the same rule set matches the /model confirmation line, not just the startup banner.

The three attribute ids (model_name, mode, effort) would be a fixed superset in Rust, and each agent's manifest implements whichever subset is actually visible for that CLI, e.g. Codex has no persistent mode badge today, so its manifest would only populate model_name/effort. An agent that implements none of them just shows nothing extra, same as today.

Because the underlying text is transient (a startup banner scrolls out of view after a few turns), the runtime side would latch: a fresh value overwrites what's shown, but a scan that doesn't re-observe it leaves the previous value in place, resetting only on agent change / process exit. Display would be a new opt-in sidebar field (like the existing custom_status field from #304), not part of the default layout, since only a couple of agents can populate it right now.

Config

Opt-in via the same ui.sidebar.agents layout config #304 introduced, no new config surface, just three new field names on their own line so they don't fight the identity line for width:

[ui.sidebar.agents]
lines = [
  [
    { field = "agent_status", show = true },
    { field = "pane_name", show = true },
    { field = "tab_name", show = true },
    { field = "space_name", show = true },
  ],
  [
    { field = "status", show = true },
    { field = "time", show = true },
    { field = "custom_status", show = true },
    { field = "right_alignment", show = true },
    { field = "agent_name", show = true },
  ],
  [
    { field = "model_name", show = true },
    { field = "mode", show = true },
    { field = "effort", show = true },
  ],
]

Status

I've built a working prototype of this on top of my fork (herdr-mx) against a recent master, including Claude Code and Codex manifest rules verified against live sessions (screen-detection evidence, not guessed regexes), and both the server-rendered and client-rendered sidebar paths. Screenshot below is three live panes (two Claude, one Codex) each showing their own model/mode/effort line. Happy to share the branch/diff or open a PR if this direction is welcome.

Open questions

• Does a fixed, Rust-enforced set of attribute ids (model_name/mode/effort) fit herdr's direction, or would you rather keep the manifest vocabulary fully open-ended (arbitrary string keys)?
• Is a third sidebar field the right call, or would folding this into the existing custom_status slot (letting a manifest author format it however they want) fit better?
• Any preference on mode terminology, I used plan/auto/manual/accept_edits for Claude Code's four confirmed status-bar badges; happy to adjust if you'd rather standardize differently across agents.

[llvm-x86]

Attribute plumbing is tempting, but detection is built on evidence from screen snapshots, not agent-declared metadata — model/mode/effort would be among the first fields we just trust instead of infer. Sidebar display is a TUI concern; can this stay a presentation-layer decode against the existing snapshot instead of growing the manifest schema? Genuine question: is there a case where model/effort can't be recovered from what's on screen, forcing manifest attributes rather than smarter decoding?

[Daniel-Steinberger]

To be clear on the first point: nothing here is agent-declared. [[attributes]] reads the exact same screen snapshot (DetectionInput) the existing [[rules]] state matching reads, with regex/contains against visible text, same evidence, same trust level. There's no new channel where an agent asserts its own model/mode/effort and herdr believes it.

On the "why not a presentation-layer decode" question: I don't think it removes the need for a manifest-like mechanism, it just relocates it. Two things push back on doing this purely at render time:

1. It still needs a cache, not just a decode. The model+effort banner is only on screen for the first few turns before it scrolls out of the detection tail, and the permission-mode badge isn't necessarily on screen at the exact moment you're rendering (mid-scroll, alt-screen tool output, etc). A pure "decode from the current snapshot" at render time would flicker to blank the moment the source text isn't visible. You need the same latch-across-scans state this PR keeps in TerminalState, decoded on the detection tick (same place state detection already runs), not on the render tick.
2. The per-agent text knowledge has to live somewhere, and today that's TOML, not Rust. If the decoder moves to the render path, it either becomes a match agent { Claude => ..., Codex => ... } block in core code, or it grows its own pluggable per-agent config, which is the manifest system again, just moved and renamed. Herdr's existing principle ("the detector reads a screen snapshot", CLAUDE.md's own words) is specifically why state detection is TOML-driven and not hardcoded per agent; extending it with a second, independent, priority-ranked rule set felt like the smaller diff than introducing a second place where per-agent screen text gets special-cased.

Answering directly: there's no case where model/effort can't be recovered from the screen, that's exactly why I think it fits the existing detection model rather than needing something new. The question isn't detection vs. trust, both approaches read the same pixels, it's where the per-agent text-matching logic and its cached result live. Doing it at the same point state detection already runs also means the value is available to anything that already consumes AgentDetection (the socket API, scripting, etc), not only the one sidebar widget that happens to render it today.

Happy to be wrong here though, if there's a cleaner presentation-layer design that doesn't need a cache or per-agent Rust branching, I'd genuinely rather have less surface area, not more.

[llvm-x86]

The trust pushback was off — if [[attributes]] reads the same DetectionInput snapshot as [[rules]], this isn’t agent-declared metadata.

Latch/cache and per-agent decode paths make “where matching lives” the real fork; I’m not arguing presentation-only after that.

On the smaller-surface option: are you leaning toward fixed ids (model, effort, mode) for sidebar/socket consumers, or open attribute keys?

[ogulcancelik]

https://herdr.dev/docs/configuration/#sidebar-row-layouts

latest sidebar customization is the solution for this. i don't want to bring more primitives but it should be extendable by anyone. tell your claude to make a claude code hook would report anything you want :)