fix(web): allow switching away from Ultrathink without manual prompt editing

[Marve10s]

Summary

• When Ultrathink was active, the effort dropdown was fully disabled and showed "Remove Ultrathink from the prompt to change effort." — forcing the user to manually edit the prompt to switch effort levels.
• Now selecting a different effort level automatically strips the Ultrathink: prefix from the prompt and applies the new effort.
• The radio group correctly highlights "Ultrathink" when it's active via the prompt.

Test plan

• Select Claude Opus/Sonnet, choose Ultrathink from effort dropdown — prompt gets Ultrathink: prefix
• While Ultrathink is active, select a different effort (e.g. High) — Ultrathink: prefix is removed, effort switches
• Re-select Ultrathink — prefix is added back
• Verify compact composer controls menu behaves the same way

Note

Allow switching away from Ultrathink effort without manual prompt editing

• When Ultrathink is active via a prompt prefix, the Effort menu is now fully interactive instead of showing a disabled state with an instructional message.
• Selecting a non-Ultrathink effort strips the ultrathink prefix from the prompt (case-insensitive, word-boundary regex) and applies the new effort setting via onPromptChange.
• Selecting the Ultrathink effort inserts the prompt prefix as before.
• Behavioral Change: the handleEffortChange callback in ClaudeTraitsPicker.tsx no longer early-returns when ultrathinkPromptControlled is true, so prompt mutation now happens automatically on effort switch.

^{Macroscope summarized aa6cd57.}

---

Note

Low Risk
Low risk: small UI/UX behavior change limited to Claude effort selection; main risk is incorrect prompt stripping via regex leading to unexpected prompt edits.

Overview
Improves Claude Effort switching when Ultrathink: is present in the prompt. The Effort menu is no longer disabled or showing the “remove Ultrathink…” message; instead it remains interactive, highlights Ultrathink as the active radio value when prompt-controlled, and strips the ultrathink prefix from the prompt when the user selects a non-ultrathink effort.

Updates browser tests for both ClaudeTraitsPicker and CompactComposerControlsMenu to reflect the new selectable behavior and removal of the prior messaging.

^{Written by Cursor Bugbot for commit 2a3c003. This will update automatically on new commits. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: b980b31f-e751-46ae-8da4-20861fb13f8b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[juliusmarminge]

screenshot/video w/ before/after pls

also, i considered this but the ultrathink can be anywhere in the prompt and i didn't wanna do a eager find-replace and mutate the users prompt, but aybe i was wrong

[Marve10s]

@juliusmarminge here you go:

Before :

zen_Bfbs8zBqAN.mp4

After :

zen_Nrpw8JqT6F.mp4

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Strip regex doesn't fully clear detection, causing state inconsistency

Low Severity

The stripping regex /\bultrathink\b:?\s*/i only removes the first occurrence of "ultrathink" (no g flag), but isClaudeUltrathinkPrompt detects it anywhere via /\bultrathink\b/i. If a prompt contains "ultrathink" more than once — e.g. the UI-added Ultrathink: prefix plus a natural occurrence in the body text — stripping removes only the prefix while the remaining occurrence keeps ultrathinkPromptControlled true on the next render. The radio group then still displays "Ultrathink" as selected, but setProviderModelOptions already changed the stored effort, creating an inconsistent UI/state.

 

[Marve10s]

The g flag deletes all instances of "ultrathink" from the user prompt.

Example

Input prompt: "Ultrathink: please ultrathink about this problem"

Without g flag

When switching away from ultrathink:

• Strip result: "please ultrathink about this problem"
• isClaudeUltrathinkPrompt still detects "ultrathink" → UI stays on "Ultrathink" (Bugbot's inconsistency)
• User's natural text is preserved

---

With g flag

Same prompt: "Ultrathink: please ultrathink about this problem"

When switching away from ultrathink:

• Strip result: "please about this problem"
• isClaudeUltrathinkPrompt returns false → UI correctly switches
• User's sentence is now mangled

I still think current version is better, we only targeting ultrathink that t3 code provides in the prompt, not written by user manually.