Agent.Space 博客

Codex 官方订阅、API 与托管 Workspace 怎么选?

从访问方式、账单归属、运行环境、持久化、协作与原生功能,对比 Codex 订阅、API 和托管 Workspace。

Codex 订阅、OpenAI API 账号和托管 Workspace,解决的是不同层面的问题。

  • 如果你需要 OpenAI 管理的 Codex 访问,以及与该账号或 Workspace 绑定的原生功能,选择符合资格的 ChatGPT 订阅
  • 如果本地或程序化工作应该按实际用量计入你控制的 API Organization 或 Project,选择 OpenAI API 计费
  • 如果更重要的是持久项目文件、Session、Preview、团队协作或跨 Agent 交接,评估独立的托管 Workspace

这三条路径不是同一余额的三个名字。先决定谁应该拥有账单、工作在哪里运行,以及项目状态放在哪里。Codex Agent Hub汇总了当前产品介绍与相关文章。

上次核验:2026-09-02。 认证支持、套餐、Credits、模型可用性、价格与产品功能都可能变化。购买或部署前,请重新检查文中链接的官方来源和各产品线上账号设置。

简短答案

个人或组织如果需要当前原生 Codex 体验,尤其是要求 ChatGPT 登录的功能,符合资格的 ChatGPT 套餐通常最直接。需要让本地 Codex 或自动化按量计入某个 OpenAI Platform Project 时,API Key 的账单边界更清楚。需要把项目和协作者长期放在 harness 周围时,托管 Workspace 属于另一个产品层。

本文负责选择运行路径,不维护实时价格或额度。当前套餐、Credits、API 账单和费率对比请查看 Codex 价格指南,然后再回到本文判断账单、Runtime 和项目状态分别由谁负责。

对比三条 Codex 访问路径

判断项符合资格的 ChatGPT 订阅OpenAI API 路径独立托管 Workspace
访问提供方OpenAI / ChatGPTOpenAI PlatformWorkspace 提供方及其支持的 harness 与模型访问
账单归属个人或 ChatGPT WorkspaceAPI Organization 或 ProjectWorkspace 账号或组织
典型执行位置OpenAI 原生本地或云端 Codex 入口使用 API Key 的本地 Codex,或由你运营的程序化集成提供方管理的云端 Workspace
项目持久化取决于所选原生入口由你在 API 之外设计和运营Workspace 保存其合同内支持的项目状态
协作原生 ChatGPT/Codex Workspace 与集成功能由你建设或运营协作层Workspace 成员、共享文件、Session 与交接
对原生功能的依赖需要 OpenAI 原生功能时最合适部分 ChatGPT 或 Cloud 相关功能受限或不可用不承诺包含每项 OpenAI 原生功能
主要运营责任管理账号、Workspace 与限制保护 Key,管理预算、Runtime、日志与集成核对提供方条款、权限、支持组合与项目控制

这里的托管选项刻意使用通用描述。必须查看一个产品真实的公开合同;“托管”这个词本身不能证明它具有持久化、安全、协作或 Codex 支持。

需要 OpenAI 原生体验时,选择 Codex 订阅

OpenAI 当前的 Codex 认证文档会区分“通过 ChatGPT 登录获得订阅访问”和“通过 API Key 登录获得按量访问”。需要 OpenAI 账号或 Workspace 专属能力时,ChatGPT 登录是自然路径。

下面这些情况适合订阅路径:

  • 希望在符合资格的 ChatGPT 套餐或组织 Seat 下使用 Codex;
  • 目标是原生 Codex App、CLI、IDE、Cloud 或集成工作流;
  • 希望适用 ChatGPT Workspace 的权限、角色、数据保留或数据驻留控制;
  • 普通交互工作不想另外管理 API Project。

最重要的入口边界是 Codex Cloud:OpenAI 当前要求通过 ChatGPT 登录。相比之下,ChatGPT Desktop 中的本地工作、Codex CLI 与 IDE Extension 当前可以支持 ChatGPT 登录或 API Key。

不要从本文推断套餐资格、具体额度或固定任务数;最终仍应以 OpenAI 线上价格和用量页面为准。

需要本地或程序化控制时,选择 API 计费

OpenAI API Key 会建立独立的按量计费路径。OpenAI 明确说明,用 Key 认证的本地 Codex 会按标准 API Rate 计入 OpenAI Platform 账号,而不会消耗 ChatGPT 套餐包含的 Credits。

下面这些情况适合 API 路径:

  • 本地 Codex 用量应该归属某个明确的 API Organization 或 Project;
  • 自动化需要非交互 Credential 和 API 预算;
  • 组织已经能运营所需 Runtime、Secret 存储、日志与支出控制;
  • 你在搭建集成,需要程序化控制,而不是完整的最终用户 Workspace。

非交互工作并不总是意味着 API 计费。**企业认证细节核验于 2026 年 9 月 4 日:**符合资格的 ChatGPT Business 与 Enterprise Workspace 可以允许可信本地自动化使用 Codex Access Token,沿用 Workspace 身份及其权益。它需要管理员授予 Token 创建权限,也需要用户具备本地 Codex 权限;创建 Token 不会改变 Seat、角色或本地权限。这类 Token 不是 Platform API Key,不能替代后者调用通用模型 API。

还要区分两种 API 用法。API Key 可以认证受支持的本地 Codex 入口;直接调用模型 API、使用 Codex SDK 或构建其他程序化集成,则会在模型调用外增加应用责任。它们都可能进入 API 账单,但界面并不相同,也不会自动获得同一套 Agent Loop、文件、权限和持久化能力。

API 访问也不等于“没有 Plus 就免费使用 Codex”,账单只是转移到了 API 账号。无需 ChatGPT 订阅使用 Codex一文说明了受支持的本地入口和登录步骤,但不会把这个事实写成费用承诺。

项目需要持续和流转时,选择托管 Workspace

当真正昂贵的问题不只是获得一次模型回复时,托管 Workspace 才有意义。项目可能需要保存文件、持续 Session、Preview、受控成员关系,或在人和不同 Agent harness 之间交接。

Agent.Space 是一个独立托管选项。它的公开产品合同会把模型访问、Codex harness、Session 与 Workspace 分开。Codex 可以在自己的 Session 中处理已保存项目;另一个受支持 Agent 则可以在独立 Session 中根据当前文件与明确交接继续工作。

这不会让 Agent.Space 变成 OpenAI 产品。Agent.Space 额度不是 ChatGPT 订阅、ChatGPT Credits、OpenAI API 余额或共享 OpenAI 登录。Agent.Space 也不保证支持任意 Codex 模型组合,更不会复制每项 OpenAI 原生功能。应检查当前产品选择器和条款,确认实际可用内容。

在 Agent.Space 使用 Codex 的实操指南提供了一条用小型、可审查任务验证这条路径的方法。

不要混用余额和身份

ChatGPT 套餐用量、符合资格的 ChatGPT Credits、OpenAI Platform API 账单和独立托管 Workspace 套餐,应始终作为四套独立账本。本文只说明每条运行路径对应哪套账本,详细计费比较由价格指南负责。OpenAI 当前的 Credits 文档也明确说明,ChatGPT Usage Credits 不是 API Credits,不能假设一个产品中的付款会自动为另一个产品充值。

身份也要分开。不要用共享个人 ChatGPT 登录或 API Key 来解决团队协作。应指定正确所有者,只授予必要权限,在可用时设置预算或限制。切换 Codex CLI 计费路径前,先用 codex login status 确认实际生效的认证方式;仅凭模型名称,不能判断正在扣费的账号或余额。

数据和管理边界会跟随所选路径。ChatGPT 登录适用对应的 ChatGPT Workspace 控制;API Key 适用 API Organization 设置。独立托管 Workspace 还会增加自己的访问、存储与运营条款,并与相关上游模型或 harness 条款同时存在。

用同一个工作负载做决定

选择一个你已经理解的小任务来比较各条路径。保持初始文件和验收标准不变,然后记录:

  • 准确的产品入口与认证路径;
  • 实际可用的模型和设置;
  • 哪个账号收到费用或消耗额度;
  • 配置时间、Key 或账号管理与权限请求;
  • 已保存文件、验证输出和最终接受的结果;
  • Session 或进程结束后还保留了什么;
  • 另一个人怎样审查或继续工作;
  • 必需的原生功能是存在还是缺失。

不要把一次运行变成普遍成本结论,它只是一个带日期的工作负载样本。能够分别说清账单所有者、Runtime 所有者、项目状态所有者、审查者和必需原生入口时,这项选择才真正完成。