关于GPT-6 Astra 的额度异常问题

L-BlackHole 2026-09-06 22:04 1

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


我用的是官方 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 这玩意到底是怎么算的 ^-^

最新回复 (6)
  • Jim Green 09-06 22:39
    1

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

  • 有色戏言 09-06 22:41
    2

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

  • JarvisTown 09-06 22:45
    3

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

  • sdxdlgz 09-06 22:45
    4

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

  • undefined 09-06 22:46
    5


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

  • 花白 09-06 22:49
    6

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

* 帖子来源Linux.do
返回