Show which model each message was sent with and answered by

[nico-stever]

Why this is worth having: the model picker can silently fail to apply — that's #981, still open, with several fixes proposed — and while it does, there is no way for a user to find out. You change the model, the UI acknowledges it, and the conversation keeps running on the previous one. I only discovered it had been happening for days on my own instance because I added the label described below and could suddenly see it: sessions I was certain were on one model had been answering with another the whole time.

The underlying reason the UI can't tell you is structural, and outlives that bug. Model selection is per conversation, but the picker's displayed value comes from a single global localStorage key, and there is no GET endpoint to ask the server which model a given session is actually pinned to. So the UI can tell you what you selected; it can never tell you what actually ran. Even with #981 fixed, switching between conversations shows one value while each conversation runs its own pin.

It also hides the case where it matters most: when a turn fails because a model's quota is exhausted, there is no assistant response carrying a model at all, so nothing on screen says what the request went out as — which is exactly the moment you want to know.

So this is a mitigation while the picker bug is open, and a verification mechanism after it's closed.

Proposal: render a small label next to the existing MD / TXT chip in the message footer — Opus, Fable, Sonnet, Haiku — on both sides of the exchange. They answer two different questions and both are needed.

On the user's message — what the request went out with

This is the half that tells you whether your picker change actually applied, and it's the only one that survives a failed turn.

Transcript user events carry no model (0 of ~840 in my install), so it has to come from the server: the resolved value that gets passed as --model for that turn. Recording it per turn and joining it on history fetch covers every turn, including ones that die before any response — which the response-side label cannot.

Two things to get right here:

• Don't label the optimistic client-side bubble with the picker's value. When a session pin exists, that value is exactly the one that is wrong, so it would reproduce the misreporting this is meant to remove. It also gets pruned against the transcript when the turn completes, so a label placed there disappears seconds later — precisely in the failure case.
• Don't collapse opus and opus[1m] (or sonnet / sonnet[1m]) into one label. Distinguishing them is the whole point: it's what tells a user whether the change they made in the picker took effect.

On the assistant's message — what answered

The data already exists: every assistant event in the transcript carries message.model. Carrying it through the normalizer makes it available with no migration and it renders retroactively, because history is re-read from the transcript on every open. Around 1500 assistant events in my install all had it.

Worth knowing before implementing: a large share of assistant events are tool-call turns with no text part, so they produce no footer and therefore no label. Coverage on this side is partial by construction — which is another reason the request-side label matters.

Edge cases

• Events whose model is <synthetic> (local CLI notices, e.g. quota errors) should get no label rather than a guessed one — no model produced them.
• Deriving the request label from the following assistant event is tempting and should be avoided: it fails on exactly the aborted turns this is meant to surface, and it silently attributes a later turn's model to an earlier request.
• If a per-turn record is missing, showing nothing is much better than showing the previous turn's model — the stale value is confidently wrong about the one question the label exists to answer.

I have a working implementation of both halves and am happy to open a PR if the approach looks right. Following CONTRIBUTING, opening this first to discuss before investing in the PR.

---

Implemented and verified with Claude Code (Opus 5) against v1.36.3. The counts above are from my own install.

[coderabbitai]

🔗 Related PRs

#762 - feat: add opencode support [merged]
#943 - feat: add Claude and Codex effort controls [merged]
#998 - fix model select and display issue [open]
#1047 - fix: apply and display mid-session model changes (#981) [open]
#1056 - fix: skip Claude's placeholder when reading transcript models [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[nico-stever]

Implementation is ready if it's useful — branch here, against main at v1.36.3:

main...nico-stever:feat/per-message-model-label — 6 files, +207/-3.

file	what it does
server/shared/utils.ts	per-turn record of the resolved model (atomic write, serialized, bounded lookup)
server/claude-sdk.js	records sdkOptions.model once at turn start, fire-and-forget
claude-sessions.provider.ts	carries message.model onto assistant text rows; joins the turn record onto user rows in fetchHistory
useSessionStore.ts	model?: string on the normalized message
useChatMessages.ts	one line — model into sharedMetadata
MessageComponent.tsx	the two labels and their helpers

No new transport and no type changes beyond that one optional field: the value rides the existing normalized-message path, which is already an open-index record end to end.

A few notes for review:

• The two labels are deliberately not the same function. The assistant side matches by family (claude-opus-5 → Opus) so point releases need no upkeep. The user side prints the exact alias (opus[1m] → Opus 1M), because collapsing that is what would make the label useless for its main purpose.
• The lookup is bounded in time. If a turn record is missing, the naive "last record at or before this timestamp" returns the previous turn's model — confidently wrong about exactly the thing being asked. Past a 5-minute gap it returns nothing instead.
• Writes are serialized and use tmp+rename. Read-modify-write of a whole file from one process; a history read landing mid-write would otherwise return the conversation with no labels at all.
• Retroactivity is asymmetric and that's inherent. Assistant labels appear on all existing history for free, because the transcript already has the data. User labels only exist from the moment the runtime starts recording — the transcript's user events carry no model and inferring it from the next assistant event fails on precisely the aborted turns this is meant to surface.

npm run build and both typechecks pass on a clean checkout of v1.36.3 with only these 6 files modified.

Happy to open it as a PR, rebase it, or split the two halves into separate PRs if you'd rather take them independently. Also happy to leave it here if the approach isn't what you want — no attachment to this particular shape.

---

Implemented with Claude Code (Opus 5) and running on my own instance.