如何让 Codex 同时支持 ChatGPT OAuth 与自定义 API Provider

2026-04-11 08:090阅读0评论SEO问题
  • 内容介绍
  • 文章标签
  • 相关推荐
问题描述:

对于有自己vps & 愿意本地跑Docker容器的佬友则更推荐使用CPA,不用忍受provider不同导致的记录不同步,算是资源充沛下的上位解了

最近 OpenAI 又调整了 ChatGPT OAuth 登录的 codex 用量,原本可能已经不是很宽裕的 5 小时窗口又被削减了一轮,再加上 4 月 2 号开始的双倍额度活动也结束了,我自己的实际体感是现在可能半小时到一小时就会蹬完五小时的额度……但活总得继续干下去呀?

所以我需要一个 fallback 方案:平时继续用 ChatGPT OAuth 登录,毕竟订阅额度不蹬白不蹬;额度不够的时候无缝切到第三方 API provider 继续续命。Codex CLI 本身是支持自定义 provider 和 profile 切换的,所以这件事技术上完全可行。但我实际配置的时候踩了不少坑,这篇文章就是把整个过程讲清楚。

我碰到的问题

首先,Codex CLI 支持两种登录路径:

  1. Sign in with ChatGPT:浏览器 OAuth 回调,走 ChatGPT 的额度和数据策略
  2. Sign in with API key:直接用 OpenAI 平台的 API key,走 API 侧的计费

在此基础上,Codex 还允许你定义自定义的 model_provider,指向任何兼容 OpenAI 协议的第三方服务,很多第三方中转的配置方式就是让你在 config.toml 文件里覆盖他们的配置以通过中转来调用codex模型的。

因此,我最开始的配置直接用了三方中转的方案:定义一个自定义 provider,指向中转服务的 base URL,然后加上 requires_openai_auth = true。想法很朴素,觉得这样就能"借用 OpenAI 的登录态,走第三方的线路",两全其美。

阅读全文
问题描述:

对于有自己vps & 愿意本地跑Docker容器的佬友则更推荐使用CPA,不用忍受provider不同导致的记录不同步,算是资源充沛下的上位解了

最近 OpenAI 又调整了 ChatGPT OAuth 登录的 codex 用量,原本可能已经不是很宽裕的 5 小时窗口又被削减了一轮,再加上 4 月 2 号开始的双倍额度活动也结束了,我自己的实际体感是现在可能半小时到一小时就会蹬完五小时的额度……但活总得继续干下去呀?

所以我需要一个 fallback 方案:平时继续用 ChatGPT OAuth 登录,毕竟订阅额度不蹬白不蹬;额度不够的时候无缝切到第三方 API provider 继续续命。Codex CLI 本身是支持自定义 provider 和 profile 切换的,所以这件事技术上完全可行。但我实际配置的时候踩了不少坑,这篇文章就是把整个过程讲清楚。

我碰到的问题

首先,Codex CLI 支持两种登录路径:

  1. Sign in with ChatGPT:浏览器 OAuth 回调,走 ChatGPT 的额度和数据策略
  2. Sign in with API key:直接用 OpenAI 平台的 API key,走 API 侧的计费

在此基础上,Codex 还允许你定义自定义的 model_provider,指向任何兼容 OpenAI 协议的第三方服务,很多第三方中转的配置方式就是让你在 config.toml 文件里覆盖他们的配置以通过中转来调用codex模型的。

因此,我最开始的配置直接用了三方中转的方案:定义一个自定义 provider,指向中转服务的 base URL,然后加上 requires_openai_auth = true。想法很朴素,觉得这样就能"借用 OpenAI 的登录态,走第三方的线路",两全其美。

阅读全文