> ## Documentation Index
> Fetch the complete documentation index at: https://aicoding.cscitech.top/llms.txt
> Use this file to discover all available pages before exploring further.

# 账号额度与模型选择

> 分清 ChatGPT 订阅与 API key 的计费边界，按任务选择模型、推理强度和服务层级，并建立预算与用量诊断方法。

Codex 能否使用、能用多久、一次任务要花多少，取决于四个彼此独立的问题：

1. 你用什么身份登录；
2. 当前入口允许使用哪些模型；
3. 任务消耗了多少上下文与推理资源；
4. 费用由订阅额度、额外 credits，还是 API 账单承担。

本页不记录某个时点的套餐价格、消息条数或模型名单。
这些数字变化很快，写死后反而容易误导。
这里提供的是一套稳定的方法：先认清账本，再选档位，最后用实际用量校准预算。

<Warning>
  ChatGPT 订阅费用与 OpenAI API 费用不是同一笔钱。
  购买 ChatGPT 套餐通常不等于获得等额 API 余额；创建 API key 也不会自动使用 ChatGPT 套餐内的 Codex 额度。
</Warning>

## 先用一张表分清两套账

| 维度    | ChatGPT 账号登录               | API key 登录                 |
| ----- | -------------------------- | -------------------------- |
| 主要使用者 | 人在 CLI、IDE、App 或网页中交互      | 脚本、CI、服务和可计量的自动化           |
| 费用入口  | ChatGPT 套餐及可能存在的额外 credits | OpenAI Platform 按 API 用量计费 |
| 常见限制  | 时间窗口、任务复杂度、模型和产品策略共同决定     | 账户余额、预算、速率限制、模型权限共同决定      |
| 成本可见性 | 更像“套餐内额度还剩多少”              | 更像“本次调用产生多少 token 和费用”     |
| 自动化适配 | 不应把个人交互登录当作无人值守凭据          | 适合程序化调用，但必须管理密钥和预算         |
| 功能范围  | 可能包含仅对 ChatGPT 工作区开放的能力    | 以 API 文档和项目权限为准            |
| 管理主体  | 个人套餐或 ChatGPT 工作区管理员       | Platform 组织、项目、账单管理员       |

一个实用但不是绝对的默认判断是：

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

## 第一步：确认当前登录方式

不要根据“我订了 ChatGPT”或“电脑里有 key”来猜 Codex 正在走哪套账。
应当查看当前会话和本机配置。

在 Codex CLI 中先检查：

```text theme={null}
/status
```

再查看当前版本支持的登录与退出命令：

```bash theme={null}
codex --version
codex login --help
codex logout --help
```

不同版本的状态页字段可能不同。
你要确认的是以下事实，而不是寻找某个固定界面：

* 当前是 ChatGPT 账号授权，还是 API 凭据；
* 当前模型是什么；
* 当前会话的上下文占用是否异常；
* 是否启用了会增加消耗的推理强度或加速选项；
* 当前工作区或组织是否施加了额外限制。

如果无法确认费用会落到哪里，先停止长任务。
退出后用明确的身份重新登录，比在错误账本上继续运行更容易控制成本。

## ChatGPT 订阅：购买的是使用权

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

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

同样发送一条消息，实际工作量可能差很多：

* 只解释十行代码；
* 扫描整个仓库；
* 读取长会话历史；
* 调用多个工具并分析输出；
* 进行高强度推理；
* 在云端运行持续较久的任务。

因此，官方页面即使显示消息范围，也只能作为容量提示。
它不能承诺每个用户、每个任务都能发送相同条数。

订阅额度常受这些因素共同影响：

| 因素    | 为什么影响额度                |
| ----- | ---------------------- |
| 模型档位  | 更强模型通常需要更多计算资源         |
| 推理强度  | 更深推理会增加延迟与计算消耗         |
| 上下文大小 | 文件、历史消息、规则和工具说明都会进入上下文 |
| 任务位置  | 本地交互与云端任务可能采用不同计量口径    |
| 时间窗口  | 产品可能按滚动窗口及更长周期管理公平使用   |
| 工作区政策 | 团队或企业工作区可有独立治理规则       |
| 产品活动  | 临时扩容、预览权益和促销不能视为长期承诺   |

### 套餐怎么选

不要先问“哪一档最强”，先连续记录一到两周：

* 每周实际使用几天；
* 哪类任务最常触达限制；
* 限制发生时是否阻塞关键工作；
* 额外 credits 的使用是否偶发；
* 团队是否需要管理、审计、SSO 或数据治理能力。

据此选择：

| 使用形态          | 选择方向                     |
| ------------- | ------------------------ |
| 偶尔处理明确的小任务    | 从当前可用的基础档开始，不为理论峰值升级     |
| 每天交互式开发，但很少触限 | 保持现档，优先优化上下文和任务拆分        |
| 经常在关键时段触限     | 比较升级后的稳定容量与额外 credits 成本 |
| 多人共享项目与治理要求   | 评估团队工作区，而不是共享个人账号        |
| 主要需求是 CI 与批处理 | 单独评估 API，不要仅提高个人订阅档位     |

升级前应验证“限制是不是套餐容量造成的”。
模型权限、地区、工作区策略、版本过旧或服务异常，都可能看起来像额度不足。

### 额度用完时怎么判断

先记录错误原文和发生时间，再区分：

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`：重试、失败、返工和峰值的冗余系数。

估算式：

```text theme={null}
月度基准成本 = N × [(I - C) × Pi + C × Pc + O × Po]
月度预算上限 = 月度基准成本 × R
```

实际计算时，把官网计价单位换算到同一单位。
不要在团队文档里抄一组长期不更新的价格。
应保存核验日期、模型页链接和计算表使用的费率快照。

### 预算分三级

| 层级  | 作用     | 示例动作                 |
| --- | ------ | -------------------- |
| 观察线 | 发现趋势偏离 | 通知负责人，检查模型与 token 变化 |
| 预警线 | 要求人工判断 | 暂停非关键批处理，缩小并发        |
| 停止线 | 防止继续扩大 | 应用侧拒绝新任务或切换到审批队列     |

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

## 额度口径：不要混为一谈

| 指标       | 回答的问题             | 常见误解                 |
| -------- | ----------------- | -------------------- |
| 上下文窗口    | 单次模型请求最多能处理多少信息   | 等同于账号剩余额度            |
| 当前上下文占用  | 这个会话已经装入多少信息      | 等同于本次新增 token        |
| 输入 token | 请求送入模型的信息量        | 只计算用户手写文字            |
| 输出 token | 模型生成的信息量          | 只计算屏幕可见回答            |
| 请求速率限制   | 单位时间可发多少请求或 token | 等同于余额不足              |
| 订阅使用限制   | 产品内某时段还能用多少       | 等同于 API 余额           |
| API 预算   | 计划允许花多少钱          | 一定能自动阻止超支            |
| credits  | 产品定义的额外使用单位       | 与现金或 API token 固定一比一 |

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

## 模型选择：先选能力档位

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

### 三类常见档位

| 档位      | 优先目标            | 适合任务               | 主要代价       |
| ------- | --------------- | ------------------ | ---------- |
| 旗舰或高能力档 | 正确性、复杂推理、跨文件一致性 | 架构、复杂调试、大型重构、安全审查  | 延迟和消耗通常较高  |
| 均衡档     | 质量、速度、成本平衡      | 日常功能开发、测试、常规审查     | 极难任务可能需要升级 |
| 轻量或低延迟档 | 快速、低成本、高吞吐      | 格式整理、明确的小改动、分类与批处理 | 更容易漏掉隐含约束  |

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

### 先做任务分级

选择模型前，先评估五个维度：

1. **范围**：单文件、单模块，还是跨系统；
2. **歧义**：验收条件是否明确；
3. **代价**：做错后是否会影响数据、安全或生产；
4. **可验证性**：是否有测试、类型检查或基准；
5. **时效性**：是交互式秒回，还是可以后台运行。

推荐匹配如下：

| 任务         | 初始档位    | 升档条件            |
| ---------- | ------- | --------------- |
| 拼写、格式、机械改名 | 轻量档     | 涉及公共 API 或大量引用  |
| 明确的小型 Bug  | 轻量或均衡档  | 根因不明、存在并发或状态问题  |
| 常规功能与测试    | 均衡档     | 跨模块契约复杂或验证不足    |
| 陌生仓库探索     | 均衡档     | 需要形成架构决策或安全判断   |
| 复杂重构       | 高能力档    | 默认就应高质量推理并分阶段验证 |
| 权限、支付、数据迁移 | 高能力档    | 仍需人工审查，不能只靠模型档位 |
| 批量独立小任务    | 轻量档     | 错误开始呈系统性时暂停并复盘  |
| PR 审查      | 均衡或高能力档 | 变更面大、风险高、测试缺失   |

逐级升级比一次追求“完美模型”更容易控制成本：

```text theme={null}
明确小任务 → 用较轻档位尝试 → 运行验证
验证失败或分析明显不足 → 提高推理强度
仍无法解决或风险较高 → 切换高能力模型并缩小问题范围
```

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

推理强度控制模型在回答或行动前投入多少计算。
可选名称、默认值和支持范围随模型变化，应以 `/model` 选择器和官方模型页为准。

| 相对强度  | 适合场景              | 不适合场景        |
| ----- | ----------------- | ------------ |
| 最低或关闭 | 完全明确的机械操作         | 需要判断边界或根因    |
| 低     | 小改动、快速反馈、简单检索     | 复杂设计与疑难调试    |
| 中     | 大多数日常开发任务         | 极高风险且缺少验证的任务 |
| 高     | 跨模块重构、复杂 Bug、严谨审查 | 高频的小修小补      |
| 最高    | 少数特别困难、值得等待的任务    | 作为所有任务的长期默认值 |

调节顺序建议：

* 结果正确但等待太久：先降低推理强度；
* 结果表面可用但遗漏边界：先提高一档并补充验收标准；
* 模型反复误解领域或跨文件关系：再换高能力档；
* 任务本身含糊：先澄清需求，不能靠最高强度替代需求定义。

推理强度越高不代表一定更正确。
没有测试、错误上下文和模糊目标仍会导致高成本返工。

## 服务层级与快速模式

部分入口可能提供快速模式或不同服务层级。
它们通常改变请求调度优先级和响应速度，而不是直接提高模型的推理质量。

| 旋钮   | 主要改变         | 不保证改变    |
| ---- | ------------ | -------- |
| 模型档位 | 能力、知识与任务适应性  | 一定更快     |
| 推理强度 | 思考深度、延迟和计算消耗 | 模型本身能力上限 |
| 服务层级 | 排队优先级、吞吐或延迟  | 答案一定更准确  |

适合使用更快服务层级的情况：

* 开发者正在等待关键交互结果；
* 线上事故排查中，每分钟都有明确价值；
* 短时演示或发布窗口需要可预测延迟；
* 已确认额外 credits 或 API 费用在预算内。

不适合的情况：

* 夜间批处理；
* 没有截止时间的仓库索引；
* 任务仍会因需求不清反复返工；
* 团队尚未建立成本归属和告警。

不同登录方式可用的服务层级可能不同。
配置键、功能开关和倍率也可能变化。
先查看当前版本帮助、`/status`、`/model` 与官方速度文档，不要照搬旧教程中的倍率。

## 一套日常决策流程

### 1. 确认账本

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

### 2. 给任务分级

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

### 3. 控制上下文

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

### 4. 写清完成条件

```text theme={null}
目标：要改变什么行为。
上下文：相关文件、复现步骤和错误信息。
约束：不能修改什么，必须遵守什么。
验收：运行哪些测试，看到什么结果才算完成。
```

### 5. 先小样本后扩量

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

### 6. 完成后记录

* 登录方式；
* 模型档位与推理强度；
* 是否开启快速服务层级；
* 任务耗时、成功率和返工次数；
* API 用量或订阅额度变化；
* 验证结果。

这些数据比网上任何“一个套餐能发多少条”的经验更适合你的团队。

## 用量异常诊断

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

按顺序检查：

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

### 症状二：API 费用突然上升

先在 Platform 用量页按项目、模型和日期切分，再检查：

* 是否有新部署或定时任务；
* 请求量、输入 token、输出 token 哪一项增长；
* 是否切换了费率更高的模型；
* 缓存命中是否下降；
* 是否发生重试风暴；
* 是否把大型日志或整个仓库重复送入上下文；
* 是否有泄露的 key 从陌生来源发起请求；
* 并发和单任务最大输出是否缺少限制。

发现无法解释的调用时，先撤销或轮换受影响凭据，再调查来源。
不要为了保留现场而让可疑 key 继续有效。

### 症状三：提示“受限”，但还有预算

预算余额正常不代表请求一定能执行。
继续检查：

* 模型是否对该账号或项目开放；
* 组织验证或付款状态是否满足要求；
* 请求速率或 token 速率是否触顶；
* 工作区管理员是否限制了模型；
* 当前地区、入口或客户端版本是否支持该功能；
* OpenAI 状态页是否报告服务事件。

### 症状四：任务越来越慢

| 观察             | 可能原因           | 优先动作           |
| -------------- | -------------- | -------------- |
| 首 token 等待明显增加 | 服务拥塞、服务层级、模型负载 | 查状态页，比较其他档位或时段 |
| 每轮都读大量文件       | 范围不清、会话失控      | 指定文件，拆任务，新开会话  |
| 回答很长但不落地       | 验收标准缺失         | 要求执行、测试并简洁报告   |
| 高强度用于简单任务      | 配置不匹配          | 降低推理强度         |
| 多代理互相等待或冲突     | 分工和文件边界不清      | 减少并发，隔离工作区     |

## 动态信息核验清单

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

### 官方来源

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/`

### 本机事实

```bash theme={null}
codex --version
codex --help
codex login --help
```

在交互会话中检查：

```text theme={null}
/status
/model
```

斜杠命令也可能随版本变化。
如果命令不存在，以当前 CLI 帮助和交互命令列表为准。

## 安全边界

### 不要暴露 API key

API key 不应出现在：

* 提示词和聊天记录；
* Git 仓库；
* `AGENTS.md`；
* Issue、PR、日志和截图；
* 前端代码或移动应用包；
* 可被普通用户读取的配置文件；
* 命令历史和共享终端录屏。

优先使用环境变量、操作系统凭据库或组织批准的 secrets manager。
示例只能使用占位符：

```text theme={null}
OPENAI_API_KEY=<从安全凭据存储注入>
```

不要把真实 key 写进示例命令。

### 给自动化设置停止条件

自动化任务至少应具备：

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

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

模型档位再高，也不能独立批准：

* 生产发布；
* 数据删除或不可逆迁移；
* 权限提升；
* 密钥导出；
* 财务交易；
* 对外发送敏感信息；
* 跳过测试或安全检查。

高风险操作需要可追溯的人类批准、最小权限和回滚方案。

## 最终选择速查

| 问题          | 默认答案                      |
| ----------- | ------------------------- |
| 我是个人交互式开发   | 先用 ChatGPT 账号登录，观察实际额度    |
| 我要在 CI 中运行  | 使用独立 API 项目和服务凭据          |
| 我不知道套餐是否够   | 记录一到两周真实使用，再决定升级          |
| 小任务该用什么     | 当前可用的轻量或均衡档，配低到中等推理       |
| 复杂任务该用什么    | 高能力档，配中到高推理，并拆分验证         |
| 想更快怎么办      | 先减少返工和上下文，再评估快速服务层级       |
| API 成本怎么估   | 用真实样本 token 外推，并加入重试与峰值冗余 |
| 突然超支怎么办     | 按项目与模型定位；可疑调用先撤销凭据        |
| 网上看到具体价格和条数 | 回到官方页面核验日期、入口和账号范围        |

## 验收清单

完成账号和模型配置后，逐项确认：

* [ ] 已明确当前是 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`。