• L-BlackHole

    先说下前提,免得大家怀疑是不是渠道或者反代的问题。

    我用的是官方 Pro 20x,Apple Store 美区礼品卡正价订阅,全程没有用任何反代。

    Astra 出来以后我基本一直在用,但这几天最大的感受就是一个字:额度掉得太快了。

    而且不是单纯体感快,我自己之前为了看 Codex 的额度消耗,专门写了个小插件做统计,所以手里还是有一些数据可以对比的。

    插件逻辑其实很简单。

    Codex 官方支持 OTel,运行过程中会往 OTel 服务发送事件,其中就有每次请求的 Token 消耗。

    我再结合 Codex 本地的 JSONL 和 SQLite 文件,就基本可以把每次请求的信息拼出来,比如:

    模型、输入 Token、输出 Token、Cache Read、有没有开 Fast、推理强度、请求时间这些。

    然后我拿这些数据去估算自己的周额度。

    这里先强调一下,我肯定不知道 OpenAI 内部到底怎么计算订阅用户的周额度,官方也没公布公式。

    所以我这个“2500”“1500”并不是说官方真的给了这么多美元额度,只是我按照 API 定价统一折算出来的一个参考值。

    但我觉得拿来做横向对比还是有意义的。

    因为只要我自己的计算公式一直不变,那 Sol 和 Astra 算出来的差距,就能大概反映出两者实际扣周额度的差异。

    官方那个周额度百分比又没有小数,所以我是这么算的:

    比如现在显示用了 5%,我就去找本周额度开始时间,到官方最后一次还显示 4% 的那个时间点,然后统计这个区间内所有模型请求,再按照 API 单价折算。

    这样反推出来的周额度其实一直还挺稳定的。

    我之前基本纯用 Sol,而且还是长期:

    Sol + xhigh + Fast

    这种比较暴力的用法。

    算出来的周额度通常在:

    2500~2600 左右

    有时候运气好一点甚至能飙到 2800 左右。

    所以这个数据我观察了挺久,不是只测了一两次。

    然后 Astra 出来以后,我基本切成纯 Astra 使用。

    结果就非常奇怪了。

    按照同样的方式算,周额度最多只有:

    1500 左右

    有时候甚至还不到 1500。

    一开始我也怀疑,是不是因为我还在按照以前用 Sol 的习惯,推理强度开太高,Fast 也一直开着,所以 Astra 才掉得特别快。

    于是发现这个问题以后,我又专门继续测试了一段时间。

    我把推理强度往下降,同时也把 Fast 关掉。

    结果……

    没什么卵用,额度还是掉得飞快。

    至少从我自己的使用来看,降低推理强度和关闭 Fast 并没有明显缓解这个问题。

    所以目前我感觉它不像单纯是“xhigh 太贵”或者“Fast 太贵”导致的。

    然后还有一个特别有意思的地方。

    我现在插件里面用的 API 单价是:

    gpt-5.6-sol

    输入:5

    输出:30

    Cache Read:0.5

    Fast 倍率:2.5

    长上下文输入倍率:2

    长上下文输出倍率:1.5

    gpt-6-astra

    输入:10

    输出:50

    Cache Read:1

    Fast 倍率:2.5

    长上下文输入倍率:1

    长上下文输出倍率:1

    按照这套价格算 Astra,我得到的周额度就是前面说的 1500 左右。

    然后我突发奇想做了个测试:

    其他参数全部不动,只把 Astra 的 Cache Read 从 1 改成 2。

    结果重新一算:

    周额度居然又回到 2500 左右了。

    这个就让我有点摸不着头脑了。

    我个人觉得,Astra 比 Sol 更吃额度这件事情本身没啥问题。

    毕竟 Astra 的 API 价格本来就比 Sol 贵不少。

    Sol 是:

    5 / 30 / 0.5

    Astra 是:

    10 / 50 / 1

    所以 Astra 同样用一周,比 Sol 更早撞限额,我觉得完全合理。

    我真正想不明白的是:

    为什么按照相同的 API 定价逻辑反推,Sol 的周额度能稳定在 2500~2600,到了 Astra 只剩 1500 左右?

    如果只是因为 Astra 本身 API 更贵,那么我在折算的时候其实已经把这个价格差算进去了。

    理论上最后反推出的“总额度”不应该缩水这么夸张才对。

    更奇怪的是,只要我把 Astra 的 Cache Read 从 1 按 2 来计算,结果又刚好基本恢复正常。

    所以现在我自己有两个猜测。

    一个可能是:

    Astra 在 Pro 订阅里的额度权重,本来就不是简单按照 API 价格来的,OpenAI 内部可能给 Astra 设置了更高的扣费权重。

    比如 Cache Read 虽然 API 是 1,但订阅额度内部实际上可能按更高权重扣。

    当然这个只是猜测,我肯定看不到 OpenAI 后台怎么算。

    另一个可能就是:

    Astra 现在的额度计算有点问题。

    因为之前 Sol 刚出来的时候额度好像也出现过一些异常,所以也不排除是新模型刚上线,内部额度计算还没完全调整好,后面又会修。

    反正我现在能确定的只有几个现象:

    我统计 Sol 很长时间了,2500~2600 基本比较稳定。

    换成 Astra 后,同一套算法只能算到 1500 左右甚至更低。

    发现掉得快以后,我降低推理强度、关闭 Fast 继续测,还是没明显改善。

    但是把 Astra 的 Cache Read 从 1 人为改成 2,反推周额度又差不多回到了 2500。

    所以想发出来跟大家一起研究研究。

    有没有同样 Pro 20x,而且之前长期用 Sol、现在切 Astra 的兄弟?

    你们有没有感觉 Astra 的周额度掉得特别离谱?

    如果大家都这样,那大概率就是 Astra 在订阅额度里面确实有一个额外权重。

    如果只有部分人这样,或者过几天突然正常了,那感觉就更像是刚上线时候的额度计算问题。

    有自己做 Token 统计的也欢迎把数据丢出来对一下,我现在也挺想搞清楚 OpenAI 这玩意到底是怎么算的 ^-^

    主楼
  • Jim_Green

    用的太快了。明显不正常,哪怕是用中,也哗哗掉

    #1
  • 有色戏言

    就是掉的很离谱,今天我也发现了这个问题

    #2
  • JarvisTown

    我也发现有异常了,消耗速度快得不正常,果然gpt-6修复了pro 20x 蹬不完的bug

    #3
  • sdxdlgz

    感觉是不太对,20x用的还是astra的medium,额度一转眼就掉了6%

    #4
  • undefined

    图片

    $1047用了150%周限 之前5.6的时候一个周限就能用$1800左右的

    #5
  • 花白

    在不同的用量的情况下分别取数据点,然后列举多种猜想的报价体系和目标额度。

    #6

发表回复

登录后回复