Codex订阅额度消耗机制研究

作者：#Anyson 板块：#搞七捻三 Codex订阅额度消耗机制研究 一、背景与分析思路 相信大家每天盯着自己的Codex订阅额度变化，每次用Codex时，都要先纠结一下额度，这是非常令人头疼的。所以我就非常想弄清楚，Codex订阅额度的消耗机制。 Codex的每次API请求，会返回已用额度的百分比数据，以便在软件中显示。这个数据是会连同token是详细使用量，记录在本地的硬盘中文件。第三方程序可以读取这些文件，分析数据，来尽量还原Codex的订阅额度消耗机制。 我这边的分析方法是：首先使用脚本（文字最后有附），从本机电脑上读取Codex的使用记录文件，从中提取有用数据输出，并导出文件。主要的数据包括每次请求时返回的5H额度和周额度的已用值，以及每次返回的各种token的具体使用量，包括缓存输入、费缓存输入、推理输出、非推理输出。然后把这个文件扔给ChatGPT网页版的Chat模式，进行分析。 主要的分析思路是：在真实的使用数据里面，先找一些较为连续的任务，以任务为单位，进行拟合分析。这里的一个任务，要求是使用同一个模型的，并且在时间上比较连续，可能跨度几十分钟这样。这个任务要显著消耗一些5H额度窗口，否则分析起来容易误差太大。这里并不是找一个完整的5H额度窗口，然后计算总的相对于API原价的“订阅额度价值”，而是采用了一种“局部采样分析”的思路，用多个样本，去验证猜想。 主要从两个方面去推测：1. 我们先不考虑美元的价格，而是从使用数据的token量与额度消耗中，拟合计算以订阅额度为单位的价格，这里主要使用5H额度的百分点。这个推算需要先假设三种token的计费比例，我使用的是6系列为1/0.1/5，5.6系列为1/0.1/6。2. 先预定义一套标准价格，然后再从使用数据的token量与额度消耗中，反过来去拟合5H额度，之后再预定义一个5H额度（10刀，后来精确到10.3刀），计算模型的“价格倍率”。 二、我的账号与使用情况 最初我一直用的是那种10块钱的月抛Team订阅，买一次最多能用37天。后来从4月底开始，Team这种渠道没有了，而正好论坛又出现了48个月Team优惠的活动，于是5月10日左右，当时正好出来了英区11英镑的48Team，马上买了一个。上车后发现长期价格非常实惠，于是618那天，论坛再次爆出英区11英镑的48Team的优惠码，于是一口气开了三个，结果第二天就被封号，申诉无果后，后续最后通过银行争议退回钱款。几天后的7月1日，又出现了11英镑的48Team的优惠码，这次感觉靠谱，马上又买了4个号，并一直续费到现在。所以说相当于所有账号都是官方叫 Business Standard 的套餐，按照官方说法，额度跟Plus是一样的。 虽然一时冲动屯了很多号，但是我并没有马上把他们用起来，首当其冲的原因是需要准备多个长效手机号接码，其次是自己暂时没有很大量的Token需求。之前我的开发方式都是先跟AI对话，把具体细节都聊清楚了确定清楚了，再让AI一口气给干完。因为我很不喜欢那种AI先随便干，完事了我看很多地方不是我想要的，再让AI返工去改，认为这样1是浪费token，2是来回返工可能会让代码库的shi山含量增加。所以说这种开发方式上，对话的讨论、打字要消耗很多时间，token消耗并不快。7-8月份很长一段时间没有5H额度限制，额度使用可以非常灵活。8月底加入5H额度限制后，我又研究了下给网页版接入MCP使用网页版Chat模式开发（后来发现网页版的5.6Sol是为聊天专门优化的模型，实际产出代码的工程效果并不是很好），所以Codex竟然一个号一直够用。 最近9-10月份，我意识到不能总是白交钱，必须利用起来。于是9月份，我先用GG卡接码（怕GG卡后续失效，还是给子号用的），把其中唯一一个周额度的空间先用上。之后10月份，我又开了个 Amaysim 的 ESIM，这个比较靠谱一些，号码可以携号转网很方便，然后给几个母号绑上。 所以说，早期的大量数据都是基于一个号的，最近十一假期，我拿多个号频繁切换使用，并且开始学习“许愿式开发”，token消耗量大大增加，也带来了大量的数据样本，用来验证不同账号之间的额度也没有差异。 三、一些比较可靠的前提假设 这些前提假设是在前期分析的时候，通过我的账号的大量实际使用数据得出来的。这些结论的可信度比较高，因此在后续分析里面，是以这些结论为基础，来继续验证和修复的。这里需要先列举一下： 额度百分比是使用 nearest rounding 的方式取整 每次请求会返回两个额度的已用百分比（不是剩余），这个百分比是整数（虽然Codex的代码里是兼容小数的返回值的），估计是官方防止大家逆推Codex额度消耗机制，故意设计的。 经过大量数据的验证，可以比较确信的是：这些整数百分比，是通过 nearest rounding 的方式取整的，也就是说四舍五入，这个的也可信度是比较高的。 周额度是5H额度的6.4倍 或者说5H额度是周额度的1/6.4。这个6.4是比较准确的数字，误差在±0.05以内。 由于百分比取整在周额度上带来的误差太大，所以我们主要推算的是5H额度。对于周额度，直接使用5H额度x6.4计算就行了。 每次请求返回的额度百分比的延迟机制 每次请求返回的额度使用百分比，是这个请求开始执行之前的状态，不是执行完成之后。所以相当于lag=1，但是也会有额度扣减有延迟的情况。 大多数的数据点按照lag=1，就能拟合的很好。 不同模型几种token的价格比例 这个也是经过一些数据的实测，可以得到 非缓存输入/缓存输入/输出 这三种token的价格比例。结果是 GPT-6 系列为1/0.1/5，GPT-5.6 系列为1/0.1/6。 这个结论是有很多实测数据拟合支持的。很多站内佬友认为订阅额度消耗是把缓内输入x2了，这里要解释一下，就是大家使用Codex的情况，大概95%的token都是缓内输入，因此账单占比也是缓内输入占了绝大部分。因此，很多整体的模型倍率变化，似乎也可以用缓内输入x2来解释。 特殊模型的特殊政策 经过数据实测后，大部分模型都可以按照API原价作为“基准价”的。但是有2个例外： 首先是 GPT-6.1 Sol，API价格把缓内输入比常理砍半了。但是经过大量数据拟合，目前更加支持的结论就是对于订阅额度消耗，这个砍半的特别待遇并不存在。也就是仍然遵守 GPT-6 系列 1/0.1/5 的比例。 其次是 GPT-5.6 Sol，这个模型之前官方打8折降价，变成 4/0.4/20，但是官方同时说明订阅额度的消耗并不受这个优惠的影响（5.6的Terra和Luna的折扣同时适用于订阅额度的消耗）。中转站目前也基本都还在使用 5/0.5/30 的价格，因此我们的“基准价”都还是这个价格。 这样，我们就得到了各个模型的“基准价”，具体将在下一章展示。 四、深入分析过程 首先，如果额度要用“美元”来算（实际上并不能说是钱），我们需要给几个模型定义一下基本的价格，即为“基准价”，用于后续分析。这个价格表是是这样的： 模型 价格（缓外输入/缓内输入/输出） GPT-6 Astra 10/1/50 GPT-6.1 Sol 2/0.2/10 GPT-6 Sol 2/0.2/10 GPT-6 Luna 0.1/0.01/0.5 GPT-5.6 Sol 5/0.5/30 GPT-5.6 Terra 2/0.2/12 GPT-5.6 Luna 0.2/0.02/1.2 GPT-5.5 5/0.5/30 然后，我们需要先假设一个初始“美元”的额度，再对此进行微调。根据之前对大量 GPT-6 Astra 的使用数据分析，特别是有一些只用Astra然后直接用完5H额度窗口的情况，发现5H额度大概是10刀左右。因此我们就定义这个初始“美元”额度为5H额度10刀，周额度64刀。这是一个比较整的数，按照官方 1刀 = 25 credits 来换算的话，相当于5H额度 250 credits，周额度 1600 credits。 下一步，我们就开始进行进一步分析了，具体将在下一章展示。 五、订阅额度消耗机制的研究结论 之后我们就使用预先定义的基准价和初始额度，在真实数据中去进行拟合，得到了每个模型的倍率，和修正后的额度。 由于分析过程主要由AI进行，而本站不允许放AI生成的内容，截图也太长，所以我这里就直接说结论了： 模型 基准价格（缓外输入/缓内输入/输出） 倍率 额度价格（基准价格x倍率） 相对Astra的额度消耗比例 GPT-6 Astra 10/1/50 1.0x 10/1/50 1 GPT-6.1 Sol 2/0.2/10 0.825x 1.65/0.165/8.25 1/6 GPT-6.1 Sol (修正前) 2/0.2/10 0.8x (修正前) - - GPT-6 Sol 2/0.2/10 1.0x 2/0.2/10 1/5 GPT-5.6 Sol 5/0.5/30 0.5x 2.5/0.25/15 1/4 GPT-5.6 Terra 2/0.2/12 1.0x 2/0.2/12 1/5 GPT-5.6 Luna 0.2/0.02/1.2 1.0x 0.2/0.02/1.2 1/50 GPT-6 Luna 0.1/0.01/0.5 1