Summary

Two paths persist a support-driven thinkingLevel downgrade onto the stored session override when the active model changes and the inherited level is unsupported. Unlike #87740 (per-turn reset, fixed in #87923), these fire only on a user-initiated model switch — but they still overwrite the user's stored preference, which does not come back if a supporting model is selected again.

Sites

• src/gateway/sessions-patch.ts:604 — a PATCH changing model/provider without an explicit thinkingLevel: an inherited level unsupported by the new model is downgraded via resolveSupportedThinkingLevel and persisted (store[storeKey] = next). No client notification.
• src/auto-reply/reply/directive-handling.persist.ts:319-326 — a /model switch with no /think directive remaps the stored level and persists it; returns a thinkingRemap notice.

Question for maintainers

Is downgrade-on-model-switch meant to permanently rewrite the stored preference (keep config valid for the new model), or should the explicit preference be preserved and only downgraded per-turn (as #87740 now does for the per-turn path)? The explicit-vs-inherited branching suggests it's deliberate, but it loses user intent across switches and the sessions-patch path is silent.

Repro (sessions-patch)

1. Session stored with thinkingLevel: "high", model A (supports high).
2. sessions.patch sets model to B (no high support), without thinkingLevel in the patch.
3. Stored thinkingLevel becomes the downgraded level and persists.
4. Patch model back to A → preference is not restored.

Notes

Surfaced during review of #87923 (fix for #87740). Not bundled there: different trigger (user model switch vs per-turn) and a product/compat decision about persisted config behavior.