Codex 降本实战：token 计费下怎么省而不变笨

同样的活，Codex 额度比预期快好几倍。一个长会话跑一整天反复重读，默认开了 multi_agent，AGENTS.md 写了几千行，琐碎任务也用最贵模型。想知道钱花在哪、怎么系统性降下来，这里拆清楚。

---

一、钱花在哪：计费机制拆解

Codex 的成本来自四个地方：上下文重复读、长会话、多 agent 并发、高推理模型。核心机制是 token/credit 计费：每 100 万 token（输入、缓存输入、输出）消耗对应的 credit，不同类型 token 费率不同。cached input 比 input 便宜——这是 prompt 缓存能省钱的根本。具体费率以官方 rate card为准，会随时调整。

Codex 用滚动窗口限额（如 5 小时窗口）而非单纯月度限额，窗口内额度用完会触发限速。Plus 和 Pro 计划有 rate-limit reset banking，窗口结束后额度恢复。API key 则独立按 token 计费，不受 Codex 计划额度影响。

想知道用量，用 /status 查看当前会话状态，或在 Codex 设置里进入 usage dashboard 看团队整体用量。

上下文重复读是最容易忽略的成本源。每次执行任务，Codex 都要重新读 AGENTS.md、项目文档、历史对话。如果 AGENTS.md 写了几千行，项目文档堆了一堆，一个线程跑几十轮对话，每轮读的内容加起来就是几万 token。长会话的问题是累积：线程越长，读的内容越多，单次成本不高，但反复执行后累积吓人。多 agent 并发时，每个活跃 agent 都在独立消耗额度，并发数 × 单次成本 = 总成本。高推理模型（GPT-5.5/5.4）比轻量模型（GPT-5.4 mini）贵，推理层级（Low/Medium/High/Extra High）也会影响费率。

降本手段的效果和代价可以对照看：

降本手段	预期效果	代价
换便宜模型	额度消耗减少 30-60%	推理能力下降，复杂任务效果变差
及时清零上下文	额度消耗减少 20-40%	需频繁开新线程，历史上下文丢失
AGENTS.md 精简	额度消耗减少 10-20%	需拆分文档，维护成本上升
Prompt 缓存利用	额度消耗减少 15-30%	稳定上下文，频繁改动失效
减少 multi_agent	额度消耗减少 20-50%	并发能力下降，任务执行变慢

降本不是一味省钱。换便宜模型能省 30-60%，但复杂任务效果会变差；及时清零能省 20-40%，但需要频繁开新线程；AGENTS.md 精简能省 10-20%，但拆分文档会增加维护成本。根据任务实际需求选择手段，不要为省一点钱牺牲核心功能。

监控用量步骤

用 /status 在命令行查看当前会话状态，包括上下文大小和已用额度。在 Codex 设置里进入 usage dashboard，看团队整体用量和额度窗口状态。定期记录额度消耗趋势，对比降本手段的实际效果。

---

二、模型分层省钱法

模型选择直接影响成本。Codex 提供 Low、Medium、High、Extra High 四个推理层级。Low 推理快、范围清晰，适合简单任务；Medium/High 用于复杂或调试类任务；Extra High 用于长链 agentic 任务。模型方面，GPT-5.5 和 GPT-5.4 是前沿模型，GPT-5.4 mini 是轻量版本（5.3-Codex 和 5.2 已弃用）。

基本原则很简单：思考类任务用前沿模型，琐碎任务用 mini。按任务难度选推理层级，不要一律用最贵配置。一律用最贵配置会导致额度燃烧快，简单任务浪费推理能力，复杂任务效果不一定更好。

推理层级与模型搭配：

任务类型	推荐推理层级	典型场景
简单查询、格式转换	Low	文档格式化、简单 bug 修复
代码重构、功能开发	Medium	单文件重构、API 集成
调试、复杂逻辑	High	跨文件 bug 定位、性能调优
长 agentic 任务	Extra High	多步骤自动化、探索性开发

Low + mini 用于简单查询和格式转换；Medium + mini 或 Medium + GPT-5.4 用于代码重构和功能开发；High + GPT-5.4/5.5 用于调试和复杂逻辑；Extra High + GPT-5.5 用于长链 agentic 任务。根据任务实际难度选配置，不要为了”保险”一律用最贵。

FAQ：怎么选模型省钱

思考类任务用前沿模型（GPT-5.5/5.4），琐碎任务用 mini（GPT-5.4 mini）。按任务难度选推理层级，不要一律用最贵配置。简单查询用 Low，复杂调试用 High，长链 agentic 用 Extra High。

---

三、会话管理：及时清零上下文

长会话跑一整天，上下文反复重读，token 消耗很快。Codex 每次执行都要重新读上下文，线程越长、读的内容越多，成本累积起来吓人。解决办法是及时清零上下文：遵循一个线程一个任务的原则，不要一个线程跑整个项目。

上下文膨胀的具体表现：AGENTS.md 有几千行，项目文档有几十个，历史对话有几十轮，每轮执行都要把这些全部重读一遍。单次读可能几千 token，但一天跑几十次，累积就是几万甚至十几万 token。上下文膨胀还会影响效果：线程越长，Codex 越容易混淆重点，执行结果变差。

会话管理命令清单：

命令	用途	使用时机
/compact	压缩早期上下文	线程变长时（Codex 也会自动压缩）
/clear	清空当前线程	任务完成后
/resume	恢复之前线程	需继续之前任务时
/fork	分叉线程	需要分支探索时
/agent	切并行 agent	需要 multi_agent 时
/status	查看会话状态	监控用量时

会话管理最佳实践

任务完成后及时 /clear 或开新线程，避免上下文累积。长会话中途用 /compact 压缩早期内容，减少上下文占用。一个线程一个任务，历史上下文用 /resume 恢复，不要混用。

一个线程一个任务的核心原则：不要在一个线程里混杂多个任务，比如既改 bug 又写新功能，既重构代码又部署服务。混用会导致上下文混乱，每次执行都要读不相关的内容，浪费 token。任务完成后立即 /clear，需要继续之前任务时用 /resume 恢复。分支探索用 /fork，但要注意分叉后两个线程独立消耗额度。

FAQ：长会话怎么管

任务完成后及时 /clear 或开新线程，中途用 /compact 压缩。一个线程一个任务。

---

四、AGENTS.md 精简：32KiB 截断规避

AGENTS.md 写了几千行，不仅占上下文，还可能触发截断。project_doc_max_bytes 默认 32 KiB，合并后的 AGENTS.md 达到上限就停止添加或截断。截断意味着部分指令丢失，还会浪费上下文空间。

判断 AGENTS.md 大小的影响：

AGENTS.md 大小	影响	解决方案
< 16 KiB	无影响，上下文占用少	保持现状
16-32 KiB	中等占用，需监控	考虑拆分非核心内容
> 32 KiB	截断风险，部分指令丢失	必须拆分到嵌套目录

AGENTS.md 精简步骤

主 AGENTS.md 保持简洁（控制在 32 KiB 以内），只放核心指令和通用规则。超限时拆到嵌套目录（如 docs/.agents），用任务专属 md 文件补充特定指令。利用就近文件覆盖机制，让特定目录的 AGENTS.md 覆盖全局配置。

关于 AGENTS.md 写法的详细指南，可以参考「AGENTS.md 最佳实践」。

---

五、Prompt 缓存：让稳定上下文更便宜

cached input 比 input 便宜（具体费率见官方 rate card），这是 prompt 缓存能省钱的根本。缓存命中时，稳定上下文以 cached input 费率计费，比普通 input 省一笔。让 AGENTS.md 和项目文档保持稳定，不要频繁改动，这样它们能吃满 cached input。

缓存工作机制：Codex 会缓存稳定的上下文部分（如 AGENTS.md、项目文档），下次执行时这些部分以 cached input 费率计费。频繁改动会打断缓存命中，缓存失效后这部分重新以普通 input 费率计费。缓存命中率高时，单次执行成本能降低 15-30%。

稳定上下文的具体做法：AGENTS.md 保持简洁且稳定，核心指令写进去后不要频繁改；项目文档分清楚稳定部分和变动部分，稳定部分放固定目录，变动部分放临时目录；避免在线程里频繁改动 AGENTS.md 或项目文档，改动后缓存失效。

缓存利用手段的效果和代价：

缓存利用手段	预期效果	代价
AGENTS.md 稳定	cached input 命中率高	需提前规划指令，改动少
项目文档稳定	减少重复读 token	文档更新后缓存失效
避免频繁改动	缓存命中稳定	灵活性下降

FAQ：prompt 缓存怎么省

让 AGENTS.md、项目文档稳定，不频繁改动，让这些稳定部分吃满 cached input。cached input 比 input 便宜，具体费率见官方 rate card。

---

六、并发取舍：multi_agent 按需开

multi_agent 会增加成本。多 agent v2 并发按「活跃执行」计数——并发时每个活跃 agent 都在消耗额度，比单 agent 更费。multi_agent 目前是实验特性，建议默认克制、按需开启。

并发成本的计算方式：单 agent 执行一次任务消耗 X 额度；multi_agent 并发 3 个 agent，每个活跃 agent 各消耗 X 额度，总成本是 3X。并发数越多，成本越高。并发还会叠加其他成本：每个 agent 都要读上下文、执行推理、生成输出，这些都会累积。

对照并发模式的成本影响：

并发模式	成本影响	适用场景
单 agent	基准成本	单一任务、顺序执行
multi_agent（少量并发）	成本增加 20-30%	需要并行探索时
multi_agent（大量并发）	成本增加 50-100%	长链 agentic 任务

什么时候用 multi_agent：任务需要并行探索（如同时改多个文件）、多文件同步操作、长链 agentic 流程（如自动测试、部署、监控）。什么时候不用：单一任务（如改一个 bug）、顺序执行（如逐步重构）、预算紧张（如个人开发、额度有限）。关于多 agent 并发的详细成本分析，可以参考「Codex 多 Agent 实战」。

multi_agent 的取舍原则：默认单 agent，只在确实需要并发时开启。并发时控制 agent 数量，不要一下子开太多。监控并发后的额度消耗，发现消耗过快就减少并发数或改回单 agent。

FAQ：多 agent 并发是不是很费

是。多 agent v2 并发按活跃执行计数，每个活跃 agent 都消耗额度。默认克制，按需开。

---

七、Plan mode 取舍：简单任务别滥用

plan mode 会多一轮规划轮次，消耗额外的 token。复杂任务（多步骤、需确认）用 plan mode 能避免返工，但简单任务（单步骤、明确）滥用反而浪费 token。

判断任务复杂度与 plan mode 的关系：

任务复杂度	是否用 plan mode	成本影响
简单（单步骤、明确）	不用	基准成本
中等（多步骤、需确认）	用	多一轮规划 token，但避免返工
复杂（长链 agentic）	用	多一轮规划，但避免返工成本更高

原则：复杂任务用 plan mode，简单任务直接执行。这是保守建议，具体取舍看任务实际情况。

FAQ：plan mode 会不会更费

会多一轮规划 token。简单任务别滥用，复杂任务用 plan mode 避免返工。

---

八、监控与预算：用量可见才能省

用量可见才能知道降本效果。Codex 提供两个监控入口：usage dashboard 和 /status。usage dashboard 在 Codex 设置里，能看到团队整体用量和额度窗口状态；/status 在命令行，看当前会话的上下文大小和已用额度。

监控用量步骤

用 usage dashboard 查看团队用量（入口：Codex 设置 → Usage）。用 /status 查看当前会话状态（命令行）。估算团队预算：Plus 约 $20/月（基础额度）；Pro 约 $200/月（更高额度）；Business 约 $25-30/人/月；社区经验：团队真实月度约 $100-200/人（参考，以官方为准）。

以上金额为截至 2026-06 的区间，具体以官方定价为准。

FAQ：一个月大概多少钱

Plus 约 $20/月、Pro 约 $200/月。团队真实经验约 $100-200/人（社区口径，以官方为准）。具体见 usage dashboard。

---

九、FAQ

Q1：Codex 的钱到底花在哪？

上下文重复读、长会话、多 agent 并发、高推理模型。详见第一节。

Q2：怎么选模型省钱？

思考用前沿（GPT-5.5/5.4），琐碎用 mini（GPT-5.4 mini）。按任务难度选推理层级。详见第二节。

Q3：长会话怎么管？

任务完成后及时 /clear 或开新线程，中途用 /compact 压缩。一个线程一个任务。详见第三节。

Q4：prompt 缓存怎么省？

让 AGENTS.md、项目文档稳定，吃满 cached input。cached input 比 input 便宜。详见第五节。

Q5：AGENTS.md 太大有影响吗？

超 32 KiB 截断，且占上下文。主文件保持简洁，超限拆到嵌套目录。详见第四节。

Q6：多 agent 并发是不是很费？

是，按活跃执行计数。默认克制，按需开。详见第六节。

Q7：plan mode 会不会更费？

会多一轮规划 token。简单任务别滥用。详见第七节。

Q8：一个月大概多少钱？

Plus 约 $20/月、Pro 约 $200/月。团队真实经验约 $100-200/人（社区口径，以官方为准）。详见第八节。

---

十、下一步与延伸阅读

想了解审批沙盒、常见报错，看「Codex 避坑指南」。想深入了解多 agent 并发，看「Codex 多 Agent 实战」。