Let existing conversations follow the current default model (opt-in)

[coygeek]

After changing my default model from Sol to Astra, I want to reopen an old conversation and have its next turn use my current default without remembering to change the model picker each time.

Project inheritance now works through #10639: I used Model → layers/inheritance panel → Reset all on two connected Macs and confirmed that both lists of project overrides became empty while both environment defaults stayed on Astra. That addresses #10594 and discussion #10593, which explicitly preserved existing conversation models.

The remaining request is an opt-in policy for existing conversations to follow the current effective default, with an explicit model pin for intentional exceptions. This should continue working after future default-model changes, without repeating a bulk replacement each time.

Proposed behavior

• Offer a one-time conversion of existing conversations to inheritance, with a preview of affected conversations and environment/provider scope. Include older and archived conversations so reopening them later does not restore a stale model.
• Distinguish Follow default from Pinned to this model in the picker. A previously saved concrete model should not automatically be treated as an intentional pin after the user opts that conversation into inheritance.
• Resolve an inheriting conversation's current project/environment default at its next send. Once project overrides are cleared, it follows the environment default.
• Apply the same rule across desktop and mobile, with server-side resolution so an old local composer selection cannot undo inheritance.
• Keep running turns and historical model/usage records unchanged. Apply updates to subsequent turns; preserve deliberate pins and conversations outside the selected scope.
• Respect environment availability: report unavailable environments rather than implying their conversations were converted.

Smallest useful scope

Start with model changes within the same configured Codex provider instance. Automatic account or provider switching is not needed for this request. Inherit the supported model options from the effective default, and surface an unavailable selection instead of silently substituting a different model.

A one-time replacement of Sol with Astra would help immediately, but would require another cleanup at the next model upgrade. Persisting inheritance is the part that removes the recurring manual work.

Acceptance example

1. Create a conversation using Sol, then opt it into Follow default.
2. Change its effective default to Astra.
3. Reopen it later and send a follow-up without touching the picker: the new turn uses Astra.
4. Change the default again: that conversation follows the next change automatically.
5. A conversation explicitly pinned to Sol continues using Sol. Past turns keep their actual model records.

Current source and related work

At af2baccd100604f9885d6af97a5fa99622dd1c4f, composer resolution prioritizes saved composer/thread choices over the effective default. Migration tests deliberately retain existing-thread selections while clearing empty implicit drafts. This is a request to add an opt-in policy, not a claim that the project reset is broken.

#10202 and #10684 track stale cross-client model reversion bugs. Those are separate correctness issues; fixing them alone would not make an intentionally inheriting old conversation follow future default changes.

[coygeek]

Checked against main at 3efdcc5296f1754e0f3bf7fee5fc2ada510e0438 and the merged settings inheritance work in #10639.

Project-level inheritance is now supported: resetting project model overrides makes new threads use the effective environment default. The related project-default discussion #10593 is now closed as resolved for that core outcome.

Existing conversations still retain a concrete modelSelection. The requested Follow default / Pinned to this model policy, including server-side resolution on future sends and conversion of older or archived conversations, remains unimplemented.

The related cross-client synchronization PRs #10205 and #10866 were still open when checked. They address stale local composer selections following changes to a thread’s concrete model; even when merged, that behavior would not by itself make the thread inherit future project/environment default changes.

Keeping this discussion open to track the remaining conversation-level inheritance feature.