一份订阅，两套额度，三个入口：我把OpenAI的产品线捋了一遍

最近在ChatGPT网页、Work、Codex云端和桌面客户端之间来回切换，越用越觉得奇怪：它们都挂在同一个OpenAI账号下，也包含在同一份订阅里，却不像一套产品自然长出来的。

入口不同、历史不同、额度不同、运行环境也不同。网页里的Work和桌面里的Work看起来不完全一样；Codex明明越来越重要，早期的云端入口却一直藏在chatgpt.com/codex/cloud下面。于是我顺着这些接缝，八卦了一下OpenAI的产品线。

这当然不是什么内部爆料。下面大部分内容来自OpenAI公开资料，以及2026年8月25日我在自己Pro账户上的实际观察。涉及团队关系和产品方向的部分，只是根据公开职位变化和产品形态做的推断。

OpenAI原来确实有两条很明显的产品线

至少在2025年，ChatGPT和Codex还是两条非常清楚的线。

2025年10月，OpenAI在收购Sky的公告里仍把Nick Turley称为“VP & Head of ChatGPT”。到了2026年5月，OpenAI Forum的活动介绍仍把Thibault Sottiaux，也就是Tibo，称为Codex负责人。

一个负责ChatGPT，一个负责Codex。单看这个分工，就能解释很多产品上的差异：ChatGPT更像面向所有人的对话产品，Codex则从一开始就围绕代码库、终端和长时间任务设计。

但到了2026年6月，OpenAI在收购Ona的公告里已经把Tibo称为“Core Products Lead”。与此同时，OpenAI对Codex的宣传也从单纯的编程工具，逐渐变成面向更多工作类型的通用Agent；新推出的ChatGPT Work更是明确写着内置Codex技术。

我原来的八卦式总结是：“号称合并，其实还在内部赛马。”查完公开资料后，这句话需要改一下：组织和品牌确实正在合并，只是产品还保留着两条线分别发展时留下的接缝。

两套额度比组织架构更诚实

最先让我意识到ChatGPT和Codex并不是一套东西的，不是负责人，也不是客户端，而是额度。

OpenAI现在已经在Codex用量说明中写得很清楚：Codex、ChatGPT Work、ChatGPT for Excel和Workspace Agents共用同一套Agent用量与额度池。普通Chat和普通语音则使用另一套限制。

从用户角度看，一份ChatGPT订阅实际上至少包含两种不同的使用体验：

普通Chat：使用Chat自己的限制
Work、Codex等Agent能力：共用Agent额度池

两边的透明度也不一样。普通Chat通常只在接近限制或发生降级时给出提示，很难提前知道还剩多少；Codex和Work这边至少有专门的用量页面、重置提示和额度信息。

最有意思的是Work。它明明挂在ChatGPT里，名字也叫ChatGPT Work，消耗的却是和Codex共用的Agent额度。只看页面入口，它属于ChatGPT；只看额度和技术血缘，它又明显站在Codex这一边。

Chat、Work和Codex不是三层皮肤

OpenAI现在对这三个入口的定位已经比较清楚。

Chat适合快速问答、讨论、搜索和分析。Work负责多步骤任务，可以跨文件和应用持续工作，最后交付文档、表格、演示、报告或Web应用。Codex则继续面向软件工程，能够处理代码库、终端、测试、Review和开发工具。

它们使用的模型可能相同，界面也在逐渐靠拢，但工作环境并不相同。

2026年8月25日，我在自己Pro账户里观察到的网页云端环境大致如下：

入口	当时分配到的环境	公网访问	使用额度
Chat	约4核、4GiB内存、63GiB磁盘	不可用	Chat限制
Work	约8核、20GiB内存、63GiB磁盘	可用	Agent额度

这些不是OpenAI承诺的固定规格，只能代表当时分配给我的环境。但差异已经足够明显：Work不是给Chat换了一个按钮，而是另一种任务执行环境。

Chat和网页Work都可以通过GitHub连接器读取授权仓库，也能做一些文件、分支和提交操作。不过GitHub凭据不会进入云端沙箱，环境里也没有完整的.git工作树，所以不能像本机Codex那样直接克隆私有仓库、安装依赖、运行数据库和完成真实验证。

这也是为什么网页Work拿来做资料研究、文档整理和交付物很顺手，拿来做完整软件开发却总差一口气。它的机器比普通Chat强，也能联网，但最大的限制不是CPU和内存，而是没有真正进入项目的开发环境。

Codex网页更像旧云端线程留下的入口

我当时还能通过chatgpt.com/codex/cloud访问Codex云端任务。这个入口可以查看和发起云端开发、代码审查等工作，但明显不是Codex现在的主战场。

OpenAI当前的帮助文档已经不再把Codex列为网页端可以直接选择的体验。桌面端可以在ChatGPT和Codex之间切换，手机端可以通过Remote跟进Codex任务，网页端则主要保留Chat和Work。

所以/codex/cloud给我的感觉，更像早期“云端线程”产品留下的任务管理面。它仍然有用，却没有发展成一个与ChatGPT并列的独立网站。连域名都一直挂在chatgpt.com下面，也很符合Codex早期作为ChatGPT内部功能生长出来的历史。

当然，从一个URL推导团队地位只能算玩笑，不能当成组织事实。但这种产品痕迹确实很有意思。

真正的合流发生在桌面客户端

至少在我当前使用的版本里，ChatGPT和Codex已经被装进同一个桌面客户端。

左上角可以在ChatGPT和Codex之间切换。进入ChatGPT后，又可以选择Chat或Work；进入Codex后，则看到独立的项目、线程和开发工作流。Codex里的Quick Chat还能随时打开一个普通ChatGPT对话，用来问些不需要启动开发任务的小问题。

从外壳看，它们已经是一款应用；从历史记录、权限、额度和工作方式看，它们仍然是两套产品。

Work在桌面端又多了一层变化。网页和手机上的Work运行在云端，桌面端的Work还可以在授权后访问本地文件和应用。OpenAI官方把这些能力区分为Work Cloud、Work Local和Codex Local，并允许管理员分别控制。

这说明Work虽然内置Codex技术，也借用了Codex擅长的本地工具和长任务能力，但OpenAI并没有简单地把Codex改个名字塞进ChatGPT。它正在做的是把Codex的执行能力抽出来，包进一个更通用、更适合非开发工作的产品入口。

为什么用起来还像两家公司

现在回头看，OpenAI的方向其实已经很明显：ChatGPT继续做所有人最先打开的入口，Codex则逐渐变成承载长时间任务、工具调用和真实执行的底层能力。Work正好位于两者中间。

问题是，产品合并不可能只靠改名完成。

普通Chat和Agent仍然使用不同额度；Chat、Work和Codex的历史记录没有完全打通；网页沙箱、Work云端环境和Codex开发环境各自独立；GitHub连接器能读仓库，却不能代替完整工作树；同一个桌面客户端里，Work Local、Work Cloud和Codex Local仍然是不同权限。

组织架构和产品名称可以很快调整，额度系统、运行环境、权限模型和历史数据却需要慢慢迁移。今天看到的混乱，更像两套产品正在拼成一套产品时露出的接缝，而不是OpenAI自己也不知道要做什么。

目前最顺手的联动方式

把这些入口捋清以后，用法反而简单了。

普通Chat适合讨论问题、积累思路和整理需求，而且不消耗Agent额度。真正需要读取完整仓库、修改代码、运行测试和操作本地环境时，再切到桌面端Codex。桌面客户端支持引用已有ChatGPT对话，这种接力方式很自然。

更大的开发任务，我现在会让ChatGPT通过GitHub参与需求讨论、方案设计和独立Review，再把正式结论、分支和固定提交交给本机Codex实现与验证。具体流程已经记录在用GitHub让ChatGPT与Codex接力开发里。

网页Work则更适合真正的通用工作：跨资料研究、处理文件、生成报告、表格、演示或其他完整交付物。它当然也能碰代码，但既然消耗和Codex相同的Agent额度，又拿不到完整开发环境，就没有必要强行把它当成云端Codex替代品。

所以这次八卦后的结论，不是“ChatGPT团队要完了”，也不是“Codex团队赢了”。更像是Codex正在从一款编程产品，变成OpenAI整套Agent产品的执行底盘；ChatGPT则继续做那个所有人最先打开的门。

至于这些入口以后还会怎么合并，过几个月再看，文章里大概又会有一半需要更新。