同时装了 Codex 和 Gemini CLI 以后，有一种特别自然的冲动。
既然都在同一个 AI Code With 账户里调用模型，Base URL 也应该一样吧。
不一样。
一份余额可以覆盖多种模型，一套后台可以管理 Key 和查看调用记录，但不同 CLI 仍然可能使用不同协议与 Endpoint。AI Code With 对 Codex 和 Gemini CLI 都有明确接入教程，因此这不是靠常识推测出来的兼容关系。
两条地址分别解决两种协议
Codex 使用：
https://api.aicodewith.ai/chatgpt/v1
并配置 Responses Provider。
Gemini CLI 使用：
GOOGLE_GEMINI_BASE_URL=https://api.aicodewith.ai/gemini_cli
同时配置相应的 Gemini API Key。两个地址都来自当前产品事实库，不能互相替换，也不该被简化成所谓万能 /v1。
为什么 Key 正确也会失败
Key 只解决认证。请求通过认证之后，服务仍要理解路径、请求格式和模型字段。
所以错误地址可能让你看到一种很迷惑的状态。Key 没报无效，网络也能连通，后面却出现 404、格式错误或模型不可用。
这时继续创建新 Key，通常只是增加变量。应该先对照工具、Endpoint 和环境变量是否匹配。
用两个 Key 做一次干净验证
长期共用时，可以给 Codex 与 Gemini CLI 分别创建命名清晰的 Key。先用 Codex 完成一个小请求，再用 Gemini CLI 完成一个小请求。
打开 Usage Records 后按 Key 查看服务、模型、渠道、Token 和费用。两条记录都出现，才算双工具链路完成。只有一条出现，就回到另一套本地配置排查。
这里同样要守住产品边界。AI Code With 提供的是模型接入、Key 与记录，不是 Gemini CLI 或 Codex 的自身功能，也不会自动让两个 CLI 共享会话和项目上下文。
如果你只用其中一个工具，就配置那一条。不要为了看起来整齐，额外制造另一条不会使用的链路。
协议不会因为我们希望统一，就自己变得统一。
看清工具，再选地址。比记住一串万能 URL 更可靠。