Repository navigation
[Bug]: Project default model is ignored for new threads when another model was selected in a different project #5796
Description
Activity
Reproduced on the macOS desktop client
0.0.34-nightly.20260813.1082while connected to a remote T3 server.The server-side project record was already correct: Project A had an explicit custom Claude/Opus default with high reasoning. The empty new-thread composer still displayed GPT-5.6-Sol/High after a reload.
A read-only inspection of the desktop client's persisted composer state showed why:
{ "draftsByThreadKey": { "<draft>": { "prompt": "", "attachments": [], "modelSelectionByProvider": { "codex": { "instanceId": "codex", "model": "gpt-5.6-sol" } }, "activeProvider": "codex" } }, "stickyModelSelectionByProvider": {}, "stickyActiveProvider": null, "version": 8 }So this is not a project-settings write failure. An empty persisted desktop/web draft contains a carried draft-local model, and
ChatComposergives thatactiveProviderprecedence overproject.defaultModelSelection.PR #6011 fixes future fresh/reused draft initialization, but an already persisted empty draft can remain wrong after upgrading because the currently open/reused path can preserve its stored model and the web composer storage version is unchanged. A reload alone cannot repair it.
The upgrade path should migrate model state off empty draft-session records (or add selection provenance and treat legacy model-only empty drafts as carried/ambient), while preserving drafts with prompts, attachments, terminal/element/preview context, or review comments. Server-thread composer overrides and deliberately edited non-empty drafts should remain untouched.
Before submitting
Area
apps/web
Steps to reproduce
Expected behavior
The new thread in Project A should use Luna because it is explicitly configured as Project A's default model.
A project's configured default should take precedence over models previously selected in other projects.
Actual behavior
The new thread uses GPT Sol, the model most recently selected in Project B.
The last-selected model appears to be remembered globally across projects and overrides the current project's configured default model.
Manually changing the selected model occasionally appeared to refresh the selection, but this behavior was inconsistent and is not a reliable workaround.
Impact
Major degradation or frequent failure
New threads can unintentionally start with the wrong model. This may affect model capabilities, usage limits, and cost, especially when moving between projects configured to use different models.
Version or commit
0.0.33-nightly.20260809.1041
Environment
Linux 7.1.4-arch1-1, T3 Code Nightly desktop app
Logs or stack traces
Screenshots, recordings, or supporting files
None currently available.
Workaround
Manually select the project's intended model whenever creating a new thread.