Codex + CCSwitch 多端点切换导致会话丢失，怎么做无缝 fallback？

问题描述：

正文（精简版）

我最近在本地用 Codex桌面端 做开发（语音效率比较高），遇到一个比较头疼的问题，想看看大家有没有更优解。

背景

• 我有官方订阅（额度有限）
• 额度用完后，会切换到一些第三方/公益站继续用
• 使用类似 CCSwitch 的方式切换 baseURL和auth信息

问题

当切换端点（官方 → 第三方 或反过来）时：

Codex桌面端 里的对话线程会丢失

原有上下文直接没了

看起来像是按 endpoint / user_id 做记忆管理的

这对开发影响挺大，因为很多上下文是连续的。

---

我现在的目标是：

希望能实现：

1. 官方额度优先用，用完自动 fallback 到第三方
2. 或者手动切换，但不影响已有线程
3. 同一套本地 Codex，会话能持续，不被清空

---

当前猜测

• Codex 的线程可能和 baseURL / API key 强绑定
• 切换 endpoint 后，相当于“换了一个用户空间”

---

想问大家：

有没有人使用类似方案，比如：

• 多 endpoint 统一代理（网关层做 fallback）？
• 让 Codex 只认一个 baseURL，但后端自动切？
• 或者有什么工具/配置可以避免线程丢失？

---

如果有成熟方案或者踩坑经验，求分享

网友解答：

---

--【壹】--：

同问，每次切模型断点，会话，设置，记忆啥的都没了，有没有啥好办法

---

--【贰】--：

佬 求分享 想学习一下

---

--【叁】--：

Model provider名字都要一样才行

---

--【肆】--：

最近也遇到这个问题，蹲一个解决方案

---

--【伍】--：

找到问题，更新了

---

--【陆】--：

provider全部手动改成OpenAI

---

--【柒】--：

感谢感谢

---

--【捌】--：

我的理解，是只走api登录，确保供应商id一致。自己的号走cpa，公益站不变

---

--【玖】--：

蹲一下，明天看看

---

--【拾】--： xy3:

用sub2api中转官方订阅之后统一provider名字吧

厉害了，这个感觉是能彻底解决

---

--【拾壹】--：

用sub2api中转官方订阅之后统一provider名字吧

---

--【拾贰】--：

小白也来蹲个方案，另外CPA是不是不能用？www
CCswitch已装，但配置好烦，每个谷歌模型都得配一遍吗
现在只会codex，用的是ggboom的公益站

---

--【拾叁】--：

更新了哈

---

--【拾肆】--：

@pentamer 如果只用第三方是可以的，但是它中间有官方的，这两个中间没有办法。Provider应该不可以使用官方的OpenAI，然后设置第三方的URL。

---

--【拾伍】--：

codex 的会话隔离用的好难受，有没有不隔离的办法？ - 开发调优 - LINUX DO
可以参考一下这个帖子

---

--【拾陆】--：

就是数据库先 toml文件延后
数据库不存在 从toml文件中重建db

---

--【拾柒】--：

我是让codex写个脚本自己修复

---

--【拾捌】--：

佬，我和你问题一样，有个 plus 不够用，接入 cpa 后就找不到对话了

---

--【拾玖】--：

按照楼上大佬提供的思路验证了一下，确实问题就在这里：

使用CC Switch切换中转站之后，怎么恢复之前的会话 - #4，来自 Haleclipse

我这边实测下来，结论是：

---

关键点

只需要保证下面两个地方的 model_provider 统一为 “openai”：

1. config.toml
2. 本地数据库：state_5.sqlite / stage_5.db

---

细节补充

• 数据库里主要是 threads 表的 provider 字段 在起作用
• 只要 provider 名一致，历史会话基本就能正常显示

---

当前遇到的问题

现在最大的问题反而是：

CCSwitch 切换时会覆盖 Codex 配置，且内容不完整导致 config.toml 错误

所以会出现：

• 配置被重写
• provider 又被改掉
• 会话再次“消失”

---

临时方案

目前只能自己写个脚本来兜底：

• 在「官方订阅」和「第三方」之间切换
• 同时强制保持 model_provider = “openai”
• 避免 CCSwitch 把配置搞乱

---

一句话总结

Codex 会话是否“丢失”，本质不是 endpoint 问题，而是 model_provider 是否一致（尤其是数据库里的记录）

---