Skip to content

vendor: adopt upstream PR #7515 (new threads honor the project default model) - #6

Closed
Jardo-51 wants to merge 1 commit into
custom/mainfrom
custom/upstream-pr/7515-project-default-model
Closed

vendor: adopt upstream PR #7515 (new threads honor the project default model)#6
Jardo-51 wants to merge 1 commit into
custom/mainfrom
custom/upstream-pr/7515-project-default-model

Conversation

@Jardo-51

Copy link
Copy Markdown
Owner

Adopts unmerged upstream PR pingdotgg#7515 ("fix(web): new threads honor the project default model", fixes upstream issue 5796).

What it changes

useNewThreadHandler now resolves project.defaultModelSelection ?? carryModelSelection and applies that override on all three draft seed paths (empty stored draft, reuse of the viewed empty draft, mint-fresh). A project's configured default model beats both the globally sticky last-used pick and the selection carried from the viewed thread; projects without a pin keep the current sticky + carry behavior, and explicit composer picks still win.

One file, apps/web/src/hooks/useHandleNewThread.ts, +31/-15.

Review flags

Nothing security-relevant: no network calls, telemetry, or credential handling; no process spawning or permission/sandbox/auth logic; no new dependencies, postinstall scripts, or CI changes; no version fields touched.

Worth knowing behaviorally: the pin includes the provider instance, so this changes which subscription a new thread starts on when a project has a default model configured. That is the point of the fix, but it is a user-visible change in where work gets billed.

Verification

  • vp test run apps/web/src/composerDraftStore.test.ts apps/web/src/threadRoutes.test.ts — 90 passed
  • vp lint apps/web/src/hooks/useHandleNewThread.ts — clean
  • vp run --filter @t3tools/web typecheck — clean
  • Checked for semantic duplication: defaultModelSelection appears exactly once in useHandleNewThread.ts; no second resolution path was introduced alongside an existing one.
  • Confirmed the draft-reuse path's no-op claim holds: with currentRouteTarget.kind === "draft", carryModelSelection resolves to that draft's own composer selection, so the unpinned write is genuinely a no-op.
  • The file is byte-identical between main and custom/main, so the patch applied in the same context it was written against.

Not verified: no integrated pass in a real client (no browser run). The upstream author reports testing new threads across two Claude instances with opposite project pins in both directions.

No fork-specific fixup commits were needed — the cherry-pick is patch-identical to upstream's commit.

Adoption note

This is adopted third-party code, unreviewed upstream and permanent by default in this fork: do not revert it to make a future sync easier. When upstream lands its own version, resolve the conflict toward upstream's version wholesale and re-apply any local adaptations as a separate commit.

@Jardo-51

Copy link
Copy Markdown
Owner Author

Closing in favor of pingdotgg#6011 which was already merged to upstream.

@Jardo-51 Jardo-51 closed this Aug 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants