我写了一个切换Codex Provider后同步session的工具
- 内容介绍
- 文章标签
- 相关推荐
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
最近由于众所周知的原因所以配置了很多的中转
因此频繁切换provider，结果发现所有历史会话都打不开了
于是研究了一下，原来每个会话文件都记录了model_provider，切换后就对不上了
所以就试着手动改，打开 ~/.codex/sessions目录，几十个 .jsonl 文件…
改了几个，发现有些文件被 Codex 锁定了，根本改不了
干脆写个工具自动化处理。于是就有了这个工具GitHub - ChanMQ4/codex-switch: 一键切换 Codex Provider 并自动同步所有会话。支持 Python 和 JavaScript，无需依赖，开箱即用 · GitHub
本人才疏学浅，但还是希望能够帮到各位佬友
诚挚欢迎各位佬友给出建议
--【壹】--：
ccswitch也可以的，我这样主要是图个方便
--【贰】--：
哈哈，是这样的，我写这个本来就是轻量为主
不过如果数据很多，我会考虑删除历史，因为我认为对话历史其实是迭代的，具备一定的时效性
--【叁】--：
有道理，如果从rollout重建索引的话就废了。
不过这里有另一层问题，就是我是持续监控并sync sqlite的，这里的开销很低，但是如果持续监控rollout，哪怕是增量，开销也相对要高一些。
主要是我觉得吧，oai做了sqlite索引的目的可能就是为了解决rollout太多的问题，需要抽象出来一层。那我们直接在抽象层上做改动就好了，然后我保留rollout作为唯一真源。这样子什么时候真的需要去回源看看那个Session是属于哪个provider的，也不耽误。这是我的设计思路。
谢谢佬友这个提醒，我琢磨琢磨。
还有就是，全量备份rollout这件事对我来说太奢侈了，一次备份就是60G，我的sqlite都有2G多。实在承受不起
--【肆】--：
能帮到就行，只要能帮上忙那就是有意义的
--【伍】--：
我还没实际切换过，是不是只要谈个ccswitch就不怕这个问题了啊，我自己现在是cpa反代的和nvidia的同时放在cc里给codex用
--【陆】--：
嗯，但是我不敢随便乱删，都是跑以前的项目的东西。后面哪个甲方要我迭代之类的，都得指望着它们。归档是目前最好的做法了。
--【柒】--：
感谢佬的工具，成功把原本auth的记录，转到使用api的provider里面
--【捌】--：
我的想法是保证两层数据一致，因为一旦SQLite从rollout文件重新建立索引，由于rollout文件的第一行元数据没有被改动，所有provider信息就会回退到原始值，等于白改了
还有就是我一开始想的没有那么多，就想着用最简单最直接的方式解决问题，所以就用这种方式了
--【玖】--：
我也写了个类似的项目：
GitHub - Wangnov/codex-threadripper: Keep Codex thread history aligned to one provider...
Keep Codex thread history aligned to one provider bucket.
但是我这里其实只做了sqlite的修改，因为我自己有一个问题：我有大概60多G的rollout文件，多的恐怖。直接改rollout，这个速度怎么也上不去。而我发现，只需要改sqlite的索引，就足够对付Codex App和Codex CLI了。
佬友这里，为啥一定要连rollout一起改呢？这个设计是出于啥目的？想请教一下，是不是我这个方案会有啥漏洞
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
最近由于众所周知的原因所以配置了很多的中转
因此频繁切换provider，结果发现所有历史会话都打不开了
于是研究了一下，原来每个会话文件都记录了model_provider，切换后就对不上了
所以就试着手动改，打开 ~/.codex/sessions目录，几十个 .jsonl 文件…
改了几个，发现有些文件被 Codex 锁定了，根本改不了
干脆写个工具自动化处理。于是就有了这个工具GitHub - ChanMQ4/codex-switch: 一键切换 Codex Provider 并自动同步所有会话。支持 Python 和 JavaScript，无需依赖，开箱即用 · GitHub
本人才疏学浅，但还是希望能够帮到各位佬友
诚挚欢迎各位佬友给出建议
--【壹】--：
ccswitch也可以的，我这样主要是图个方便
--【贰】--：
哈哈，是这样的，我写这个本来就是轻量为主
不过如果数据很多，我会考虑删除历史，因为我认为对话历史其实是迭代的，具备一定的时效性
--【叁】--：
有道理，如果从rollout重建索引的话就废了。
不过这里有另一层问题，就是我是持续监控并sync sqlite的，这里的开销很低，但是如果持续监控rollout，哪怕是增量，开销也相对要高一些。
主要是我觉得吧，oai做了sqlite索引的目的可能就是为了解决rollout太多的问题，需要抽象出来一层。那我们直接在抽象层上做改动就好了，然后我保留rollout作为唯一真源。这样子什么时候真的需要去回源看看那个Session是属于哪个provider的，也不耽误。这是我的设计思路。
谢谢佬友这个提醒，我琢磨琢磨。
还有就是，全量备份rollout这件事对我来说太奢侈了，一次备份就是60G，我的sqlite都有2G多。实在承受不起
--【肆】--：
能帮到就行，只要能帮上忙那就是有意义的
--【伍】--：
我还没实际切换过，是不是只要谈个ccswitch就不怕这个问题了啊，我自己现在是cpa反代的和nvidia的同时放在cc里给codex用
--【陆】--：
嗯，但是我不敢随便乱删，都是跑以前的项目的东西。后面哪个甲方要我迭代之类的，都得指望着它们。归档是目前最好的做法了。
--【柒】--：
感谢佬的工具，成功把原本auth的记录，转到使用api的provider里面
--【捌】--：
我的想法是保证两层数据一致，因为一旦SQLite从rollout文件重新建立索引，由于rollout文件的第一行元数据没有被改动，所有provider信息就会回退到原始值，等于白改了
还有就是我一开始想的没有那么多，就想着用最简单最直接的方式解决问题，所以就用这种方式了
--【玖】--：
我也写了个类似的项目：
GitHub - Wangnov/codex-threadripper: Keep Codex thread history aligned to one provider...
Keep Codex thread history aligned to one provider bucket.
但是我这里其实只做了sqlite的修改，因为我自己有一个问题：我有大概60多G的rollout文件，多的恐怖。直接改rollout，这个速度怎么也上不去。而我发现，只需要改sqlite的索引，就足够对付Codex App和Codex CLI了。
佬友这里，为啥一定要连rollout一起改呢？这个设计是出于啥目的？想请教一下，是不是我这个方案会有啥漏洞