你准备在项目里接 Codex 系列模型写代码，翻到官方价目表却有点懵：按 token 还是按次？输入输出分开算吗？一个 agent 任务跑下来到底烧多少？这篇不讲单价数字，而是把「该看哪几项、怎么估算、什么时候口径会失效」理成一条可执行的路子，让你自己算出属于你项目的成本。
你打算在项目里接 Codex 系列模型写代码，翻到官方价目表却有点懵：按 token 还是按次？输入输出分开算吗？一个 agent 任务跑下来到底烧多少钱？这篇不报单价数字，而是把「该看哪几项、怎么估算、什么时候口径会失效」理成一条能执行的路子，让你自己算出属于你项目的成本。
先给你一个心理预期：Codex 这类偏代码的模型，成本结构和你平时调聊天模型不太一样，调用轮次多、上下文长、缓存影响大。所以决定花费的往往不是单价本身，而是你的使用方式。下面按「先分清账单口径 → 找出变量 → 自己估一遍 → 知道什么时候不适用」的顺序走。
先分清 Codex 的三种花钱方式
很多人一上来就拿套餐价去算 API 成本，结果怎么算都不对。因为订阅制额度和按量 API 是两套独立的账本，计费单位和结算周期都不一样，先在站内 /coding-plans 确认你走的是哪条路，再去谈单价。
- 订阅制：按月或按席位购买额度，用超了会限速或额外计费，看到的花费不等于真实 token 消耗；
- 按量 API：输入、输出、缓存读、缓存写可能是四个不同的单价，别当成一个数乘总量；
- 同一模型在不同渠道（官方直连、云托管平台、聚合中转）计价单位可能不一样，先对齐口径再横向比。
| 口径 | 计费单位 | 最容易被算错的地方 |
|---|---|---|
| 订阅套餐 | 按周期/席位额度 | 把额度消耗直接当成 API 花费 |
| 按量直连 | 按 token 分项 | 只算输入输出，漏掉缓存读写 |
| 第三方渠道 | 按 token 或按次 | 不同渠道单位不同，直接比价会错 |
确认口径之后，再去 /official-api/providers/openai 看该模型当下的分项单价，不要在脑子里记数字。价格会调整，记数字等于给自己埋坑。
决定花费高低的四个变量
同一个模型，两个团队跑出来的账单可能差好几倍，差距基本出在这四个变量上。理解它们，比背单价有用得多。
- 任务类型
- 一次性代码补全和整仓库重构消耗的 token 量差一个量级，别用同一个均价去套所有任务
- 上下文长度
- 贴进去的文件越多，输入侧越贵，长上下文任务成本会明显抬头，能裁剪就先裁剪
- 调用轮次
- agent 循环里一个任务可能调用模型十几次，按「一次对话」估会严重低估
- 缓存命中
- 重复的上下文如果没命中缓存，等于每次都在按全价付输入侧的钱
什么情况下这四个变量不适用？如果你的调用是短、少、无重复上下文的批处理脚本，那缓存和轮次的影响会小很多，重点看输出侧用量即可。
用自己的数据估一遍，五步走
不要拿网上的「大概多少钱一次」来拍板，那和你项目的任务分布没关系。正确做法是挑一个你自己的真实任务，从头到尾记一遍用量。下面五步按顺序做，做不完别跳步。
- 挑一个真实任务选一个上周实际跑过的任务，记录它一共调了几轮模型、每轮的输入和输出大概多长（字符数或 token 数都行，口径一致即可）。
- 分项加总用量把调用日志里的输入、输出、缓存读、缓存写分别加总，只看账单总额会分不清钱花在哪一项上。
- 换算成钱到 /tools/token-price-calculator 或 /tools/model-cost-calculator，用站内当下的单价把你统计的四项用量换算成金额。
- 放大到周期乘上你一天或一周跑这类任务的次数，得到月度区间。单次结果只能当参考，不能直接拍板预算。
- 拿账单对账跑一周后把实际账单和你的预估对一遍，差得多的那部分通常出在缓存命中率和失败重试上，回头调这两块。
估算与核对的具体动作
上一节讲的是流程，这一节把「怎么验证估得准」讲细一点。核心原则是：预估和真实账单必须定期对一次，否则你永远不知道自己的模型是不是早就变了。
- 对账时按任务类型分组，别把所有调用混在一起看总数，否则看不出是哪个任务在吃钱；
- 重点盯失败重试和空转轮次，这部分调用往往没有产出但照样计费；
- 缓存命中率单独拉一条曲线，掉下来的那几天成本通常同步上涨；
- 价格数字不要靠记忆，去 /price-watch 和 /official-api/providers/openai 核对当时的数字；
- 如果同时用了多个渠道，按渠道分开记账，否则优化方向会被平均数掩盖。
| 核对项 | 发现异常时的动作 |
|---|---|
| 单次任务轮次偏高 | 检查 prompt 是否让模型反复确认，简化指令 |
| 输入侧占比过高 | 裁剪上下文，把稳定不变的部分放到缓存前缀里 |
| 缓存命中率偏低 | 检查请求前缀是否每次都变，保持前缀稳定 |
| 重试次数偏多 | 看是不是限速或超时导致，调小并发或加重退避 |
什么情况下这套算法不管用
任何估算方法都有边界，下面几种情况你套上面的公式会失真，得换判断方式。
- 有免费额度或赠送额度在抵扣时，账单上看到的花费不等于真实消耗，要把抵扣部分单独记一笔；
- 订阅套餐内超额、限速重发、批量折扣这些规则会改变实际单价，先看清合同或后台规则再套公式；
- 模型换代或渠道调价后，旧结论直接失效，价格与可用渠道一律到 /price-watch 看当时的数字；
- 如果你的任务是低频、短上下文的批处理，轮次和缓存的影响很小，重点盯输出用量就行。
Codex 类模型的成本，八成花在你的调用方式上，两成才是单价。下一步先去确认你走的是订阅还是按量口径，再用自己的真实任务跑一遍五步估算。价格数字别记，到站内价格追踪页核对当时的数字，顺手把账单和预估对一次，你就有一套自己的成本模型了。→
常见问题
Codex 是按 token 收费还是按次收费？
要看你在哪条路上用。走订阅套餐时，你买的是额度或次数包，不直接按 token 扣钱；走按量 API 时才是按输入输出 token 计费。两套账不能混着比。具体某一档是哪种口径，去 /coding-plans 和 /official-api 对照，价格数字以页面当时显示的为准。
为什么我算出来的成本和账单差很多？
最常见的三个原因是：把多轮 agent 调用当成一次对话算了、没算长上下文带来的输入侧膨胀、以及重试或缓存未命中产生的重复计费。建议先把调用日志里输入、输出、缓存读、缓存写四项分别加总，再对照账单找差异，顺序别颠倒。
有没有办法先把花费压下来？
能做的通常是：缩小每次请求携带的上下文、把重复内容交给缓存、给 agent 循环设轮次上限、给账号配一个预算告警。这些是流程动作不是省钱承诺，效果取决于你的任务形态。设告警的闸门思路可以参考 /usage 看真实用量分布后再定阈值。
