Claude Code 切换大模型卡死？这可能是“模型锁”在作怪

最近在日常使用 VS Code 插件写代码时，遇到了一个让人挺抓狂的小问题，不知道大家有没有同感？

事情是这样的：我平时习惯用那个很好用的 Claude Code 插件，配合着第三方模型中转工具（比如 cc switch）来切换不同的大模型。本来一切都很丝滑，直到我在同一个对话窗口里尝试切换模型。

VS Code Claude Code 插件界面

Claude Code 插件在 VS Code 中的使用界面，展示了对话窗口和操作按钮。

场景很清晰：我正在当前的对话窗口里用 Opus 4.8 这种级别的模型跟 AI 对话，代码写得好好的。突然我想换个轻量点的模型，或者换个 GPT-4 试试别的思路，于是我在 cc switch 上把模型切掉了。

接着我回到 Claude Code 的窗口，期待它能无缝接续。结果大概有 40% 的概率，这个窗口就像死了一样，无论我怎么发消息，它就是不响应，完全没有反应。

一开始我也没辙，只能被迫关掉当前的窗口，重新开一个新的对话。奇迹发生了，新窗口居然一切正常，新模型也能跑起来。

但这就很尴尬了：之前的上下文记录（Context）全都丢在了那个“死掉”的旧窗口里，还得重新复制粘贴或者重新过一遍背景，非常影响开发的心流。

为了搞清楚这事儿，我也去问了问 AI 本身。它提到了一个可能的概念——“模型锁”。

VS Code 插件右键菜单选择 Reload 选项

在插件侧边栏右键菜单中选择“Reload”强制刷新会话状态。

这个概念其实不难理解：为了保证对话的连贯性和上下文的准确性，很多 AI 接口在会话建立之初，就会把这个会话“绑定”到特定的模型 ID 或 endpoint 上。当你通过外部工具强行切换了后端路由，但 VS Code 插件内部还拿着旧的身份信息去请求新模型，两边对不上号，自然就卡住了。

简单说，就是身子换了，魂还留在原来的躯壳里。

既然知道了原因，在官方修好这个 Bug 之前，我们有没有什么办法能尽量避免这种情况？这里有几个我在摸索中总结出来的土办法，大家可以试试：

“清场”大法：在 cc switch 切换模型之前，先手动点击 Claude Code 插件里的“Stop”或者“Reset Thread”按钮，试图结束当前的会话绑定。清空后再切模型，成功率会高很多。
利用插件内置切换（如果有）：如果 Claude Code 插件本身支持修改 API 参数，尽量通过插件内部配置来改变模型，而不是完全依赖外部网络层的中转切换。虽然这可能不如 cc switch 方便，但胜在稳定。
固定的模型窗口策略：如果是多模型协作，不如养成一种习惯：一个项目开两个窗口，一个专门跑 Opus（负责深度思考），一个专门跑 GPT-4 或其他模型（负责快速生成或调试）。不要在一个窗口里反复横跳，虽然有点费资源，但能有效避免卡死。
重载插件：如果不幸卡死了，不用关掉整个 VS Code，试着在插件侧边栏右键选择“Reload”或者重新登录账号，有时候能强制刷新会话状态。

这个问题的核心在于外部中转工具与编辑器插件之间的状态同步。在我们无法修改插件源码的情况下，保持上下文的一致性是关键。

如果你也遇到了类似的“模型锁”困扰，或者有更优雅的解决姿势，欢迎在评论区交流一下，毕竟谁也不想为了切个模型还要重启对话嘛。