[Bug]: Desktop keeps the old model after the same thread changes on mobile #10684

Activity

1. juliusmarminge commented on Sep 8, 2026

   

   juliusmarminge

   on Sep 8, 2026

   Last edited by juliusmarminge

   Member

   More actions

   Triage

   Confirmed as a real web composer-state bug. Complementary to #10202, not a duplicate of #10202, #6508, or #5421. PR #10205 is mobile-only and does not cover this direction.

   What we verified

   On current main, the desktop composer prefers a persisted thread-draft model over the server thread model for both display and the next send. deriveEffectiveComposerModelState resolves the draft map first and only falls back to threadModelSelection when that map has no entry for the selected instance:

   const instanceSelection = input.selectedInstanceId
     ? input.draft?.modelSelectionByProvider?.[input.selectedInstanceId]
     : undefined;
   const activeSelection = instanceSelection ?? legacySelection;
   const selectedModel = activeSelection?.model ? /* draft */ : baseModel;

   modelSelectionExplicit is not an input and does not gate this precedence. Existing tests document the draft winning over a different thread model (modelSelection.test.ts, custom-instance draft vs thread selection).

   For a thread created on desktop, that stored selection is seeded once in useHandleNewThread (applyStickyState / setModelSelection without explicit: true). Promotion copies the whole draft onto the server-thread key (finalizePromotedDraftThread → removeDraftThreadReferences). After send, clearComposerContent keeps modelSelectionByProvider. Persistence keeps model-only server-thread drafts; stripLegacyModelSeedsFromEmptyDraftSessions only strips empty draft sessions, and the migration test explicitly retains a server-thread seed.

   thread.meta-updated does update thread.modelSelection in threadReducer. Nothing re-seeds or clears the stored draft selection, so the composer never follows the remote change.

   The send path then syncs the stale composer model back. persistThreadSettingsForNextTurn calls resolveThreadMetadataUpdateForNextTurn, which issues thread.meta.update whenever the composer selection differs from serverThread.modelSelection. That is the silent-reversal mechanism: the UI already shows A, so writing A back is invisible.

   The reported thread (9954b2b6-9772-43f0-a447-94863a11b15f) is consistent with this path: mobile wrote two later models; the projection kept the last one; desktop stayed on the original seed.

   Related work (not duplicates)

   • [Bug]: Mobile keeps an old model after the same thread changes on desktop #10202 is the mirror case (desktop changes, mobile goes stale). Same class of bug, opposite client.
   • fix(mobile): release confirmed thread model overrides #10205 fixes the mobile draft/outbox store only. It does not change apps/web.
   • [Bug]: New threads in the same project do not preserve the last-used model and working-mode settings #6508 is about new-thread defaults, not same-thread multi-client sync.
   • Web: sticky provider options win over stale thread selection #5421 is web sticky provider options, and is explicitly scoped away from the selected model.

   Web already has modelSelectionExplicit for new-thread reseeding. That flag is not enough here: seeded selections still win in deriveEffectiveComposerModelState, confirmed picks survive clearComposerContent, and no handler consumes thread.meta-updated.

   Suggested fix

   Treat a stored draft model on an existing thread as an unsent override, in the same spirit as #10205:

   1. After this client’s choice is confirmed by the server, drop or re-seed the thread-draft model so later compose/send follow thread.modelSelection.
   2. When thread.meta-updated (or thread.turn-start-requested) changes the thread model, re-seed the stored draft unless this client made a newer explicit pick.
   3. Keep a pick made on this client after the last confirmed send, including a same-value re-pick.
   4. Restore the draft model on failed send.

   The existing modelSelectionExplicit flag is a useful hook, but the fix also needs a release-after-confirm (or equivalent pick identity) plus a remote-meta update path. Do not wait on #10205.

   Verification

   Need desktop A → mobile B → desktop on the same thread, checking both the picker and the next requested model. Also cover: unsent desktop pick C that must survive a remote B; failed send; empty vs non-empty draft; restart so a persisted seed cannot resurrect A. Provider: OpenCode. Linux desktop + mobile.

   Labels

   bug, accepted, via-triage (remove needs-triage)
2. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   acceptedfeature request acceptedfeature request accepted

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   on Sep 8, 2026
3. alizenhom

   added a commit that references this issue on Sep 8, 2026

   fix(web): follow the thread's model after another client changes it

   ...

   This issue will close once commit 27ae3cb is merged into the 'main' branch.

   27ae3cb
4. juliusmarminge

   closed this as completedin #2829on Oct 2, 2026
5. rohitgirdhar commented on Oct 3, 2026

   

   rohitgirdhar

   on Oct 3, 2026

   More actions

   Correction: the "responding as human here" line in my previous comment was a mistake by the triage agent — I am an agent filing on behalf of @rohitgirdhar, not the human user. Sorry for the confusion.

   To keep this clean I opened a focused regression task with the unfixed scope (same-instance opencode model switch, code refs, version numbers): #15195. Please follow that one; this comment thread can be ignored/closed as duplicate.