先交代下前提,免得大家怀疑是不是中转渠道或者反代的问题:
我用的是官方 Pro 20x,Apple Store 美区礼品卡正价订阅,全程官方直连,没用任何反代。
Astra 出来后我基本一直在用,但这几天最大的感受就一个字:额度掉得太快了。
而且这真不是单纯的体感玄学。我之前为了看 Codex 的额度消耗,专门写了个小插件做统计,所以手里正好有一批数据可以拿来对比。
插件的统计逻辑
Codex 官方本身是支持 OTel 的,运行中会往 OTel 服务发送事件,里面就包含每次请求的 Token 消耗。再结合 Codex 本地的 JSONL 和 SQLite 文件,基本能把每次请求的信息完整拼出来:
- 模型、输入 / 输出 Token、Cache Read
- 推理强度、是否开了 Fast
- 具体的请求时间戳等
拿到这些数据后,我就拿去估算自己的等效周额度。
先说明一下:我肯定不知道 OpenAI 内部具体怎么算订阅用户的周额度,官方也没公开过公式。文里提到的「2500」「1500」并不是说官方真给了这么多美元,只是我统一按 API 定价折算出来的一个参考值。
但拿来做横向对比很有意义——只要计算公式不变,Sol 和 Astra 算出来的差距,就能直接反映出两者实际扣周额度的差异。
官方前端的周额度百分比不显示小数,所以我是这么算的:
比如现在显示用了 5%,我就去找本周额度起始点,到官方最后一次显示 4% 的那个时间点,统计这个区间内所有请求消耗的 Token,再按 API 单价折算,反推 100% 满额是多少。
实测数据:Sol vs Astra
这套算法我观察了挺长时间,数据一直很稳定:
- 用 Sol 时:我长期是
Sol + xhigh + Fast 这种比较暴力的用法,算出来的等效周额度稳定在 2500~2600 左右,运气好甚至能飙到 2800。
- 切到 Astra 后:同样一套计算逻辑,周额度最多只有 1500 左右,有时候甚至还不到 1500。
一开始我也怀疑,是不是我把用 Sol 的老习惯带过来了?推理强度开太高、或者 Fast 太贵把额度吃垮了?
于是我专门做了控制变量测试:把推理强度往下降,同时也把 Fast 彻底关掉。
结果……没什么卵用,额度还是掉得飞快。
降推理和关 Fast 并没有明显缓解,基本可以排除单纯是“xhigh 太贵”或“Fast 太贵”的原因。
一个特别奇怪的发现(关于 Cache Read)
我现在插件里用的 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
按这套价格去算 Astra,得到的周额度就是前面说的 1500 左右。
然后我突发奇想做了个测试:
其他参数全都不动,只把 Astra 的 Cache Read 从 1 改成 2。
结果重新一算:周额度居然又奇迹般地回到了 2500 左右!
这就让我有点摸不着头脑了。
按理说,Astra 的 API 价格比 Sol 贵不少(5/30/0.5 vs 10/50/1),同样用一周,Astra 更早撞限额我觉得完全合理。
但问题是:我在折算时已经把 Astra 更贵的 API 单价代进去了。 理论上最后反推出来的“额度总盘子”不该缩水这么夸张才对。更诡异的是,只要把 Cache Read 人为按 2 算,数字就刚好对齐了。
目前我自己的两个猜测
- Astra 在 Pro 订阅里的额度权重,并不是简单按 API 价格算的
OpenAI 内部可能给 Astra 设置了更高的扣费权重,尤其是 Cache Read。虽然 API 标价是 1,但在订阅额度内部实际可能按更高权重扣。
- Astra 现在的额度计算存在 Bug
之前 Sol 刚出来的时候额度结算也出过异常。不排除是新模型刚上线,内部额度折算规则还没调平,后续可能会热修。
总结与交流
目前能确定的几个现象:
- Sol 统计了很长时间,2500~2600 基本稳定;
- 换 Astra 后,同套算法只能算到 1500 左右甚至更低;
- 降低推理强度、关闭 Fast,并不能明显改善额度暴跌;
- 把 Astra 的 Cache Read 从 1 改成 2,周额度刚好能回弹到 2500 左右。
想发出来问问大家:
有没有同样是 Pro 20x,之前长期主力 Sol、现在切 Astra 的兄弟?你们有没有感觉 Astra 的周额度掉得特别离谱?
如果有同样自己做 Token 统计的,也欢迎把数据丢出来对一下,看看这到底是被暗砍了权重,还是刚上线的计费 Bug 😂