[Bug]: New thread reopens an empty draft's old model pick (e.g. Extra High) instead of the configured default #36408

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Settings → Threads → New threads → Model: set Claude Opus 5.5, High.
2. Open a project that already existed when the page loaded (call it A). Start a new thread there. The composer shows Opus 5.5 High.
3. Type nothing. Change the effort in the composer to Extra High.
4. Open a thread in another project B. Reload the page (or restart the desktop app).
5. Open the command palette → New thread in… → A.

Note on step 2: a project added in the current page session can have its new-thread draft re-keyed on the next reload. The repro then starts over with a fresh draft, so use an existing project.

Expected behavior

The new thread in A starts on the configured default, Opus 5.5 High.

The draft holds no text and no attachments, only a model pick. Clicking New thread should not reopen an earlier abandoned pick as if it were unsent work.

Actual behavior

The new thread opens on Opus 5.5 Extra High.

The stored draft in localStorage (t3code:composer-drafts:v1) has prompt: "", no attachments, effort: "xhigh" and modelSelectionExplicit: true. That pick then stays for that project, in that browser profile or desktop install, until the user changes it or sends the draft:

• useHandleNewThread.ts:305-317 reuses the empty stored draft. When hasExplicitComposerModelSelection(storedDraft) is true, it skips re-applying the configured default.
• stripLegacyModelSeedsFromEmptyDraftSessions (composerDraftStore.ts:2229-2248) keeps explicit picks on empty drafts across reloads.
• There is no age-based pruning.
• Changing the default in Settings does not touch existing drafts.
• The picker gives no hint that the selection differs from the configured default.

In practice, each project and each client quietly keeps whatever effort it was last set to in an abandoned draft. Users who mostly run on High keep landing on Extra High or Max in some projects and not in others, and they burn usage before they notice.

Mobile already handles this case. On rehydrate, use-composer-drafts.ts:713-728 drops modelSelection from new-task drafts that have no text, attachments, mode or workspace changes, and a plain New thread on mobile starts a fresh draft.

A possible fix: when New thread reuses a stored draft with no user content, re-apply the configured default (or drop modelSelectionExplicit from content-free drafts on rehydrate, the same way mobile does).

Impact

Minor bug or occasional failure

Version or commit

main @ 1721f18

Environment

Reproduced on Linux with a web dev build from main in Chromium, using isolated state. Seen in daily use in the Linux Stable desktop app, whose local storage holds several empty drafts with an explicit xhigh pick. Claude Opus 5.5.

Workaround

Check the effort before every first send in a project, or send or clear the stale draft once so the project starts from the default again.

Related issues

• [Bug]: New threads in the same project do not preserve the last-used model and working-mode settings #6508 asks for more per-project carry-over and lists "explicit choices already made in the unsent draft" first. This report is about the opposite edge: a content-free draft whose pick outlives the session it was made in.
• Model switched on one client reverts when another client sends #13483 and Composer draft with an option the model does not advertise is never cleared, so each send reverts t3_thread_configure #32019: a stale composer draft selection overrides newer state on existing threads.