先说下前提，免得大家怀疑是不是渠道或者反代的问题。
我用的是官方 Pro 20x，Apple Store 美区礼品卡正价订阅，全程没有用任何反代。
Astra 出来以后我基本一直在用，但这几天最大的感受就是一个字：额度掉得太快了。
而且不是单纯体感快，我自己之前为了看 Codex 的额度消耗，专门写了个小插件做统计，所以手里还是有一些数据可以对比的。
纯sol 2500左右，纯astra 1500左右
以下是我的插件计算逻辑
计算逻辑
插件逻辑其实很简单。
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 这玩意到底是怎么算的 
2026-09-07、我去测下，稍等把结果发出来
目前测试几乎无任何变化，要不是修复还没有发布，要不是这老小子骗人。
2026-09-08 更新
今天额度重置后又测试了下，发现一个问题，使用体感上,周限额的使用速度确实慢了很多。但是用api去推断额度的话大概还是那些，所以用api定价去衡量订阅号的额度确实是不对的，但是确实没有其他很好的算法了，额度当参考吧。另外，我改了下我的插件，记录每一个百分比耗了多少token和额度，发现非常的不均匀。如果你经常的开新会话，你的缓存率就会低，那么你的输入token去折算额度就会发现很高，但是实际上周限额的百分比扣减和高缓存的速度差不多，感觉是oai均衡了这两种情况（个人猜测）
2026-09-11 更新
周期用完了，确实是 1400，但是体感确实慢很多，我全程fast
