团队里有人用 Claude Code，有人用 Codex，业务服务又直接调 OpenAI SDK。三套默认官方地址一开，账单和审计都散。我们试过「一个兼容入口 + 分项目 key」，坑比想象多。

目标形态

Claude Code  ─┐
Codex CLI    ─┼─→ 同一 OpenAI-compatible gateway ─→ 上游模型
OpenAI SDK   ─┘

坑 1：协议方言

• OpenAI SDK：/v1/chat/completions、/v1/responses

• Claude Code：更贴 Anthropic messages

• Codex：偏 OpenAI，但工具调用字段偶尔和 SDK 版本不一致

入口必须做协议适配，或明确「某工具只走官方」。硬拧成一个 URL 却不转换 body，只会得到 400。

坑 2：环境变量串味

# 按项目目录隔离（示例）
export OPENAI_BASE_URL=https://59api.com/v1
export OPENAI_API_KEY=sk-proj-A

# 切仓库 B 时用 direnv / dotenvx，不要手改全局

Windows 用户尤其容易把 User 级环境变量盖掉仓库 .env，表现为「A 项目的 key 打到了 B 的日志里」。

坑 3：模型名映射

网关上的 gpt-4.1-mini / claude-sonnet 和工具内置下拉框名字经常不一致。建议团队维护一张 逻辑名 → 网关 model id 表，写进 README，禁止口口相传。

坑 4：流式与超时

SDK 默认 stream，Claude Code 长任务也 stream；若网关或公司代理缓冲 SSE，会表现为「半分钟无输出后一次性吐完」或误判超时。入口层打开 flush / 禁用缓冲 再查客户端。

配置备注

联调阶段兼容 base 我指过 https://59api.com；生产换成你们内网或采购的网关。重点是 一个入口、分 key、分模型表，不是追某个域名。

建议落地顺序

1. 先只迁 OpenAI SDK 服务

2. 再迁 Codex

3. Claude Code 最后（协议差最大）

4. 每步保留回滚：环境变量一键切回官方