fix(web): let new threads honor the project's default model - #7551
fix(web): let new threads honor the project's default model#7551KyeMoon123 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 Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 4dab31b. Configure here.
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This is a focused bug fix that adds fallback logic to honor project default model selections in new threads. The changes are additive, well-commented, and follow existing patterns in the file. The scope is limited to model selection defaults in thread creation. You can add or adjust custom eligibility rules. Learn more. |
4dab31b to
ef011be
Compare
New threads were seeded from the global "sticky" last-used model (applyStickyState) and only fell back to the project's configured defaultModelSelection when no sticky value existed at all — which in practice only happens on a user's very first thread ever. As a result, the project setting "New threads in this project start with this model" was effectively never applied once any thread anywhere had already picked a model. Apply the project default whenever there's no carried selection from a currently-viewed thread/draft to take priority instead, across all three new-thread paths: minting a genuinely fresh draft, reusing a stored-but-empty draft, and reusing the empty draft already open.
ef011be to
75b13e3
Compare
|
Note 🤖 GPT-5.6 Sol responding on behalf of Theo We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together. Closing this narrower project-default fix because it still lets a carried model override the project default. #7515, #6593, and #6011 cover the precedence choice more directly and remain open. Keep the fresh and reused draft cases in the selected implementation. If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look. |

Summary
ProjectSettingsPanel.tsx, writesproject.defaultModelSelection) was effectively never applied once any thread anywhere had picked a model.applyStickyState(draftId)inuseHandleNewThread.ts, which pulls from a global, provider-keyed "last used model" (stickyModelSelectionByProviderincomposerDraftStore.ts) — not scoped to project or thread. The project default was only ever consulted as a last-resort fallback that's effectively dead once the sticky map is populated (i.e. after the user's very first thread ever).project.defaultModelSelectionwhenever there's nocarryModelSelection(i.e. no thread/draft currently being viewed to intentionally carry a selection from), across all three new-thread code paths in the hook:Test plan
pnpm run typecheck(apps/web) — passespnpm run lint -- apps/web/src/hooks/useHandleNewThread.ts— passesNote
Fix new threads to honor the project's default model selection
In useHandleNewThread.ts, when creating or reusing an empty draft without a carried model selection, the handler now applies
project.defaultModelSelectionwithreplaceOptions: trueto the target draft. This covers three cases: reusing an existing empty draft for a project remap, staying on the current route's empty draft during a context update, and creating a brand new draft.Risk: The project default overrides any previously stored selection or sticky state on empty drafts.
Macroscope summarized 75b13e3.
Note
Low Risk
Behavior change is limited to new/reused empty draft initialization in one hook; no auth, persistence, or server API changes.
Overview
New threads in a project now honor the configured default model when the user isn’t carrying a selection from the thread they’re viewing.
useHandleNewThreadalready seeds drafts from global sticky “last used model” state and only overrides that whencarryModelSelectionis present. This change adds the same kind of override forproject.defaultModelSelectionin three paths: resurrecting an empty stored draft, reusing the empty draft already open for that project, and minting a brand-new draft afterapplyStickyState. In each case it runs only when there is no carried selection, and usessetModelSelectionwithreplaceOptions: trueso the project default is a full snapshot (not merged with stale draft options).Precedence is unchanged for carry-over: if the user is viewing a thread/draft with a model, that selection still wins over both sticky state and the project default.
Reviewed by Cursor Bugbot for commit 75b13e3. Bugbot is set up for automated code reviews on this repo. Configure here.