Codex + CPA 怎么配：统一 GPT / Gemini 入口与启动路由

如果你想在一套本地工作流里同时兼顾 GPT 和 Gemini，一个比较实用的方向就是：

• 不直接散着记很多启动命令
• 而是统一成一层 launcher

这样后面切模型、改地址、补代理或做自动选择时，维护成本会低很多。

先说结论

更推荐的做法是把启动入口统一成一层 codex-cpa，让模型选择和基础环境变量都收敛到这里。

这样至少能解决三件事：

• 启动命令统一
• 模型切换更清楚
• 代理地址和环境变量更集中

一、这套 launcher 是怎么组织的

本地这套用法里，核心入口包括：

• bin/codex-cpa
• bin/codex-cpa-gpt
• bin/codex-cpa-gemini
• bin/codex-cpa-auto

其中共享入口可以这样使用：

./bin/codex-cpa gpt
./bin/codex-cpa gemini
./bin/codex-cpa auto

如果只是想直接走快捷方式，也可以：

./bin/codex-cpa-auto

二、为什么要多一层 launcher

直接把命令写散，短期看很快，长期通常会遇到这些问题：

• 换模型时要改很多地方
• CPA 地址一变就要到处调整
• 很难记住当前到底用了哪套模型

统一入口之后，模型路由和环境变量就能放在一层里集中管理。

三、auto 模式到底在做什么

这里的 auto 不是每条消息都轮询切换，而是启动时做一次路由选择。

基本思路是：

1. 查询 CPA /models
2. 优先选择 CODEX_CPA_GPT_MODEL
3. 如果不可用，再回退到 CODEX_CPA_GEMINI_MODEL
4. 探测失败时复用上一次选择
5. 再不行就默认走 GPT

这意味着它更像“启动路由器”，而不是“每轮智能调度器”。

四、最值得统一的环境变量有哪些

这套 launcher 里，比较常用的环境变量有：

• CODEX_CPA_PROVIDER
• CODEX_CPA_BASE_URL
• CODEX_CPA_WIRE_API
• CODEX_CPA_REASONING
• CODEX_CPA_GPT_MODEL
• CODEX_CPA_GEMINI_MODEL
• CODEX_CPA_PROXY_TOKEN
• CODEX_CPA_STATE_FILE

如果你后面希望做：

• 切换代理地址
• 切换模型版本
• 调整默认推理档位
• 持久化上次选择

这些变量就是主要控制面。

五、几个更实用的启动例子

1. 明确指定 GPT

./bin/codex-cpa gpt

2. 明确指定 Gemini

./bin/codex-cpa gemini

3. 让启动器自动选

./bin/codex-cpa auto

4. 临时覆盖默认模型

CODEX_CPA_GPT_MODEL=gpt-5-codex ./bin/codex-cpa gpt
CODEX_CPA_GEMINI_MODEL=gemini-2.5-pro ./bin/codex-cpa gemini

5. 临时切换 CPA 地址

CODEX_CPA_BASE_URL=http://127.0.0.1:8317/v1 ./bin/codex-cpa auto

六、这套方式最适合什么场景

比较适合：

• 你想统一多模型入口
• 你经常在 GPT 和 Gemini 之间切换
• 你不想把代理地址和模型名称散落到多个脚本里

对于个人开发环境来说，这种方式比手工记一堆命令更容易长期维护。

七、后面还可以怎么扩

如果你后面继续深化，这层 launcher 还可以继续承担：

• 默认工作目录注入
• 审批或权限档位切换
• 团队统一别名命令
• 不同项目的配置模板

这样不同项目就可以在统一入口下复用不同配置。

八、最常见的误区

1. 把 auto 理解成每轮自动挑最优模型

它更像启动时选择，不是消息级动态切换。

2. 环境变量分散在很多地方

一旦配置分散，后面问题会很难查。

3. 没有保留最后一次状态

如果没有状态文件，探测失败时体验通常会更不稳定。

一句话总结

Codex + CPA 的关键不在“又多了一层”，而在这层把模型选择、代理地址和启动方式统一了。

对长期使用多模型终端工作流的人来说，这种收口方式会更稳。