gpt codex 5.3 价格

很多开发者第一次接编码模型，打开官方价目页看到一堆单价，却不知道自己一个月会花多少：输入输出怎么分开算、重复上下文会不会又算一遍、走中转站又是什么口径。这篇不讲绝对值，只给你一套查数、换算、设闸、核对的流程，让你在任何一次调价后都能自己把成本算明白。

很多开发者第一次接编码模型，打开官方价目页看到一列列单价，脑子是懵的：输入输出怎么分开、工具调用返回算不算钱、长上下文是不是重复计费、走中转站又是什么口径。这篇不给你任何绝对值，只给一套查数、换算、设闸、核对的流程，让你在任何一次调价之后都能自己把成本算清楚。

核心思路就一句：把「口径」和「数字」分开。口径是稳定的，token 分输入输出两档、折扣分层、重试也会花钱，这些不随调价变；数字是波动的，单价、倍率、套餐额度一律去站内页面核对当时的数字，别背、别抄群里的截图。

这笔钱到底按什么口径收

先分清计价单位。编码模型基本都按 token 分输入、输出两档，输出通常更贵，所以别用一个平均单价去乘总 token，那样误差能差出一倍。正确的做法是：调用日志里把输入 token 和输出 token 分开统计，再各自乘对应档位的单价，最后相加。

还要写清哪些部分会进账单。系统提示词、工具或函数调用的返回内容、被截断后重新拼上去的历史上下文，都会算进输入侧。很多人只看用户那句提问，忽略了系统提示词和工具回包，结果对账时发现用量比预期高一截。

• 输入、输出分开统计，别用平均单价一把梭；
• 系统提示词、工具回包、重拼的历史上下文都计入输入侧；
• 缓存命中、批处理、渠道倍率是折扣层，不是计价口径本身；
• 重试和失败请求只要产生了计费调用，一样会落在账单里。

当期数字去哪里核对，不要背

官方单价去站内的 OpenAI 价目页核对，模型库页面能对照上下文长度和规格，两个一起看才完整：只看单价不知道上下文多长，只看规格不知道要花多少钱。写完换算公式之后，把单价当成一个变量填进去，下次调价只换这个变量。

订阅套餐和按量 API 是两条线。想知道包月够不够，去编程套餐目录比额度折算，而不是盯着单价页。单价低不代表套餐划算，单价高也不代表按量一定贵，关键看你的调用频率和输入输出比例。判断标准是：如果一周里有好几天用量明显低于套餐额度，那套餐对你就是浪费。

单价页

看输入输出两档的当期数字，变量填进你的公式

模型库

核对上下文长度和规格，决定你的截断策略

套餐目录

比额度折算，判断包月还是按量更合适

价格追踪

看历史变动趋势，知道什么时候该重查

从你的真实用量倒推月成本

估算的起点不是单价，而是你自己的用量日志。先拿一周的日志出来，按调用次数、输入 token、输出 token 三项分开统计，别用总量。有了这三个数，你才能按档位分别相乘再相加，而不是拿一个平均数糊弄自己。

1. 取一周用量日志从你的网关或调用记录里导出调用次数、输入 token、输出 token，按天分开；验证方式是看三项各自的总和能不能对上日志行数。
2. 分档相乘再相加输入乘输入档、输出乘输出档，缓存命中的那部分单独拎出来按优惠档算；验证方式是把结果和上周实际账单比一次，差太多就是口径漏了项。
3. 乘波动系数留余量用日用量最高那天除以平均值得到波动系数，再额外留一笔重试与失败的余量；验证方式是拿这个估算值去和套餐额度比，看哪种更划算。
4. 决定按量还是套餐如果稳定用量已经超过套餐折算值，套餐更省心；如果波动大、有闲置天数，按量更灵活。

什么情况下这套估算不适用：刚上线、用量还没稳定的项目，或者正在做灰度测试、调用量一天一个样，这时候估算的参考价值有限，更应该靠预算闸兜底，等用量稳定两三周再回头算。

上预算闸和每月对账的动作

先设两道闸。第一道是单日用量上限，防止某次循环调用或者死循环把额度跑空；第二道是项目级预算告警，按周或按月设，触线就收到通知。两道闸的作用是让跑飞的损失能压在一个晚上以内，而不是月底看账单才发现。

每月固定一次对账，把账单里的计费项和充值记录、用量日志三方对齐。对不上的时候，先查两个地方：缓存命中的部分有没有单独拎出来、重试请求有没有重复计入。团队里把计费口径写进接入文档，新人换模型或换渠道时，先看口径再看价格，能省掉很多重复解释。

价格会变，口径不会；把口径记牢，把数字留给页面。

• 单日用量上限常开，防跑飞；
• 预算告警按周设，触线即查；
• 每月对账一次，三方对齐；
• 调价后重查一次页面，更新换算公式；
• 新人接入先读口径文档，再看价格。