Skip to main content
Codex 能否使用、能用多久、一次任务要花多少,取决于四个彼此独立的问题:
  1. 你用什么身份登录;
  2. 当前入口允许使用哪些模型;
  3. 任务消耗了多少上下文与推理资源;
  4. 费用由订阅额度、额外 credits,还是 API 账单承担。
本页不记录某个时点的套餐价格、消息条数或模型名单。 这些数字变化很快,写死后反而容易误导。 这里提供的是一套稳定的方法:先认清账本,再选档位,最后用实际用量校准预算。
ChatGPT 订阅费用与 OpenAI API 费用不是同一笔钱。 购买 ChatGPT 套餐通常不等于获得等额 API 余额;创建 API key 也不会自动使用 ChatGPT 套餐内的 Codex 额度。

先用一张表分清两套账

一个实用但不是绝对的默认判断是:
  • 人坐在电脑前持续协作,先考虑 ChatGPT 账号登录;
  • 无人值守任务、CI 或服务端集成,使用 API key 或组织批准的服务身份;
  • 团队既有人机协作又有自动化时,分别管理两套预算,不要混成一个“AI 经费”。

第一步:确认当前登录方式

不要根据“我订了 ChatGPT”或“电脑里有 key”来猜 Codex 正在走哪套账。 应当查看当前会话和本机配置。 在 Codex CLI 中先检查:
再查看当前版本支持的登录与退出命令:
不同版本的状态页字段可能不同。 你要确认的是以下事实,而不是寻找某个固定界面:
  • 当前是 ChatGPT 账号授权,还是 API 凭据;
  • 当前模型是什么;
  • 当前会话的上下文占用是否异常;
  • 是否启用了会增加消耗的推理强度或加速选项;
  • 当前工作区或组织是否施加了额外限制。
如果无法确认费用会落到哪里,先停止长任务。 退出后用明确的身份重新登录,比在错误账本上继续运行更容易控制成本。

ChatGPT 订阅:购买的是使用权

ChatGPT 套餐中的 Codex 权益通常表现为产品内可用量。 它不应被理解成一笔可以自由转移到 API 的 token 余额。

为什么不是固定“消息数”

同样发送一条消息,实际工作量可能差很多:
  • 只解释十行代码;
  • 扫描整个仓库;
  • 读取长会话历史;
  • 调用多个工具并分析输出;
  • 进行高强度推理;
  • 在云端运行持续较久的任务。
因此,官方页面即使显示消息范围,也只能作为容量提示。 它不能承诺每个用户、每个任务都能发送相同条数。 订阅额度常受这些因素共同影响:

套餐怎么选

不要先问“哪一档最强”,先连续记录一到两周:
  • 每周实际使用几天;
  • 哪类任务最常触达限制;
  • 限制发生时是否阻塞关键工作;
  • 额外 credits 的使用是否偶发;
  • 团队是否需要管理、审计、SSO 或数据治理能力。
据此选择: 升级前应验证“限制是不是套餐容量造成的”。 模型权限、地区、工作区策略、版本过旧或服务异常,都可能看起来像额度不足。

额度用完时怎么判断

先记录错误原文和发生时间,再区分:
  1. 当前时间窗口的用量限制;
  2. 更长周期的公平使用限制;
  3. 某个模型暂时不可用;
  4. 工作区管理员禁用了相关能力;
  5. 服务拥塞、网络或登录状态失效;
  6. 额外 credits 不足或没有启用。
不要看到一次失败就立即升级套餐。 如果换成小范围任务或其他可用模型后恢复,问题可能是模型容量或单任务负载,而不是总额度。

API key:按量账单必须配预算护栏

API key 登录时,主要成本来自模型 API 的实际用量。 典型账单项包括输入 token、缓存输入、输出 token,以及模型文档列出的其他资源。 输入不只是你刚写的提示词,还可能包含:
  • 系统和项目指令;
  • AGENTS.md 等规则文件;
  • 当前会话历史;
  • Codex 读取的代码与日志;
  • MCP 工具定义;
  • 工具调用后的输出;
  • 压缩后继续保留的上下文摘要。
输出也不只是最终回答。 推理模型可能按其官方计费口径计算内部推理相关 token。 具体字段与单价必须查看当前模型文档和 API 用量记录。

先建立项目级隔离

不要让所有开发者、CI 和实验脚本共用一个没有边界的 key。 更稳妥的组织方式是:
  1. 按团队或应用建立 Platform 项目;
  2. 按环境区分开发、测试和生产;
  3. 为自动化创建专用凭据;
  4. 为项目设置预算提醒和可用模型范围;
  5. 定期轮换,并撤销不再使用的 key;
  6. 用平台用量页按项目、模型和时间定位异常。
预算提醒不是强制断路器的同义词。 应查看当前 Platform 是否支持硬限制、软限制或仅发送告警,并用应用侧限流补齐缺口。

一个可执行的 API 预算模型

不要靠猜测“每月大概多少钱”。 先抽样,再外推。 定义:
  • N:每月同类任务数量;
  • I:单任务平均输入 token;
  • C:其中可按缓存价计算的输入 token;
  • O:单任务平均输出及相关计费 token;
  • Pi、Pc、Po:官网当前对应费率;
  • R:重试、失败、返工和峰值的冗余系数。
估算式:
实际计算时,把官网计价单位换算到同一单位。 不要在团队文档里抄一组长期不更新的价格。 应保存核验日期、模型页链接和计算表使用的费率快照。

预算分三级

停止线必须由你能验证的机制实现。 不要仅因为控制台存在“预算”输入框,就假设超额后一定会自动停止请求。

额度口径:不要混为一谈

另一个常见误区是“消息越短越省”。 一句“帮我优化整个项目”虽然字少,却可能触发大范围探索和多轮返工。 一段写清文件、约束和验收标准的提示反而可能更省。

模型选择:先选能力档位

模型列表会变化,账号可见范围也不同。 因此应按角色理解模型,而不是把某个名称永久写进团队规范。

三类常见档位

若产品提供面向实时协作的预览模型,把它视为独立档位。 预览意味着可用范围、能力边界和持续时间都可能变化,不宜作为关键流水线的唯一依赖。

先做任务分级

选择模型前,先评估五个维度:
  1. 范围:单文件、单模块,还是跨系统;
  2. 歧义:验收条件是否明确;
  3. 代价:做错后是否会影响数据、安全或生产;
  4. 可验证性:是否有测试、类型检查或基准;
  5. 时效性:是交互式秒回,还是可以后台运行。
推荐匹配如下: 逐级升级比一次追求“完美模型”更容易控制成本:

推理强度:同一个模型该想多久

推理强度控制模型在回答或行动前投入多少计算。 可选名称、默认值和支持范围随模型变化,应以 /model 选择器和官方模型页为准。 调节顺序建议:
  • 结果正确但等待太久:先降低推理强度;
  • 结果表面可用但遗漏边界:先提高一档并补充验收标准;
  • 模型反复误解领域或跨文件关系:再换高能力档;
  • 任务本身含糊:先澄清需求,不能靠最高强度替代需求定义。
推理强度越高不代表一定更正确。 没有测试、错误上下文和模糊目标仍会导致高成本返工。

服务层级与快速模式

部分入口可能提供快速模式或不同服务层级。 它们通常改变请求调度优先级和响应速度,而不是直接提高模型的推理质量。 适合使用更快服务层级的情况:
  • 开发者正在等待关键交互结果;
  • 线上事故排查中,每分钟都有明确价值;
  • 短时演示或发布窗口需要可预测延迟;
  • 已确认额外 credits 或 API 费用在预算内。
不适合的情况:
  • 夜间批处理;
  • 没有截止时间的仓库索引;
  • 任务仍会因需求不清反复返工;
  • 团队尚未建立成本归属和告警。
不同登录方式可用的服务层级可能不同。 配置键、功能开关和倍率也可能变化。 先查看当前版本帮助、/status、/model 与官方速度文档,不要照搬旧教程中的倍率。

一套日常决策流程

1. 确认账本

  • 交互式工作是否走 ChatGPT 登录;
  • 自动化是否使用独立 API 项目;
  • 费用归属和预算负责人是否明确。

2. 给任务分级

  • 低风险、范围明确:轻量或均衡档;
  • 中等复杂度:均衡档配中等推理;
  • 高风险或高歧义:高能力档,先计划后执行。

3. 控制上下文

  • 指定相关文件和错误日志;
  • 不要无条件读取整个仓库;
  • 关闭当前任务不需要的 MCP server;
  • 不相关任务新开会话;
  • 长会话按当前版本支持的方式压缩或重开。

4. 写清完成条件

5. 先小样本后扩量

批处理先运行一个或少量样本。 确认质量、耗时和用量正常后,再扩大并发或任务数。

6. 完成后记录

  • 登录方式;
  • 模型档位与推理强度;
  • 是否开启快速服务层级;
  • 任务耗时、成功率和返工次数;
  • API 用量或订阅额度变化;
  • 验证结果。
这些数据比网上任何“一个套餐能发多少条”的经验更适合你的团队。

用量异常诊断

症状一:订阅额度下降得比以前快

按顺序检查:
  1. 当前模型是否切到了高能力档;
  2. 推理强度是否被设为高或最高;
  3. 是否开启了快速模式;
  4. 会话是否已经很长;
  5. AGENTS.md、日志或生成文件是否异常膨胀;
  6. 是否新增了许多 MCP 工具定义;
  7. 任务是否从本地小改变成云端长任务;
  8. 是否存在大量失败重试和返工;
  9. 官方近期是否调整了额度政策。

症状二:API 费用突然上升

先在 Platform 用量页按项目、模型和日期切分,再检查:
  • 是否有新部署或定时任务;
  • 请求量、输入 token、输出 token 哪一项增长;
  • 是否切换了费率更高的模型;
  • 缓存命中是否下降;
  • 是否发生重试风暴;
  • 是否把大型日志或整个仓库重复送入上下文;
  • 是否有泄露的 key 从陌生来源发起请求;
  • 并发和单任务最大输出是否缺少限制。
发现无法解释的调用时,先撤销或轮换受影响凭据,再调查来源。 不要为了保留现场而让可疑 key 继续有效。

症状三:提示“受限”,但还有预算

预算余额正常不代表请求一定能执行。 继续检查:
  • 模型是否对该账号或项目开放;
  • 组织验证或付款状态是否满足要求;
  • 请求速率或 token 速率是否触顶;
  • 工作区管理员是否限制了模型;
  • 当前地区、入口或客户端版本是否支持该功能;
  • OpenAI 状态页是否报告服务事件。

症状四:任务越来越慢

动态信息核验清单

模型、套餐和额度属于动态信息。 作出购买或配置决定前,按以下顺序核验。

官方来源

  1. Codex 定价与套餐说明:https://developers.openai.com/codex/pricing
  2. Codex 模型说明:https://developers.openai.com/codex/models
  3. Codex 速度与服务层级:https://developers.openai.com/codex/speed
  4. ChatGPT 当前套餐:https://chatgpt.com/pricing
  5. API 当前价格:https://platform.openai.com/docs/pricing
  6. API 用量与账单:登录 OpenAI Platform 后查看 Usage 与 Billing
  7. 服务状态:https://status.openai.com/

本机事实

在交互会话中检查:
斜杠命令也可能随版本变化。 如果命令不存在,以当前 CLI 帮助和交互命令列表为准。

安全边界

不要暴露 API key

API key 不应出现在:
  • 提示词和聊天记录;
  • Git 仓库;
  • AGENTS.md;
  • Issue、PR、日志和截图;
  • 前端代码或移动应用包;
  • 可被普通用户读取的配置文件;
  • 命令历史和共享终端录屏。
优先使用环境变量、操作系统凭据库或组织批准的 secrets manager。 示例只能使用占位符:
不要把真实 key 写进示例命令。

给自动化设置停止条件

自动化任务至少应具备:
  • 明确的项目和账单归属;
  • 最大并发;
  • 单任务超时;
  • 最大重试次数和指数退避;
  • 最大输入和输出规模;
  • 日预算或任务预算;
  • 异常时停止而不是无限重试;
  • 不接触生产密钥和客户数据的默认策略。

不要用更贵模型替代人工审批

模型档位再高,也不能独立批准:
  • 生产发布;
  • 数据删除或不可逆迁移;
  • 权限提升;
  • 密钥导出;
  • 财务交易;
  • 对外发送敏感信息;
  • 跳过测试或安全检查。
高风险操作需要可追溯的人类批准、最小权限和回滚方案。

最终选择速查

验收清单

完成账号和模型配置后,逐项确认:
  • 已明确当前是 ChatGPT 登录还是 API key;
  • 知道费用由哪个个人、工作区或 Platform 项目承担;
  • 没有把 ChatGPT 订阅误当成 API 余额;
  • 模型与推理强度匹配任务难度;
  • 快速服务层级只在确有时效价值时开启;
  • 已设置用量观察、预警和停止机制;
  • API key 未进入仓库、日志或对话;
  • 已用小样本测得真实耗时、质量和用量;
  • 动态价格、模型权限和限制来自当前官方页面;
  • 高风险操作仍保留人工审批与回滚方案。
只需记住三个原则:
  1. 先分账:ChatGPT 订阅与 API 是两套身份、两套额度、两套账单;
  2. 再匹配:按任务风险与复杂度选择模型、推理强度和服务层级;
  3. 用数据校准:以 /status、Platform Usage、真实样本和当前官方页面为准。
这样做比记住任何一组价格、消息条数或模型名称都更可靠。 参考资料:参考/codex/04-pricing.md、参考/codex/30-models.md、参考/codex/31-speed.md。