AI Code With · Codex 成本与用量排查指南
“Codex 一个月到底多少钱？”这个问题看起来很简单，但如果不先说明你是怎么用 Codex 的，几乎不可能给出一个靠谱答案。
有人用 ChatGPT 账号直接登录 Codex，先消耗计划内额度；有人达到限额后继续购买 ChatGPT Credits；还有人用 OpenAI Platform API Key，或者把 Codex 接到 AI Code With 这类第三方 Provider，完全按 API 调用量计费。
这几条路线最后都可能表现成“我在用 Codex”，但账单口径不是一回事。最容易踩的坑，就是把 ChatGPT Credits、API 费用和第三方平台余额混在一起，然后拿一张余额截图去猜“这次任务为什么贵”。
余额告诉你“钱少了多少”；真实用量记录才告诉你“钱花在了哪里”。
1. 先别算钱：先确认你走的是哪条计费路线
现在使用 Codex，至少要先区分三种常见路径。它们不是三种付款按钮，而是三套不同的用量逻辑。
| 使用方式 | 费用从哪里扣 | 适合谁 | 最容易混淆的点 |
| ChatGPT 计划内 Codex | 先使用当前 ChatGPT 计划包含的 Codex / agentic usage | 已经有 ChatGPT 计划、主要直接用 Codex 的用户 | 不要拿 API Token 单价直接解释计划内限额 |
| ChatGPT Credits | 计划内额度用完后，符合条件的账户可继续消耗购买的 Credits | 偶尔超出计划限额，但仍想继续在 ChatGPT / Codex 体系内使用 | Credits 不是 OpenAI Platform API 余额 |
| API Key / 自定义 Provider | 按实际 API 调用计费；第三方 Provider 则按对应平台规则扣费 | 自动化、多模型、自定义 Provider、希望按调用拆账的用户 | 这条链与 ChatGPT 计划内 Credits 是两套账 |
路线 A：ChatGPT 计划内使用 Codex
如果你是用 ChatGPT 账号登录 Codex，最先看的不是每百万 Token 多少钱，而是当前计划的可用额度、重置时间和 Usage Dashboard。Codex 现在会和部分 agentic 功能共享使用额度和 Credits 池，任务复杂度、模型、上下文、运行位置和工具调用都会影响消耗速度。
所以两个人同样说“我一天用了 20 次 Codex”，实际消耗可能完全不同。一个只是改几行脚本，另一个让 Codex连续读大型仓库、跑测试、调用工具，根本不是同一个量级。
路线 B：ChatGPT Credits
Credits 可以理解成计划内额度之外的按需补充。符合条件的账户在计划内使用量耗尽后，可以购买 Credits 继续使用支持的功能。
这里最重要的一点是：ChatGPT Credits 不是 OpenAI Platform API credit。你在 Codex 里买了 Credits，不代表自己的 API Key 账户里自动多了一笔 API 余额。
路线 C：API Key 或第三方 Provider
如果 Codex 通过 API Key 或自定义 Provider 发请求，成本就要回到“实际调用了什么模型、用了多少输入/缓存/输出 Token”来计算。
如果你接的是 AI Code With，那么这次请求是否经过 AI Code With，要以 Provider 配置和后台真实调用记录为准；没有经过它的官方 Codex 调用，也不会出现在 AI Code With 的 Usage Records 里。
2. API 计费真正要算什么？别拿文章字数直接猜 Token
对于 API Key 或第三方 Provider 场景，最通用的成本公式其实不复杂：
单次任务成本
= 输入 Token × 输入单价
+ 缓存输入 Token × 缓存单价
+ 输出 Token × 输出单价
+ 其他明确计费项
但难点不在公式，而在于：你到底给模型喂了多少上下文，又让它输出了多少内容。
一篇 2000 字的需求，不等于只会产生 2000 字对应的 Token。Codex 可能还读取项目规则、相关源码、Git diff、日志、工具输出和前面的会话历史。真正的输入量，往往比你手动输入的 Prompt 大得多。
3. 为什么同一个任务，今天可能比昨天贵？
原因一：输入上下文突然变大
这是最常见的原因之一。比如你昨天只让 Codex 看 src/payment 下三个文件，今天却让它“帮我全面检查整个项目”，模型需要读取和维持的上下文很可能直接翻倍。
长会话也会产生类似问题。前面几十轮都没清理，后来只是让它改一个变量名，实际上它仍可能带着大量历史上下文继续工作。
原因二：输出要求变重
“告诉我问题在哪”和“把所有问题修好、补测试、解释原因、生成变更报告”，看起来只差一句话，但输出 Token 和工具调用规模可能完全不同。
如果你要求它每一步都给长解释、输出多个方案、重复总结，成本上升并不奇怪。
原因三：模型换了
同一个任务切到更强或价格更高的模型，单价就可能变化。反过来，如果只是机械搜索、改变量名、整理日志，也没必要一直让最高档模型承担。
真正省钱的不是“永远用最便宜模型”，而是让任务难度和模型能力匹配。
原因四：缓存命中率发生变化
重复上下文如果能命中缓存，通常会比完全重新计算更省。但缓存字段只能告诉你复用情况，不能自动解释为什么没有命中。你还是要回到上下文、会话和任务结构去看。
原因五：重试、循环或 Agent 重复调用
这是余额页最难告诉你的问题。一个任务看起来只执行了一次，Agent 背后可能重试了多次，或者某个脚本 / 自动化重复触发。
如果费用突然异常，不能只看“最后一次成功响应”，还要看同一时间段是不是出现了多条相似调用。
4. 真正排查一次 Codex 调用，建议按这 5 层看
如果你走的是 AI Code With 这类第三方 API 路线，Usage Records 的价值就在这里：它能把“余额少了”拆成一条条可以核对的请求。原稿已经确认当前记录里会展示时间、服务、模型、渠道、输入输出 Token、缓存、TTFB、总时长、Key 和费用等字段。
第 1 层：先看时间
先故意跑一个很小的 Codex 请求，记住开始时间。然后只看这一两分钟内的记录。
如果这个时间段完全没有请求，先别讨论价格。优先检查 Provider、Endpoint、网络、API Key 和当前 Codex 进程是否真的读到了正确配置。
第 2 层：再看 Key 和模型
如果你给不同项目或工具使用了可识别的 Key，例如 codex-seo、codex-dev，排查会快很多。
找到这条请求后，先确认模型是不是你以为的那个。模型不对，可能是默认 Provider 覆盖、Model ID 配错、旧会话仍在生效，或者当前配置根本没有被加载。
第 3 层：拆输入、缓存和输出 Token
输入特别高，先想是不是上下文太大；输出特别高，先看是不是要求了过多生成；缓存变化，则用来判断重复上下文有没有被复用。
这里不要把“Token 高”直接理解成“模型浪费”。有些复杂任务本来就需要读很多文件，关键是这些输入是否真的对任务有用。
第 4 层：看时长和响应表现
TTFB 可以帮助你观察等待首个响应花了多久，总时长可以反映整次请求跑了多长时间。它们是排查线索，不是根因诊断器。
例如首包很慢，可能与网络、上游排队、模型处理有关；总时长很长，也可能只是任务本身输出很多。不能只看一个数字就下结论。
第 5 层：最后再看渠道和最终费用
如果同一模型支持不同渠道，实际费用、响应表现可能存在差异。成本突然变化时，应该一起看模型、渠道、Token、缓存和调用次数，而不是只看到一笔高费用就认定“平台涨价了”。
[真实截图待补：AI Code With Usage Records 筛选器 + 一条脱敏 Codex 请求，重点展示时间、Key、模型、Token、缓存、渠道和费用字段]
5. 一个现实案例：昨天一次任务 1 元左右，今天为什么突然变贵？
假设你每天都让 Codex 帮你检查一个项目。昨天跑完感觉费用很正常，今天类似任务却明显贵了。不要第一反应去换 Key 或怀疑价格变了。
更有效的排查过程可以是：
| 检查顺序 | 你看到的现象 | 更可能的解释 |
| 1. 时间 | 今天同一时间出现 3 条相似请求 | 可能发生了重试、重复触发或多 Agent 调用 |
| 2. Key / 模型 | 模型从常规模型变成更高档模型 | 默认配置或会话模型发生变化 |
| 3. 输入 Token | 输入从 8 万涨到 30 万 | 读取范围扩大、历史会话累积或重复附带文件 |
| 4. 输出 Token | 输出从 5 千涨到 2 万 | 任务从“分析”变成“分析 + 修改 + 测试 + 报告” |
| 5. 缓存 | 缓存复用明显降低 | 重复上下文没有被复用，或上下文结构变化 |
| 6. 渠道 / 费用 | 其他项基本相同但费用变化 | 再核对渠道、当天模型价格与平台记录 |
这套思路最大的价值，是把“感觉今天贵了”变成一个可以逐层验证的问题。
先证明是哪一个变量变了，再决定要不要优化。
6. AI Code With 在这件事里的价值，不只是“看余额”
如果你只是用官方 ChatGPT 计划里的 Codex，而且现有额度和模型已经完全满足需求，就没必要为了做成本分析强行多接一个第三方 Provider。
但如果你已经在 Codex 里切 Kimi、DeepSeek、GLM、通义千问等不同模型，或者同时维护多个 AI 编程工具，那么统一的 Key、模型入口和调用记录就开始有实际价值。
AI Code With 当前公开页面仍强调 30+ 模型统一接入、按量计费和统一可观测性。对 Codex 用户来说，最有用的不是一个“便宜”的宣传词，而是你能把调用拆到 Key、模型、Token、渠道和费用层面，知道到底是谁在花钱。
这也意味着更合理的使用方式不是一个万能 Key 走天下。长期项目可以分别创建可识别的 Key，再用 Usage Records 做归因；偶尔测试则可以用低额度测试 Key，用完停用，没必要把简单工作流设计得过度复杂。
7. 真想让 Codex 成本降下来，优先做这 7 件事
1. 把任务边界说清楚
“帮我看看项目有什么问题”会让搜索范围非常大。改成“只检查 src/payment，先分析三个最可能原因，不改代码”，通常更可控。
2. 先分析，再让它修改
复杂任务先让 Codex 给出定位和计划，确认方向后再改指定文件，可以减少错误方向带来的重复生成和返工。
3. 不要在超长旧会话里硬续小任务
如果前面的上下文已经很重，新任务和旧任务关系又不大，重新开会话并给出必要背景，往往比继续背着全部历史更干净。
4. 长期规则放进项目规则文件，但别写成百科
稳定的目录约束、测试方式、禁止修改范围可以让 Codex 自动读取；但项目规则同样要控制长度，只保留长期有效内容。
5. 简单任务不一定要最强模型
搜索文件、整理日志、机械改名、格式化等执行型任务，可以优先考虑成本更低的模型；复杂架构、疑难 Bug 再升级。
6. 关注重复调用，而不是只优化单次 Token
一次请求省 10% 没什么意义，如果自动化意外重复跑了 5 次，真正的大头是调用次数。
7. 优化之前先看真实记录
没有真实 usage 就谈“优化”，很容易优化错方向。先找出输入、输出、缓存、模型还是调用次数在变，再动手。
8. 那到底选 ChatGPT 计划、Credits，还是 API / AI Code With？
没有哪条路线对所有人都更划算。更合理的判断方式是看你的工作流。
| 你的情况 | 优先考虑 |
| 已经有合适的 ChatGPT 计划，主要只用 Codex，很少切其他模型 | 先把现有 ChatGPT 计划用好，最省配置成本 |
| 偶尔达到 Codex 限额，但仍想继续用同一套 ChatGPT / Codex 体验 | 看账户是否支持购买 Credits |
| 需要脚本化、自动化、明确按 Token 预算 | API Key 路线更容易按量核算 |
| 长期在 Codex、Kimi、DeepSeek、GLM 等多个模型之间切换 | 统一 API / 多模型管理平台的价值更明显 |
| 需要按项目 / 工具拆 Key 和调用记录 | AI Code With 这类带 Usage Records 的第三方 Provider 更方便归因 |
| 只是偶尔测试一个第三方模型 | 低额度测试 Key 足够，不必先搭复杂多 Key 体系 |
9. 如果你决定走 API / AI Code With，建议这样验证真实成本
1. 先确认当前 Codex 真的在走 API / 自定义 Provider，而不是 ChatGPT 官方登录。
2. 为 Codex 创建一个用途明确的 Key，长期项目尽量不要和其他工具混用。
3. 按当天最新接入文档配置 Provider、Endpoint 和 Model ID。
4. 先发一个很小、无副作用的请求。
5. 记下请求时间。
6. 在 Usage Records 找到同一时间的真实调用。
7. 确认 Key、模型和渠道符合预期。
8. 记录输入、缓存、输出 Token 和最终费用。
9. 再运行一个真实工作任务，用同样方法对比。
10. 至少观察几类任务后，再决定哪种模型和预算策略适合自己。
10. 关于 Codex 费用，最容易出现的 6 个误区
| 误区 | 为什么不准确 |
| “Codex 一个月就是固定 X 元” | 使用路线、计划、模型、任务复杂度和调用量都不同 |
| “Credits 就是 API 余额” | ChatGPT Credits 与 OpenAI Platform API 计费是不同体系 |
| “余额掉得快就是模型涨价” | 可能是上下文、输出、缓存、渠道或重复调用变了 |
| “/status 显示模型对，就说明费用一定走对” | 模型显示不等于请求一定经过预期 Provider；要看真实调用记录 |
| “输入 Prompt 很短，所以输入 Token 一定少” | Codex 还可能带入代码、工具输出、规则和会话历史 |
| “最便宜的模型一定最省钱” | 如果能力不够导致反复重试和返工，整体成本反而可能更高 |
11. 最后：看余额是看结果，看 usage 才是在找原因
Codex 的成本管理，真正难的不是会不会套公式，而是能不能把一次任务拆成可验证的变量。
你至少要知道：自己走哪条计费路线、实际调用了哪个模型、输入和输出用了多少、有没有缓存复用、请求是不是重复跑了，以及最终费用落在哪个账户或 Provider。
如果走 ChatGPT 计划，就看官方 Usage Dashboard 和 Credits；如果走 OpenAI API，就看 API usage 和当日价格；如果走 AI Code With，就用后台的真实调用记录去核对 Key、模型、Token、渠道和费用。
不要用一种账单解释另一种使用方式。先找对账本，再谈省钱。
当你能回答“哪一次请求、哪个 Key、哪个模型、多少 Token、为什么变贵”，成本优化才真正从感觉变成工程。
相关阅读
• Codex API Key 怎么配置：先分清 Key、Base URL、Provider 和模型
• Kimi K3 怎么接入 Codex：完整配置、验证与费用控制
• Codex auth.json 是什么：位置、风险与安全排错
• Codex App 接第三方模型：Provider、Base URL 与 401 排错
• Codex 多工具怎么配才不串线
资料来源与核对说明
本文在《Codex 一次调用到底花在哪，别只盯账户余额》和《Codex 怎么收费：ChatGPT 套餐、Credits 与 API Key 别混在一起》两篇原稿基础上合并重写。ChatGPT 计划、Credits、模型费率和第三方平台能力可能更新，因此文章避免写死会快速过期的固定额度或单次价格，正式判断时应以当天 Usage / Pricing 页面为准。
OpenAI - Using Codex with your ChatGPT plan：https://help.openai.com/en/articles/11369540
OpenAI - Using Credits for Flexible Usage in ChatGPT：https://help.openai.com/en/articles/12642688
OpenAI - Codex / ChatGPT credit rate card：https://help.openai.com/en/articles/11481834
AI Code With 官网：https://aicodewith.ai/zh
AI Code With Codex 文档：https://docs.aicodewith.ai/zh/docs/codex-cli
AI Code With Blog - Codex 配置与 Usage Records：https://aicodewith.ai/zh/blog/codex-ai-code-setup
