--- layout: post.njk source: https://yage.ai/share/chatgpt-subscription-oauth-20261013.html speaker: yage.ai title: 不想为 GPT 付两次钱：把 ChatGPT 订阅接进你的工具 date: '2026-10-13' summary: 文章解析了将ChatGPT订阅接入开发工具的三种路径：官方API Key、新推出的Sign in with ChatGPT协议及逆向Codex身份的灰色方案。重点介绍了官方协议的技术规范、限制及选型建议，旨在帮助开发者利用闲置订阅算力降低开发成本。 area: tech-engineering category: ai-application tags: - chatgpt-subscription - oauth-integration - api-billing - developer-tools - openai people: [] companies_orgs: - openai products_models: - chatgpt - codex - sign-in-with-chatgpt media_books: [] draft: true status: evergreen --- 很多人每个月都在给ChatGPT Plus或Pro付费，但写代码或使用本地智能体时，用的开发工具往往还要再填一个独立的API key，按token消耗在另一张账单上扣款。既然订阅里已经包含了充足的推理算力，为什么不能直接把这个额度接到自己的开发环境里？ 过去要想用订阅额度调用第三方工具，只能借用官方客户端公开的身份标识，在官方没有明确禁止的灰色地带调用私有接口。直到2026年9月，OpenAI推出了Sign in with ChatGPT，这件事才有了官方的协议。这篇文章主要想介绍把ChatGPT订阅接入外部工具的技术演进、官方协议的具体规则和限制，以及在官方API key、官方订阅授权和复用官方客户端订阅身份这三种做法之间怎么取舍。文章的末尾我们也会提供一个自己实现的、可以直接运行的参考实现。 ## 两条账单：API 为什么要按 token 另付一遍钱 如果你平时在本地折腾 AI 工具链，对这种两张账单并行的尴尬应该不陌生；团队和公司把用量放大之后，这笔重复开销只会更扎眼：一边是信用卡每月固定扣款的 ChatGPT 订阅费，一边是 OpenAI 开发者后台每隔几天就自动充值的 API 账单。调用的明明是同一家公司的模型，为什么手头现成的订阅额度，就不能用来抵扣写代码和跑智能体的消耗？ 这两笔账为什么不通，得从它们各自的收钱方式说起。面向开发者的开放平台，核心是 Responses API 推理端点，它纯粹按实际输入和输出的 token 数量计费。翻看 官方最新定价标准，专用模型 gpt-6.1-sol，每 100 万 token 输入 2 美元、输出 10 美元；换成更高一档的旗舰模型 gpt-6-astra，输出要涨到 50 美元。中间还有轻量模型和折中档，单价便宜很多，但本地工具只要频繁把大代码库塞进上下文、让模型跑多轮长思考，token 累积起来开销涨得很快。 另一面是面向普通用户或团队的 ChatGPT 订阅。个人从免费的 Free、轻量的 Go，到主力档 Plus（每月 20 美元）都有，再到按算力分档的 Pro。团队则按人头计费，ChatGPT 商业版方案 标准坐席按月付每人每月 25 美元，年付有折扣。 还有一点容易忽略：ChatGPT 订阅本来就内置了 Codex（官方的编程功能），而且所有套餐的 Codex 和 ChatGPT Work 共用一个用量池。这块额度折算成 API 调用相当可观，SemiAnalysis 的测算认为，OpenAI 订阅的 API-equivalent value 大约是订阅费的 12 倍，以 $200 档的 Pro 换算下来接近两三千美元的 API 花费。换句话说，你手里本来就有一大笔没用起来的算力，却还在为第三方工具另开一张 API 账单，这才让想用订阅这件事变得很有吸引力。 这两套产品在计费和协议体系上一直是分开的。官方在商业版的 FAQ 里也明确说明，ChatGPT 商业版订阅不包括 API 用量，API 使用需要额外付费。从协议上看，消费级产品由 OpenAI 使用条款 管辖，但开发者 API 用的是 商业服务协议，商业条款中明确指出不适用于消费级个人服务。两边账户余额也不互通。很多人有高级订阅却在第三方工具里还要绑卡，就是因为官方在商业规则上把这两个体系隔开了。 ## 想用订阅跑自己的工具，过去只有一条灰路 面对这两张账单，一个自然的想法就是能不能让外部工具假扮成官方客户端，直接去扣订阅里的额度。这里面主要是两件事：先是身份认证，确认当前是谁在发起调用；再是计费归属，确定这笔调用由谁来买单。 API key 可以轻松实现计费，但用户需要拥有开发者账号并且持续充值。ChatGPT 的订阅虽然预付了算力，但官方只支持他们的网页端、移动端和桌面客户端。不过官方自己的编程助手 Codex 是个例外。Codex 客户端（前面提到的 gpt-6.1-sol 就是它默认用的代码模型）提供了两种平行的登录途径：传统 API key，和 基于 ChatGPT 订阅的登录认证。 既然官方的 Codex 客户端已经支持用 ChatGPT 订阅来登录，那其他第三方客户端有没有可能也用同样的方式呢？遗憾的是，官方并没有提供 API。因此，开源社区通过逆向工程官方客户端，发现了整个实现流程。正如 开发者社区的深入讨论 所揭示的那样，不少编辑器里的代码插件（比如 Roo Code）选择直接复用官方 Codex 客户端公开发布的 OAuth 客户端标识符 client_id，在本地调起浏览器完成授权，接着把推理请求直接转发到 ChatGPT 的私有后端端点 chatgpt.com/backend-api/codex/responses。 这种做法技术上确实有效，用户不用多花钱，就能用上订阅里的 Codex 算力。但在契约性质上，它从来没有得到过官方的正式支持。 官方的态度一直是暧昧的。2026 年 2 月 9 日，OpenAI 负责 Codex 的维护者 etraut-openai 在 GitHub 讨论区公开回应 开发者时表达了个人看法：作为工程师而非律师，官方的使用条款和代码开源协议相对宽松，像开源的终端编程工具 OpenCode 也在做类似的事。这段非正式的回复，不少开发者当时把它当成了一种事实上的默许。 但在官方的文档和协议中，这个领域始终是模棱两可的灰色地带。官方的使用条款明确禁止与他人共享账户凭据，也明文禁止绕过任何速率限制、技术保护或安全缓解措施。OpenHands 软件代理开发团队在进行了合规审计后也指出，主流模型厂商明确表示不鼓励甚至禁止使用第三方客户端对消费级产品进行自动化调用，对于生产环境中的严肃需求，他们仍然建议通过官方 API key 的方式进行调用。 这种局面一直维持到 2026 年秋季：大家虽然靠着私有接口把工具跑通了，但心里清楚这是一条未承诺稳定、缺乏 SLA 保障且随时可能因接口变动而失效的临时通路。 ## 官方路径：Sign in with ChatGPT 2026 年 9 月 29 日，OpenAI 在 DevDay 上正式发布了 Sign in with ChatGPT 服务。它要解决的核心问题，是让第三方工具在用户授权之后，可以名正言顺地花掉用户自己 ChatGPT 订阅里的额度。这是官方第一次公开承认并放行这种用法，也是开源项目和本地工具摆脱私有端点的正规入口。首发就公布了 16 家合作伙伴。 Sign in with ChatGPT 把授权拆成两层：确认身份的身份层，和真正花掉订阅额度的额度层，中间用一个可选开关隔开 在官方公布的生态体系中，开源软件获得了明确的席位。根据 官方接入指南与集成名单，首批开源集成伙伴涵盖了 OpenClaw、OpenCode、Pi 以及 T3 等项目；商业级试用应用则包含了 Devin、Notion、Vercel、Warp、Airtable、GitLab 与 Supabase 等产品。 这引入了一个关键的新概念：授权分为两个层次： 1. 基础身份认证层：在 官方快速入门文档 中定义，其授权范围为标准的 openid profile email。该层仅负责确认用户的 ChatGPT 账号身份并返回 ID token，官方在此处做出明确说明：基础身份权限不提供对用户 ChatGPT 历史对话或 OpenAI API 资源的任何访问能力。 2. 订阅额度共享层：在 面向开源项目的额度共享规范 中定义，要求显式申请 offline_access resource.invoke chatgpt.tokens.use.direct 权限，同时必须把 resource 参数设为 https://api.openai.com/v1。只有用户在授权界面勾选允许该应用调用自己的订阅额度，外部工具才能发起实际的模型推理。 在开放范围上，商业应用的接入仍处于有限试用阶段；但对于订阅额度调用能力，官方规定在发布初期即全面向所有开源项目、在本地运行的个人项目以及选定的私有客户端开放。 在所有权和计费方面，官方文档 指出，拥有Go、Plus或Pro订阅的用户可以自行授权兼容的应用程序使用自己的订阅，无需生成或共享个人API key。所有合格请求都会直接计入用户套餐里包含的用量额度。这是一种典型的用户自带订阅模式（Bring Your Own, BYO），不用大家混用同一个共享账号。用户始终可以在 ChatGPT 的设置中心随时查看已授权工具的活跃状态，监控算力使用情况，并随时单方面撤销授权。 对于开源或本地部署的项目，官方提供了一套动态注册机制，不需要提前申请客户端密钥。客户端首次向 账户授权端点 发起请求时，统一将 client_id 设置为公共预留标识 dynamic_agent_client，并传入当前运行宿主的唯一标识 ext_agent_host_id 以及工具名称提示 agent_name_hint。 授权流程在本地环回端点 127.0.0.1:1455/auth/callback 接收回调。验证通过后，OpenAI 会在响应中下发一个绑定当前用户账号与所选 workspace 的正式 client_id，供后续流程长期复用。整个过程既不需要存储客户端密钥，也不需要开发者注册商业 API key。 在推理端点上，官方给出了很明确的技术约束：所有推理请求必须通过 POST 发送到公开端点 api.openai.com/v1/responses。官方文档以加粗字体发出警告：必须使用上述公开 Responses API 端点，严禁将请求导向 ChatGPT 的 backend-api 私有端点。 每次推理请求必须在 JSON 载荷中强制声明 store:false（不保存用于后续检索或续接的响应状态）与 stream:true（强制流式输出）。凭证有效周期方面，访问令牌的有效时间为 1 小时，刷新令牌则支持 30 天滑动窗口轮转。 官方将当前订阅额度共享定位为预览阶段，相比于完全自由的 API key，它仍然包含很多严格的限制。根据 预览阶段限制说明，调用方无法使用常见的采样调优参数，诸如 temperature、max_output_tokens、prompt、background、conversation、metadata 以及 moderation 等字段均不支持配置；不能使用官方提供的很多功能，比如内置的代码解释器、文件检索、图像生成、原生计算机操作、云端托管的 MCP 连接器等；不能传入音视频作为输入、不能进行文件上传和语音转写等。此外，这个接口也不支持基于服务端保存的历史自动进行对话延续，而是在工具端手动把历史消息加入请求中。 ## 一个能跑的参考实现：chat_gpt_oauth skill 上一节介绍的是官方给的正道。这一节要看的是一条更早、也更直接、但已经不推荐长期依赖的路：把前面提到的那条灰路写成一个能跑的最小实现。它更像一份教学样本，价值在于把用订阅换 token 的整套机制摊开给你看清，本身不适合当作长期依赖。我们把它开源在了 chat-gpt-oauth-skill 代码库。 要说明的是，它带一个能单独跑的命令行，但你完全可以不用它，那个命令行本身意义不大。它真正的定位是一份 reference implementation：把它集成进你自己的 agent 或 sub-agent 里，让用 ChatGPT 订阅发请求这件事，变成工具链里的一个模块。它完整演示了 OAuth 凭据交换、令牌生命周期管理和 Codex 推理请求构造，读代码就能看清 subscription token 长什么样、请求是怎么发出去的。 安装不需要自己啃文档。把仓库链接直接丢给你的 AI 编程工具（Codex、Claude Code、OpenCode 都行），让它先把仓库读一遍，再照着里面的说明安装、配置、跑通 demo 就行。它默认把 token 以明文 JSON 存在 ~/.chatgpt_oauth/token.json（权限 0600），这是刻意留给调试观察的教学设计，不是生产级的安全做法。 它走的通信目标是官方 Codex 私有后端，和上一节的官方 Sign in with ChatGPT 是同一诉求下的两条路径：官方协议打 api.openai.com，这个 skill 则复用官方 Codex 客户端的既有身份打私有端点。所以它不是一个官方 SDK，依赖的是没有 SLA 保证的私有端点，只适合个人技术探索、学习验证，以及完全由你自己掌控的本地轻量工具。 ## 总结：还有哪些路，以及怎么选 把这些路并排放在一起，才好看清每一条适合谁。 接入 ChatGPT 的三条路：API key 按量付费、Sign in with ChatGPT 用订阅额度、复用 Codex 身份走灰色地带，各自代价不同 目前接入 OpenAI 模型的路径主要有三条： 第一条是标准的 官方 API key 路线。它是 OpenAI 开发者生态中的一等公民，打向标准的 api.openai.com/v1/responses 端点，受官方 Services Agreement 管辖。这条路径的能力最完整：支持所选模型开放的全部参数、官方的代码解释器与文件检索等全套工具链、各类模态输入。它的代价是按 token 计费，无法共享个人 ChatGPT 订阅内已有的额度。 第二条是官方的 Sign in with ChatGPT 订阅额度路线。它专为开源项目和自用脚本提供官方认可的订阅消费通道，用户可以光明正大地携带自己的 Plus、Pro 订阅登录，而无需在第三方工具中暴露高风险的 API key，并且可以随时在 ChatGPT 设置中查看与切断授权。但它的代价是目前仍处于预览阶段，官方裁掉了不少进阶微调参数和托管工具，输入也只支持所选模型允许的文本、图像和文件。 第三条是直接复用 Codex 客户端身份的逆向协议路线（如 chat_gpt_oauth skill），它在本地可以最大限度地压榨出订阅所包含的 Codex 专用模型能力，但它运行在官方未明文背书的灰色地带，缺乏长期稳定性保证，仅适合个人折腾与本地过渡。 这三条里，一条是另开 API 账单，两条是想办法用上订阅额度。 面对这些分支，开发者的选型判据可以归纳为以下几条： - 追求零额外成本，希望消耗个人闲置订阅：优先尝试 Sign in with ChatGPT；如果受限于预览期的参数限制或需要特定的 Codex 交互体验，且完全清楚其非官方性质，可暂时采用类似 chat_gpt_oauth 的本地参考实现。 - 追求生产级稳定性，需要复杂的工程调优与多模态工具：直接选用官方 API key。为按量付费买单，换取的是更完整的官方 API 能力与商业协议保障。 使用个人订阅去驱动第三方工具而非按量计价的 API，在过去很长一段时间里只能寄希望于借用官方客户端身份在灰色地带探索。而 2026 年 9 月推出的 Sign in with ChatGPT，首次在官方契约层面为开源与本地开发打开了正规入口。尽管目前这条正规通道仍然受到严格的预览限制，但它标志着消费级订阅与第三方开发者工具之间的割裂开始弥合。 最后补一句和主线无关的：如果你要解决的是另一类问题，比如让程序在云端长时间自主运行，官方另有 Agents API。它把驱动 Codex 的长任务编排能力做成托管服务开放出来，但按标准 API 费率计费、不消耗订阅额度，这里就不展开了。