fix: maintain reasoning selections for multiple providers#2760
fix: maintain reasoning selections for multiple providers#2760adambuchweitz wants to merge 1 commit into
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Fix reasoning selections to persist per provider instance across multiple providers
Macroscope summarized 9b5d554. |
ApprovabilityVerdict: Approved Straightforward bug fix that changes how model options are keyed from provider to instance ID, allowing multiple instances of the same provider to maintain separate reasoning selections. The change is well-scoped with a test and doesn't affect sensitive code paths. You can customize Macroscope's approvability policy. Learn more. |
215044b to
9b5d554
Compare
What Changed
Fix secondary Codex reasoning selection by threading the instance ID instead of just the provider.
Codex reasoning options have to follow the configured provider instance, not the driver kind. Otherwise multiple Codex accounts collapse into codex and secondary-account choices can fail to stick.
Here's an HTML code tour, because it's fun: https://lp-tours.up.railway.app/d/99a0303e-58e1-4ae6-9e47-3568830c62fc
Why
The composer could display or persist traits through ProviderDriverKind, such as codex, even when the active provider was a distinct ProviderInstanceId, such as "codex_work"
The practical ramifications are that I would set reasoning to Low but it would send it as Extra High, costing me precious tokens.
UI Changes
None
Checklist
Note
Medium Risk
Changes how composer model options are keyed and persisted (from driver kind to instance id), which could affect saved draft/sticky selections and active provider behavior across threads/instances.
Overview
Fixes composer traits/model-option handling to be instance-aware so multiple configured accounts under the same provider driver (e.g. Codex) don’t overwrite each other.
ChatComposerand traits rendering now passinstanceIdthrough and readcomposerModelOptionsviaselectedInstanceIdinstead ofselectedProvider.TraitsPickerandcomposerProviderStatethreadinstanceIdinto persistence calls.useComposerDraftStore.setProviderModelOptionsnow accepts an optionalinstanceIdto write selections under that instance key and, when provided, updates draft/stickyactiveProvideraccordingly; tests add coverage for storing option changes on a custom instance.Reviewed by Cursor Bugbot for commit 9b5d554. Bugbot is set up for automated code reviews on this repo. Configure here.