Codex、Claude Code、Gemini CLI 怎么一起用？

AI Code With · 多工具 AI 编程配置与排错指南

电脑里同时装 Codex、Claude Code、Gemini CLI 以后，很多人的第一反应都一样：既然三个工具最后都要调用模型，那最好把 Key、Base URL、模型甚至配置文件都统一掉。

这个想法听起来很工程化，但真正落地时，最容易出问题的恰恰就是“强行统一”。因为三个工具面对的不是同一套协议。Key 可以来自同一个平台，调用记录可以回到同一个后台，账户和成本也可以集中查看；但 Codex、Claude Code、Gemini CLI 期待的 Endpoint、环境变量和配置格式并不一样。

真正该统一的是管理层，不是协议层。

这篇文章把三个场景放到一条线上讲：Codex CLI / Codex App、Claude Code、Gemini CLI 如何分别配置，为什么 Base URL 不能互相复制，以及如果你通过 AI Code With 统一管理模型入口，怎样做到“后台统一、前端各走各的协议”。

1. 先把结论说清楚：哪些能统一，哪些不能

如果你同时使用多种 AI 编程工具，可以把“统一”拆成两层。

可以统一的是管理

• 在同一个 AI Code With 账户下创建和管理多个 API Key。

• 按工具给 Key 命名，例如 codex-main、claude-main、gemini-main。

• 在 Usage Records 里按时间、Key、服务、模型、Token 和费用核对调用。

• 需要时在同一后台查看模型和渠道状态，而不是分别去多个上游账户查账。

不能强行统一的是协议

• Codex 的专用 Endpoint 与 Responses Provider。

• Claude Code 使用的 Anthropic 风格环境变量与根地址。

• Gemini CLI 使用的 Gemini 专用 Base URL 和变量名。

• 每个工具自己的配置文件、会话上下文、权限和 Agent 能力。

所以“同一个平台”不等于“同一个 Base URL”。平台可以统一账户和调用记录，但客户端仍然必须按照自己理解的协议发请求。

2. 为什么同一个 Base URL 不能三个工具通吃？

API Key 只解决“你是谁”；Base URL 和协议解决“请求发到哪里、对方按什么格式理解”。当 Key、Endpoint、Provider、模型 ID 混在一起时，就会出现最让人迷惑的情况：Key 明明有效，网络也正常，却还是 404、格式错误、model not found，甚至界面显示模型名正常，但后台根本没有真实调用记录。

可以把它理解成三家快递公司共用一个付款账户。你当然可以统一付款，但每家公司仍然有自己的面单格式、分拣规则和入口。把 A 公司的地址标签贴到 B 公司的包裹上，并不会因为“钱是同一个账户扣的”就自动兼容。

3. Codex、Claude Code、Gemini CLI 配置有什么区别？

这张表最值得记住的不是三串地址，而是：三个客户端根本不是在读取同一套配置。

Codex CLI / App：使用 Codex 专用 Endpoint

Codex 桌面端最容易让人误判。打开 App 设置找了一圈没看到 Base URL，就以为第三方 Provider 不支持桌面端。实际上 AI Code With 当前 Codex App 文档的路线是：先把 Codex 的 auth.json 和 config.toml 配好，再让 App 复用这套配置。

一个最小的 Codex Provider 结构可以理解成：

model = "<CURRENT_MODEL_ID>"

model_provider = "aicodewith-codex"

[model_providers.aicodewith-codex]

base_url = "https://api.aicodewith.ai/chatgpt/v1"

wire_api = "responses"

requires_openai_auth = true

这里最容易犯的错误不是 Key，而是把普通 API 的 /v1 地址塞进 Codex，或者把另一个工具的 Base URL 拿过来复用。Codex 这条链需要使用它自己的专用 Endpoint，并且 Provider 要和 Responses 路线对上。

另一个现实问题是：CLI 能用，不代表 App 此刻一定已经读取了最新配置。修改以后要完全退出 App 再重新打开，比只关窗口更稳。

App 里看到一个模型名，只能说明界面状态。真正的验收证据，是一次真实返回 + AI Code With Usage Records 中出现对应请求。

Claude Code：使用 Anthropic 配置路线

Claude Code 的配置思路完全不同。AI Code With 当前教程使用的是 Claude 自己的环境变量：

"env": {

"ANTHROPIC_AUTH_TOKEN": "在这里替换成你的_API_KEY",

"ANTHROPIC_API_KEY": "",

"ANTHROPIC_BASE_URL": "https://api.aicodewith.ai"

}

注意这里的 Base URL 是根地址，不是 Codex 的 https://api.aicodewith.ai/chatgpt/v1。两者一长一短，不是文档不统一，而是客户端期待的路径和协议不同。

所以如果 Claude Code 报错，不要因为 Codex 正常，就把 Codex 的 Provider 配置整段复制过来。你应该只检查 Claude Code 自己的 settings.json、环境变量、Key 和对应调用记录。

Gemini CLI：使用 Gemini 专用 Endpoint

Gemini CLI 同样有自己的配置入口。当前 AI Code With 文档使用：

GEMINI_API_KEY=在这里替换成你的_API_KEY

GOOGLE_GEMINI_BASE_URL=https://api.aicodewith.ai/gemini_cli

GEMINI_MODEL=<CURRENT_MODEL_ID>

这里再次体现了同一个原则：Key 可以来自同一个账户，但 Gemini CLI 的 Base URL 仍然不能换成 Codex 或 Claude Code 的地址。

如果 Key 是有效的，但 Endpoint 写错，你可能不会第一时间看到“Key 无效”，而是在后面遇到 404、格式错误、模型不可用。这时候继续创建新 Key 只是在增加变量。

4. 真正推荐的管理方式：一个后台，三个 Key

如果你每天都在 Codex、Claude Code、Gemini CLI 之间切换，我更推荐“同一个后台、不同 Key”，而不是三个工具共用一把万能 Key。

codex-main

claude-main

gemini-main

这样做的好处不是为了多管理三串字符，而是把调用归因做干净。

• Codex 报错时，只需要看 codex-main 有没有对应请求。

• Claude Code 费用突然上涨时，可以直接按 claude-main 查。

• Gemini CLI 没有后台记录时，说明请求可能根本没有走预期链路。

• 某个 Key 泄露或需要轮换时，只影响对应工具。

这比三个工具共用同一个 Key，然后靠时间猜“这条费用到底是谁产生的”要省心得多。

5. 两个真实排错案例

案例一：三个工具都能启动，但只有两个真的走对了

假设你刚把三套工具都接到同一个 AI Code With 账户。Codex 能正常回答，Claude Code 也能回答，Gemini CLI 终端看起来也没有明显红字。表面上像是全部成功了。

真正验收时，你到 Usage Records 里看：

10:01 codex-main 有记录

10:03 claude-main 有记录

10:05 gemini-main 没有记录

这时候不要去重装 Gemini CLI，也不要重新生成三个 Key。因为 Codex 和 Claude 已经证明平台和账户本身能用。问题范围已经被缩小到了 Gemini CLI 这一条链。

接下来只查：

• ~/.gemini/.env 是否被读取

• GOOGLE_GEMINI_BASE_URL 是否还是专用地址

• GEMINI_API_KEY 是否对应 gemini-main

• 当前 Model ID 是否有效

• 是否有其他配置覆盖这份 .env

这种排错方式的核心不是“记住更多命令”，而是让每个工具都留下独立证据。

案例二：Codex CLI 正常，Codex App 却一直 401

这个问题很容易让人误以为 Provider 本身坏了。但如果 CLI 已经能通过同一个账户正常返回，说明平台地址和 Key 至少有一条工作路径。

这时更应该检查：

• App 是否完全退出并重新读取 ~/.codex 配置；

• auth.json 中的 Key 是否仍有效；

• App 实际请求 URL 是否仍然指向 https://api.aicodewith.ai/chatgpt/v1；

• 是否还有旧 Provider 或旧会话配置在生效。

不要看到 401 就继续换模型。401 首先是认证 / Key / 当前请求路径的问题，模型 ID 通常不是第一优先级。

6. 401、404、Model not found 怎么按层排查？

7. 三个 AI 编程工具应该怎么分工？

配置跑通以后，还有一个经常被忽略的问题：Codex、Claude Code、Gemini CLI 本身的 Agent 能力、项目上下文和操作方式并不会因为用了同一个后台就自动共享。

例如你可以这样分工：

• Codex 负责一个明确的代码修改任务；

• Claude Code 做另一类分析或 Review；

• Gemini CLI 用于你更熟悉的某类模型或任务；

• 最终由 Git diff、测试和人工验收决定哪一版保留。

但不要让两个 Agent 同时在同一个未提交工作区里大范围改同一批文件，然后再指望“后台统一”帮你解决冲突。AI Code With 统一的是模型 API、Key 和调用记录，不是工作树，也不会自动让三个 CLI 共享会话。

8. 什么情况下 AI Code With 的统一价值最明显？

如果你只用一个工具，而且官方登录已经完全满足需求，那就没有必要为了“看起来统一”再多加一层。多一层配置本身也是成本。

但下面这些情况，统一后台开始真正有价值：

• 同时使用 Codex、Claude Code、Gemini CLI 或其他支持自定义 API 的工具；

• 经常切换多个模型，不想分别维护多个上游账户；

• 希望按 Key 区分不同工具的调用和费用；

• 需要在一个地方核对模型、渠道、Token 和使用记录；

• 配置出错时，希望能用后台记录判断请求到底有没有走到预期 Provider。

这也是为什么这篇文章不建议“统一 Base URL”，反而建议“统一管理、分开配置”。

9. 最后做一次三工具验收

第一次配置完成后，不要直接拿大项目测试。最稳的是给三个工具各跑一个同等级、无副作用的小任务。

1. Codex：读取一个 README，解释一段内容

2. Claude Code：读取同一个或类似的小文件，做只读分析

3. Gemini CLI：做一个同等级的小问答 / 代码解释

4. 分别记录时间

5. 打开 Usage Records，按 Key 对三条调用

6. 核对模型、渠道、Token 和费用

7. 某一条失败，只修改那一套配置

当这七步都能稳定重复，你才算真正建立了多工具工作流。

10. 最后记住一句话

成熟的多工具配置看起来往往并不整齐：Codex 有自己的 config.toml，Claude Code 有 settings.json，Gemini CLI 有 .env；三个 Base URL 也不一样。

但它们背后可以非常统一：

一个账户

↓

按工具分 Key

↓

各自使用正确 Endpoint / 协议

↓

统一回到 Usage Records 验收

这才是工程上真正有用的统一。

后台统一，协议分开；配置分开，证据统一。

只要守住这个原则，以后不管你再加 OpenCode、其他 CLI 或新的模型入口，都不用再去寻找所谓“万能 Base URL”。先看清客户端使用什么协议，再给它正确的地址，然后用一条真实调用记录完成验收。

相关阅读

• Codex App 接第三方模型：Provider、Base URL 与 401 排错

• Codex API Key 怎么配置：Key、Provider、Base URL 和模型分别做什么

• Claude Code 接第三方 API：环境变量和 Base URL 怎么配

• Gemini CLI 接第三方模型：.env、Key 与 Endpoint 配置

• AI Code With 创建和管理 API Key

资料来源

AI Code With Codex CLI：https://docs.aicodewith.ai/zh/docs/codex-cli

AI Code With Codex App：https://docs.aicodewith.ai/zh/docs/codex-app

AI Code With Claude Code CLI：https://docs.aicodewith.ai/zh/docs/claude-code-cli

AI Code With Gemini CLI：https://docs.aicodewith.ai/zh/docs/gemini-cli

OpenAI Codex / Responses API：https://developers.openai.com/