[FEATURE] Clause Code Web UI: show which model and effort level each running agent is using

Status Open
Reported on v2.1.222
Maintainer reply None cached
Activity 0 comments · opened Aug 5, 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)

(NOTE TO SELF — do not paste this line into the form. Before ticking box 1, see the "Additional Context" section below: there are adjacent issues about model selection and silent downgrades, but none I found covers per-agent model/effort attribution in the web UI. Sanity-check the list against current search results.)

---

Problem Statement

I run Claude Code on the web with a top-tier model as the orchestrator (currently Fable 5) and expect the actual work to be delegated down to Opus 5 or Sonnet 5. The orchestrator is worth paying for; having every subagent run at that tier is not.

Two settings determine what a delegated agent costs: which model it runs on, and what effort level it runs at. Neither is visible in the web UI once work leaves the main session.

The problem is that I can't tell what's actually happening. The web UI shows the model I selected for the session, but once work is delegated to a subagent or a multi-step workflow, nothing in the interface says which model — or which effort level — is executing that unit of work. Delegated agents appear to inherit the parent's settings when I don't explicitly pin them, so a single ambiguous prompt can silently fan out N top-tier, high-effort subagents across a repo.

That failure mode is invisible in three separate ways:

  1. Nothing before the run. Delegation is decided mid-run, so there is no point at which I'm told "this is about to execute on Fable at high effort."
  2. Nothing during the run. The agent card already carries a metadata line — elapsed time, token count, tool-use count, tool names, a link to the transcript. Every expensive dimension of the run is reported except the two that set the unit price. By the time a run looks expensive, the tokens are already spent.
  3. Nothing after the run. As far as I can tell from the UI, the transcript records that a subagent ran, not what model or effort it ran at — so I can't audit a session after the fact either.

There's precedent for treating this as a real defect rather than a nicety: 2.1.222 fixed the spinner's effort label in a subagent's transcript view showing the session's effort instead of the subagent's own effort: setting. That's exactly the bug class I'm describing — the UI reporting the parent's configuration in place of the child's — and it was worth fixing there. On the web agent card the same information isn't wrong; it's simply absent, for both effort and model.

The net effect is that the cheapest-orchestration-plus-cheap-workers pattern can be requested but never confirmed. I find out what tier and effort the work ran at when I look at usage, which is far too late to change the decision. For anyone routinely mixing tiers in one session, this turns an ordinary prompt into an unbounded and unobservable spend.

---

Proposed Solution

**Attribute every unit of work to a model and an effort level, visibly, in the Claude Code web UI.**

Concretely:

  • A model tag and an effort tag on the agent card, next to the Agent label. The card already has the right slot for them — the header line reads Agent · 1m 42s, with 59.3k tokens · 12 tool uses · Read · View transcript underneath. These are two fields added to an existing, already-populated component, not a new surface:

```
before: Agent 1m 42s
59.3k tokens 12 tool uses Read View transcript

after: Agent [Sonnet 5 · high] 1m 42s
59.3k tokens 12 tool uses Read View transcript
```

Always visible — not behind a hover, not inside the expanded detail view, not only in the transcript. The value of seeing it is that I catch it without looking for it.

If only one of the two can ship, model is the more urgent half — it moves cost by a larger multiple. But they're the same field group on the same component, and effort is already tracked per-subagent (see the 2.1.222 fix above), so splitting them seems like more work than shipping both.

  • Visually distinct treatment for the top tier, so an unintended Fable agent registers in peripheral vision instead of requiring a deliberate read of each row. A colour or outline difference is enough; it doesn't need to be an alert. Same for the top effort levels.
  • Model and effort recorded in the transcript at the point a subagent is spawned and where it returns, so a completed session can be audited without guessing.
  • Session header shows the orchestrator's model/effort and the effective subagent defaults as separate values, since they can legitimately differ and today only the session's own setting is shown.

Nice to have, same surface, if it's cheap to include:

  • The per-agent token count is already displayed — pairing it with the model and effort tags makes it interpretable, since 59.3k tokens means very different things at different tiers and effort levels.
  • A session-level rollup grouped by model, e.g. Fable 5: X tokens · Sonnet 5: Y tokens, so spend is attributable to a tier at a glance.

The ask is scoped to display. I'm not asking for the routing or effort-inheritance behaviour itself to change in this issue — just for both to be observable.

---

Alternative Solutions

What I do today (and why it doesn't work):

  • Name the model explicitly in the prompt ("delegate this to Sonnet"). Works when I remember, silently fails when I don't, and I can't verify it was honoured because there's nothing to verify against.
  • Split into separate sessions per tier. Kills the point of orchestration and adds a lot of manual context ferrying.
  • Check usage after the fact. Detects the problem only after paying for it, and doesn't tell me which agent was responsible.
  • Just avoid the top tier as orchestrator. This is what I actually end up doing when I'm cost-sensitive, which means the feature I'm paying for goes unused because I can't trust the delegation boundary.

Adjacent designs I considered instead of a badge, and why I'm not asking for them here:

  • An explicit defaultSubagentModel setting, so delegation never silently inherits the orchestrator's tier (inheritance is a fine default for downgrades and a dangerous one for upgrades). The same argument applies to a defaultSubagentEffort.
  • A maxSubagentTier cap, or a one-time confirmation when a delegated agent would exceed the configured default in either dimension.

Both would prevent the problem rather than merely reveal it, and I'd file either happily. I've left them out of the request because they're behaviour changes rather than a UI change, and because visibility is the smaller, cheaper fix that makes the rest diagnosable. If maintainers would rather solve it at the config layer, I'm glad to open that separately.

---

Priority

High - Significant impact on productivity

---

Feature Category

Other

(No Web / cost-visibility category exists in the dropdown; "Other" is the closest fit. Worth saying so in the body so triage relabels rather than assumes.)

---

Use Case Example

A concrete run from last week:

  1. Open Claude Code on the web, session model set to Fable 5, because I want a strong planner for a refactor spanning ~40 files.
  2. Prompt: "Audit every module under src/ for the deprecated config API and produce a migration plan."
  3. The orchestrator decides to fan out — one agent per module group, several running in parallel. This is the right plan and I want it.
  4. The run panel fills with agent rows: names, statuses, spinners. No model and no effort level shown on any of them. I assume the fan-out went to a cheaper tier, because that's what I'd have asked for if I'd been asked.
  5. Run completes. Good output. I move on.
  6. Later, checking usage, the numbers are much higher than a Sonnet fan-out would explain. There's no per-agent breakdown, so I can't confirm what happened; I can only infer that the subagents inherited the orchestrator's model and effort.

With the proposed feature, step 4 is the whole fix: I see Fable 5 · high on twelve parallel agent rows, stop the run within seconds, re-prompt with an explicit delegate model, and the fan-out costs a fraction of what it did. The decision point moves from "after the invoice" to "three seconds into the run" — and that's the entire value of the request.

The same shape shows up whenever the orchestrator is a different tier from the workers, which for me is most non-trivial sessions.

---

Additional Context

Possibly related existing issues (all touch model selection, none appear to cover per-agent model attribution in the web run panel — worth linking so triage can dedupe or merge):

  • #24109 — model configuration command and new-model notifications
  • #36835 — model selection via /model not applying to the current conversation
  • #66266 — effort/model selection not persisting across chats
  • #67620 — model upgrade/downgrade notifications and explicit model selection
  • #74654 — unexpected automatic tier switching involving Fable

Those are about choosing a model for the main session, or about the session's model changing under the user. This request is about seeing the model and effort on delegated agents in the web UI, which is a different surface and, unlike the above, is purely additive display.

Prior art in the changelog — two 2.1.222 entries suggest this is already recognised as a problem class, just not on this surface:

  • The fix for the subagent transcript spinner showing the session's effort level instead of the subagent's own effort: setting. Same failure mode as this request (parent's config displayed in place of the child's), already accepted as a bug worth fixing.
  • The fix for opus-style subagent and teammate family aliases dropping to the parent model under org model restrictions. Confirms that subagent-inherits-parent is a real code path with real cost consequences, not just my inference from usage numbers.

If effort is already tracked per-subagent well enough to fix a mislabelled spinner, surfacing it on the web agent card should be cheap.

Technical notes:

  • Model and effort are both necessarily known at the point the subagent is dispatched, so this should be a plumb-through to the UI rather than new state.
  • Terminal Claude Code has /status and /cost as partial escape hatches; the web UI has no comparable per-agent view, which is why this is filed against web specifically.
  • Screenshot attached of a completed agent card. It reports elapsed time, token count, tool-use count, the tools touched, and a transcript link — five pieces of telemetry, and neither of the two settings that determine what those tokens cost. The component that would host these tags already exists and is already populated.

Environment:

  • Surface: Claude Code on the web
  • Models involved: Claude Fable 5 (orchestrator), Opus 5 / Sonnet 5 (intended delegates)
  • Effort: session-level setting; subagent effort not visible, so unknown

View original on GitHub ↗