feat: add toggleable sticky modes setting

[atlasgong]

Context

I find the sticky modes feature annoying, and this PR adds a way to turn it off. It adds a new MiscellaneousSettings section in Roo Code's settings, and adds the checkbox toggle under it for the stickyModesEnabled setting. It is checked by default to maintain backwards compatibility.

Implementation

I used (copied) the existing NotificationsSettings section and ttsEnabled setting as a template for the MiscellaneousSettings section and stickyModesEnabled setting, respectively. Translations were added with Roo Code's native Translate mode.

Screenshots

How to Test

I've updated the test suite in ClineProvider and all tests pass. To manually test:

1. Go to Roo Code's settings, note that Enable sticky modes is checked.
2. Go back to the chat. Select a mode and model.
3. Select a different mode and different model.
4. Swap back to the old mode and note it's sticky, just as it was before this PR.
5. Go to the settings and uncheck Enable sticky modes.
6. Swap back and forth between all modes and note the choice of model remains unaffected.

Get in Touch

Discord: nineatlas

---

Important

Adds a toggleable stickyModesEnabled setting to Roo Code, allowing users to enable or disable sticky modes, with UI integration and translations.

• Behavior:
  • Adds stickyModesEnabled setting to toggle sticky modes in ClineProvider.ts.
  • Default is enabled for backward compatibility.
  • When disabled, modes do not remember the last used model.
• UI:
  • Adds MiscellaneousSettings.tsx for the new setting in the settings UI.
  • Integrates new setting into SettingsView.tsx.
• State Management:
  • Updates state handling in ClineProvider.ts to respect stickyModesEnabled.
  • Adds tests in ClineProvider.test.ts for new setting behavior.
• Translations:
  • Adds translations for the new setting in multiple language files including settings.json for ca, de, en, es, fr, hi, it, ja, ko, pl, pt-BR, tr, vi, zh-CN, zh-TW.

^{This description was created by for d0a8568. You can customize this summary. It will automatically update as commits are pushed.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: d7bc0cd

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ellipsis-dev]

Typographical suggestion: In the 'stickyModes' description, it currently reads "Quando ativado, o Roo lembrará o último modelo usado para cada modo...". This may be confusing because 'sticky modes' implies retaining a mode, not a model. Consider changing 'modelo' to 'modo' for clarity.

Suggested change

	"description": "Quando ativado, o Roo lembrará o último modelo usado para cada modo e o selecionará automaticamente ao retornar a esse modo."
	"description": "Quando ativado, o Roo lembrará o último modo usado para cada modo e o selecionará automaticamente ao retornar a esse modo."

^{This comment was generated because it violated a code review rule: mrule_JLtLS6tLppVEv8iV.}

[mrubens]

Hey, thanks for the PR. I'd love to discuss a little more what makes the stickiness annoying. For me a big part of the mental model is that each mode has its own associated provider, so I'm hesitant to change that or make it an option. Want to pick this up in Discord?

[sachasayan]

@mrubens I can get what's going on here. Say you're switching gears from a high-demand programming task in Gemini Pro 2.5, and editing some json or whatever. So you switch to architect mode and, and toggle to a low-grade model — say Flash 2.0. Your coding mode will still 'sticky' to 2.5 Pro, so when architect mode automatically switches back into code mode, you're back on Pro 2.5. This can be a little confusing, because the UI is now fighting you.

I think an illustrative alternate solution here would be a little checkbox to 'pin' a model while you're working. So while you have Flash 2.0 'pinned' it will persist across all modes.

Is this what you're thinking, @atlasgong ?

[atlasgong]

@sachasayan You're spot on. I can definitely see how sticky modes might be preferred by the average user, and for that reason the checkbox remains checked by default, and merging this PR would not affect those users. It does feel like I'm fighting with the UI at times; if I wanted to switch models I would do it myself.

I think adding a checkbox to pin a model is interesting, definitely worth exploring, but I'm curious where you think it should live in the UI. My thought process behind adding the "Miscellaneous" section was that the sticky modes setting would be out of sight and undisruptive to the average user, but would provide more configuration to those who wish to dig deeper into the settings.

Happy to pick this up on Discord too if it requires deeper discussion.

[sachasayan]

@atlasgong Maybe here? I'm thinking just a little button with an active and inactive state. Very minimal, no label. Just a square button in-line with the other buttons and with a tooltip.

Any chance you'd be willing to prototype this up?

Also, try the Lucide (we're migrating from codicons!) lock and unlock icons, let me know if those feel better than a pin to you:

https://lucide.dev/icons/lock-open

https://lucide.dev/icons/lock

[atlasgong]

@mrubens thoughts before I execute? Is it alright if the infrastructure remains the same? i.e. no changes would be made to the backend, we'd just discard the miscellaneous section and "move" the checkbox to where @sachasayan suggested.

Also maybe https://lucide.dev/icons/pin and https://lucide.dev/icons/pin-off would be clearer than the lock icons?

[sachasayan]

@atlasgong I'm taking point on this one, you're good to go as long as you also think it's a good idea. :)

Worth thinking about: What happens when you unpin/unlock the currently locked-in model? Does it revert to the previously set model for that mode, or do we just keep persisting the current model? I think we keep persisting, but open to hear your opinion. ✌️

[sachasayan]

@atlasgong Another thing to consider: What happens when the window gets too narrow? Just make sure it truncates gracefully. :)

[atlasgong]

Worth thinking about: What happens when you unpin/unlock the currently locked-in model? Does it revert to the previously set model for that mode, or do we just keep persisting the current model? I think we keep persisting, but open to hear your opinion. ✌️

Do you use sticky modes yourself? I'm thinking someone who likes it might have a specific setup they use, e.g. an expensive reasoning model for architect, a faster model for ask, maybe a non-reasoning model for code, etc. In that case, if they wanted to deviate from this setup temporarily and "pin" a specific model, it would be for some specific irregular reason. When they unpin the model, it should return to their regular expected workflow, so it should restore to the previously set model for the respective mode. Of course, there may be another perspective I'm not seeing.

Another thing to consider: What happens when the window gets too narrow? Just make sure it truncates gracefully. :)

Maybe we should consider branching off into two rows in that case? One for the mode and model and one for the icons?

[sachasayan]

Of course, there may be another perspective I'm not seeing.

The other perspective I see is that if you 'unpin' a model, it doesn't necessarily mean you want to go back to another model. You might not even remember what that model was. If I 'pin' a model and leave it like that and after a month I unpin.... do I go back to whatever models I was using before? A month ago? I might not even remember I was using other models.

Also, what does a re-pinning interaction look like?

Let me throw a paradigm shift on the stack to help frame the use case and possible modes of interaction:

Are we really after a configurable "Special Model" button which you can temporarily turn on and off and which is always set to the same model (ie, G.25Pro) rather than borrowing from whatever the current mode is set to?

[atlasgong]

Are we really after a configurable "Special Model" button which you can temporarily turn on and off and which is always set to the same model (ie, G.25Pro) rather than borrowing from whatever the current mode is set to?

What do you think of the pin button having a similar dropdown(up?) menu to that of the model selection menu? It would still remain toggleable, e.g. unpinned state would have the Pin-Off icon and be greyed out, then the model selection menu would pop up when you toggle it to the "Pin" state.

[atlasgong]

On second thought, I think that would introduce too much complexity; the original implementation seems cleaner and easier to understand to me. Maybe sticky modes doesn't bother anybody else, so I'm happy to keep this PR stale for a bit and see if there are any other complaints, and if not then I'll close it.

[pdecat]

I'd love having the ability to disable this sticky mode. This is especially not desired when in Architect mode, the LLM asks to switch to Code, and approving that request also switches the model.

[sachasayan]

@atlasgong I think you're not the only one who wants some kind of toggle or escape hatch here, it's a great idea. Just wanted to forward some alternate implementation ideas. Which one did you like best?

[atlasgong]

@atlasgong I think you're not the only one who wants some kind of toggle or escape hatch here, it's a great idea. Just wanted to forward some alternate implementation ideas. Which one did you like best?

My goal with the current implementation was to place the setting deep enough in the configuration that it wouldn't impact the majority of users, while still providing a toggle for the small minority who might care. Adding a "Special Model" button would introduce an entirely new feature, separate to the sticky modes feature, which would require more discussion and would be better suited for a separate PR. The original intention of this PR was simply to offer an option to disable an existing feature.

[James-Cherished]

Hey, thanks for the PR. I'd love to discuss a little more what makes the stickiness annoying. For me a big part of the mental model is that each mode has its own associated provider, so I'm hesitant to change that or make it an option. Want to pick this up in Discord?

Nice PR. I was looking for this for a while. I had just created a feature request to bring this up, I'll reference it here in regards to your question: #3615

[hannesrudolph]

@atlasgong Thanks for submitting this PR, and our sincere apologies for letting it sit for so long. This was a great idea, and we definitely should have responded sooner.

We're closing this now because the code has become outdated due to recent changes. If you're still interested (and we hope you are!), please open a new issue using our issue-first approach. This allows us to clearly review and agree on the exact implementation details, like precisely where and how control mechanisms should be structured, before starting development.

We genuinely appreciate your patience and enthusiasm and would love to see this move forward.