fix(web): switching providers no longer drops the thread's stored effort - #33090

Approvability

Verdict: Approved at 00fc14b

Macroscope's review found this PR approvable — Provider switching now retains stored thread effort options while allowing draft options to override their own provider instance. Existing provider/model fallback safeguards remain in place, with no change to product defaults.

^{You can add or adjust custom eligibility rules. Learn more.}

No actionable comments were generated in the recent review.

Merge Risk: Low · up to cf8be

Switching models now keeps the thread's stored effort in the normal case. In two narrow cases a different model could still inherit that effort: an unsent pick with no draft options, and a custom model whose name matches an alias. The effect is limited and the fixes are small, so the change is mergeable with owner awareness.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: switching providers no longer drops the thread's stored effort. The changeset adds carry-over of stored options in useComposerSelection.ts and composerDraftStore.ts, a…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description check		The description follows the repository template. It has Problem, Change, Scope, and Verification sections, and each section has concrete content. The Problem section states the bug and reproduction st…

Full details: Title check

Explanation

The title names the main change: switching providers no longer drops the thread's stored effort. The changeset adds carry-over of stored options in useComposerSelection.ts and composerDraftStore.ts, and the tests cover this behavior. The title is concise, uses the conventional commit form, and matches the PR objectives.

Full details: Description check

Explanation

The description follows the repository template. It has Problem, Change, Scope, and Verification sections, and each section has concrete content. The Problem section states the bug and reproduction steps. The Change section names the two changed files and the behavior change. The Scope section says this is a bug fix, explains why no prior issue is linked, and notes what is unchanged. The Verification section gives manual steps, observed results before and after the fix, test commands, and items not checked. The description also includes the model and harness that did the work, as the template requests. Minor gaps: the Scope section cites a related PR (#24872) but does not link a dedicated issue, and the description is long. These gaps do not block the check.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: bf8e5e6
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: c575523e-8168-4bd6-93b7-b98f6be91282

Commits

Reviewing files that changed from the base of the PR and between 42c305b and cf8beeb.

Files selected for processing: 1

• apps/web/src/composerDraftStore.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 0 remain after this review.

Verified in a real dev environment

verified unchanged head 00fc14b6387b06947232a40e480ad7fe79f6a3f1 on a disposable linux vm with the real web client, repository Playwright, /usr/bin/google-chrome, and Codex gpt-6.1-sol through the local proxy. installed dependencies with vp i in both checkouts and ran one background dev server at a time.

created the project, provider instance, threads, and real turns through the app. no mocks, fixtures, replay provider, or seeded database. used two available Codex instances to exercise instance-scoped options; Claude was not authenticated.

• before: on github/main (bcee0f5d2872ba193c66ed9ba979bbe424f89ff9), opened a real Codex thread stored with high effort in a fresh browser. selected the second Codex instance, set medium, then returned to the original instance. the composer dropped to low. current main also persists model picks immediately, whereas this older PR head keeps them in the draft, so the PR comparison used a fresh thread created on its own head with the same model, high effort, and baseline prompt.
• after: repeated that flow on the exact PR head in a fresh browser. high remained selected. sent a message from that composer; the web client's message.dispatch included reasoningEffort: high, Codex app-server received turn/start with effort: high, and the real response rendered.
• neighboring behavior: the second instance remembered medium. explicitly choosing medium on the original instance overrode stored high. fast sent serviceTier: priority; switching back to standard sent default. both real turns completed.
• focused checks through Blacksmith: cd apps/web && vp test run src/modelSelection.test.ts src/composerDraftStore.test.ts src/components/ChatView.logic.test.ts: 165 passed. GitHub reports 24 successful checks and 7 skipped, with no failures or pending checks. no source changes were needed.

provider protocol transcript, filtered from the running server's actual Codex logs:

2026-11-10T10:39:32.493Z turn/start model=gpt-6.1-sol effort=high   serviceTier=default  -> OPTIONS_RETAINED_OK.
2026-11-10T10:40:20.113Z turn/start model=gpt-6.1-sol effort=medium serviceTier=priority -> OPTIONS_OVERRIDE_OK
2026-11-10T10:40:36.385Z turn/start model=gpt-6.1-sol effort=medium serviceTier=default  -> OPTIONS_STANDARD_OK

before, after returning to the original instance:

after, with the same baseline prompt and initial model/effort:

14-second recording, shown as an animated GIF for GitHub: switch to the second instance, choose medium, return to high, and send a real turn. inspected the capture and checked the uploaded MP4 playback and seeking in T3.

Not verified

native desktop shell, iOS/Android, Claude/Cursor and other provider adapters, remote/relay/tunnel connections, and unavailable-instance fallback were not exercised on this linux web pass. the focused existing tests cover fallback-instance behavior; this is not a claim of runtime verification for those paths. no rebase or integration with current main was performed.

@maria-rcks thank you for testing this with real Codex turns. Your run fills the gap our description left open, a send through a real provider. High stayed selected after the trip through the second instance, message.dispatch carried reasoningEffort: high, and Codex received turn/start with effort: high. It also shows the neighboring behavior holds. The second instance kept medium, an explicit pick on the original instance still overrides the stored value, and the fast and standard switch sent the matching serviceTier. Your 165 focused tests match ours.

Your before run on main at bcee0f5 already includes #31739's immediate model-pick persistence and still drops to low, so the bug is still on main. The branch merges into current main without conflicts. As you noted, desktop, mobile, the other adapters, remote connections and a run on the merged result are still unverified.

@maria-rcks You verified 00fc14b638. The new head fa16e572e4 is more than a merge of main ab9df1d6ff: main's #31739 now saves a model pick to the thread before the next message, so after the merge my earlier fix in deriveEffectiveComposerModelState no longer took effect when you pick the model again. I added a fix where that pick is built (useComposerSelection.ts) and kept the per-provider rule in deriveEffectiveComposerModelState, now only for the model the options were stored with; it still matters when a provider is turned off before its pick is sent. What the user sees is the same as you verified: switching providers and back keeps the thread's stored effort.

@maria-rcks Since fa16e572e4, the new head ccc755848a changes one thing: the pick path now treats a stored model alias (such as gpt-5-codex for gpt-5.4) as the same model, so it keeps the thread's stored options; nothing else changed.

Require a model match for stored options (composerDraftStore.ts:1187): when the draft holds no options, the stored options apply as they do on main. I checked the case you describe, an optionless pick of another model on the same instance, against main's composerDraftStore.ts, and it shows the stored effort there too. This PR only changes what happens when the draft holds options, so I left main's rule for an optionless draft as it is.

Require exact equality when either model is custom (composerDraftStore.ts:1264): this comparison is main's own model identity from the fallback-instance rule, moved unchanged into isSameModel. A custom slug is compared by its exact text, and only a non-custom slug is alias-expanded, so a stored gpt-5-codex matches a custom gpt-5.4 only because it expands to that exact slug.

@maria-rcks You verified 00fc14b638; my last note covered ccc755848a. The new head 42c305bb68 merges main cd8fc91a57 into ccc755848a and changes neither fix file (useComposerSelection.ts, composerDraftStore.ts). The one conflict was the test helper fakeEnvironment.ts, where main now has the same thread model field, so I took main's version.

I merged main because its newer commits changed composerDraftStore.ts, a file this fix changes.
The merge had no conflicts, and nothing else changed.

I merged main again. On main, re-picking the model the composer already shows now saves nothing, so I changed my model-pick test to match. The fix's own lines are unchanged.