Repository navigation
[Bug]: Composer model and effort controls read as one label ("Opus 5.5 High") #26989
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- Update to the latest nightly (or run
main). - Open any thread and pick Claude Opus 5.5 with effort High. Any model and effort show the same problem.
- Look at the controls at the bottom right of the composer.
Expected behavior
You can tell at a glance that there are two controls, the model picker and the reasoning effort menu, and which word belongs to which.
Actual behavior
Since #25869 ("simpler composer with grouped controls, effort words…"), the effort level follows the model name as a plain, muted word at normal word spacing. #24865 had already removed the divider lines between composer controls. Together, the composer now reads "Opus 5.5 High", as if "High" were part of the model name:
- There is no divider, icon, chevron or hover box to show where one control ends and the next begins. Only the slightly dimmer color of "High" sets it apart, and that difference is easy to miss in dark mode.
- The two click targets touch, and their hit boxes overlap by about 2 px. Clicking near "5.5 High" opens either the model picker or the effort menu, and you can't predict which.
- It gets worse with model names that end in a version or a word, for example
6 Astra Medium(Codex default) orOpus 5.5 Extra High.
The opt-in Settings › Appearance › Effort display = Bars helps, but it is off by default, and Max, Ultracode and Ultrathink still show as words.
Suggestion
Give the effort control its own visual anchor by default, while keeping the calm one-row look. Two lightweight options, mocked up on the same composer:
- A: a hairline divider between model and effort.
- B: a small leading icon on the effort control (the gauge feat(web): UI design overhaul, with the new look behind a Beta toggle #24865 introduced; open PRs feat(web): effort indicator shows the selected reasoning level #25431 and feat(web): gauge option for the composer's effort display #26802 already build on it).
(Ideas A and B are mockups made by editing the DOM of the real composer. They are not implemented.)
Impact
Minor bug or occasional failure
Version or commit
Desktop 0.1.5-nightly.20261029.3877; also reproduced on main @ 37fbefd
Environment
Linux Mint 22.3, desktop AppImage, dark theme; reproduced in the web dev build (vp run dev) with Claude Opus 5.5 · High and Codex GPT-6-Astra · Medium.
Workaround
Settings › Appearance › Effort display → Bars.
Activity
RostyslavDzhohola commentedon Oct 29, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of RostyslavDzhohola
+1. I hit both problems this issue describes in daily use on nightly.
I'd vote for option B, on by default rather than behind Settings › Appearance: give effort an icon, the same way the model has its provider icon. The old gauge made the control easy to spot. Even better, keep that gauge and move its needle to the selected level (as #25431 and #26802 do), so one icon both marks the control and shows the level at a glance.
wagner-deoliveira commentedon Oct 30, 2026
A pointer for the hit-box overlap described above: in
TraitsPicker.tsxthe effort trigger gets-ms-1 ps-0(-ms-1 ps-0.5without the word) when the composer owns the row. The comment next to it says this cancels the model chip's end padding and the row gap so the effort word reads on from the model name. A 4 px negative margin is a likely source of the two click targets running into each other.I run
-ms-0.5locally to keep the "Opus 5.5 High" look with a little less pull. I haven't measured the hit boxes or captured before/after, so treat this as a lead to check, not a verified fix. It also doesn't address the readability point, which the icon or divider in the issue would.Posted with Claude Code (Sonnet 5.5).