Composer draft with an option the model does not advertise is never cleared, so each send reverts t3_thread_configure #32019

What happened

I asked the agent in a thread to change its own reasoning effort from high to medium. It called t3_thread_configure, and a read-back showed medium. When I sent my next message from the composer, the thread went back to high. Agent model and effort changes do not stay.

Diagnosis

#20886 (fix for #15195) clears a thread's composer draft pick when the live thread selection matches it (matchesAtom in apps/web/src/composerDraftStore.ts). draftModelPickMatchesThread (packages/shared/src/model.ts) ignores only fastMode: false and compares all other options exactly.

The settings default for new threads is claude-opus-5-5 with effort: high and contextWindow: 1m. The contextWindow value stayed from an earlier Opus default. Opus 5.5 advertises only effort and fastMode. The composer seeds the draft with both options. The server stores the thread selection without contextWindow. So the draft and the thread never match, and the draft is never cleared.

deriveEffectiveComposerModelState takes the model and options from the draft before the thread. Each send writes the draft selection back to the thread, so a change from t3_thread_configure or from another client is lost when the user sends the next message. The picker already shows the draft value, so the user does not see the reversal. Most saved claude-opus-5-5 drafts on this install have contextWindow: 1m.

The code paths are the same on main @ 6577c6b. A possible fix: compare the draft and the thread after both are normalized to the options that the model advertises. That also covers drafts that are already saved.

Steps to reproduce

1. Have a settings default model selection with an option the model does not advertise. Here: claude-opus-5-5 with [{effort: high}, {contextWindow: 1m}].
2. Create a thread in the desktop composer and send a message.
3. Ask the agent to call t3_thread_configure with {instanceId: claudeAgent, model: claude-opus-5-5, options: [{effort: medium}, {fastMode: false}]}. Read back: effort: medium.
4. Send the next message from the composer. Do not touch the model picker.
5. Read back again: effort: high.

Expected: the composer follows the thread (medium) and the send keeps medium.

Version

0.1.8-nightly.20261104.4165 (desktop). Triage done by hand, not with the t3 triage CLI.

Environment

Windows 11 Pro, desktop app with its local server, Claude provider (claudeAgent, Claude Code CLI)

Evidence

Thread log (UTC):
13:23:57 t3_thread_configure effort=medium
13:23:59 read-back effort=medium
13:24:15 user message sent from composer
13:24:24 read-back effort=high

Persisted composer draft for the thread (desktop Local Storage):
"modelSelectionByProvider":{"claudeAgent":{"instanceId":"claudeAgent","model":"claude-opus-5-5","options":[{"id":"effort","value":"high"},{"id":"contextWindow","value":"1m"}]}},"activeProvider":"claudeAgent"

Server thread selection before the change:
{"instanceId":"claudeAgent","model":"claude-opus-5-5","options":[{"id":"effort","value":"high"},{"id":"fastMode","value":false}]}

Related issues

#15195 (closed by #20886): the same reversal; this is a case the fix does not cover. #23497: related options precedence from the settings default. #15300: t3_thread_configure on an active run.

Fix applied or workaround

Nothing was changed on the machine. Workaround: pick the effort in the composer before sending, or select the default model again in Settings so the default has no contextWindow option. Drafts that are already saved keep the option.

Filed by

Claude Opus 5.5 in Claude Code, running in T3 Code, on behalf of runshotgun