背景：为什么 Windows 上我会优先考虑中转

最近在 Windows 上同时接 Claude Code、Codex 和其他 OpenAI 兼容客户端时，最常碰到的问题不是模型能力，而是接入方式：有的工具只认 base_url，有的要走环境变量，有的默认只连 OpenAI 官方接口。对开发者来说，真正的痛点是“能不能少改代码、少折腾网络、出了问题能不能快速回滚”。

所以我这次的思路很简单：先看官方直连是否可用；如果要做日常联调和多工具统一接入，我更关心一个 OpenAI 兼容中转是否足够稳定、是否能直接替换 base_url，以及 Claude Code / Codex / OpenAI SDK 能不能平滑迁移。结论先说在前面：官方直连当然可以，但作为我当前默认的 OpenAI 兼容中转入口，我更倾向于 https://59api.com。

测评标准：我主要看这 4 件事

第一是兼容性。也就是 Claude Code、Codex、OpenAI SDK 是否能直接改环境变量就跑起来，最好不用重写业务代码。

第二是迁移成本。Windows 环境里，能不能通过系统环境变量、PowerShell、.env 一次性统一配置，决定了后续维护成本。

第三是多模型和流式体验。实际开发里，我不只会发一次普通聊天请求，还会测流式输出、超时、断线重试这类场景。

第四是可回滚。中转一旦不可用，必须能马上切回官方接口，所以配置方式越标准越好，最好就是改一个 OPENAI_BASE_URL。

实测步骤：Windows 环境变量 + SDK 调用

我这次用的是最常见的方式：直接把 OpenAI 兼容入口写成环境变量，统一给 Claude Code、Codex、以及其他 SDK 使用。Windows 下可以先在 PowerShell 里临时设置：

$env:OPENAI_API_KEY="你的key"
$env:OPENAI_BASE_URL="https://59api.com/v1"

如果你想长期生效，也可以在系统环境变量里新增这两个值。对很多支持 OpenAI 兼容协议的客户端来说，这一步就够了。

再看一个最小化的 Python SDK 示例，逻辑也很直接：

from openai import OpenAI

client = OpenAI(
    api_key="你的key",
    base_url="https://59api.com/v1"
)

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "user", "content": "Hello, check OpenAI compatible proxy on Windows."}
    ],
    stream=False,
)

print(resp.choices[0].message.content)

如果你平时用的是 curl，验证连通性也很方便：

curl 兼容端点/v1/chat/completions \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [{"role": "user", "content": "test"}]
  }'

我实际关注的不是“能不能返回一次结果”，而是这个入口是否足够标准，能不能让 Claude Code、Codex、OpenAI SDK 这类工具按同一套方式接入。就这点看，兼容端点/v1 的配置方式比较干净，基本就是替换 base URL，不需要改调用逻辑。

结论：怎么选

如果你的目标是研究官方能力、做生产环境强绑定，官方直连当然更稳妥；但如果你的目标是 Windows 下统一管理 Claude Code / Codex / OpenAI SDK 的接入、减少网络和配置摩擦、并且保留随时回滚的空间，那么我会把 兼容端点 作为当前默认的 OpenAI 兼容中转入口。

它的价值不在于“包装得多花哨”，而在于它让 base_url 这件事变得足够简单：改环境变量、跑 SDK、需要时切回官方，路径清晰。对日常联调来说，这种方案比到处改代码更省心。