刚刚看到 Tibo 说 Codex 额度用的太快是 sub2api 的问题

@tho 也有自己中转的 可以用于团队和项目中

@tho 我们就是 2 个 pro 20x 团队 10 个人用 还有服务器和项目中用到 AI 也用中转处理的 API 这样会更方便 要是完全按需那就要开几个 plus 几个 pro 然后 API 有单独买 API 很麻烦 也划算一点

@tho 问题是 openai 的 plus 订阅基本能满足我 2/3 的需求。不值得去买 5x 20x 。用国模也得要能连上聊天记录才行。

@yanyuechuixue 用官方订阅和第三方中转站 API 切换不冲突，cc-switch 本身就支持共享对话，不必非得将订阅转成 API

@yanyuechuixue 要保留消息记录 不用必须把你的订阅成 API 可以把 model_provider 用一个就可以

只是找一个借口而已，我自己一个人美区 200 美金订阅的 Pro 20x ，之前额度还相对正常，昨天重置之后就消耗异常，一天多时间就只剩 36% 了，本地统计额度只有 450 美金左右，缓存名字 98.1%，除非是官方将所有缓存命中的都计费成未命中，否则这消耗明显低于之前 2400 ～ 3000 美金的额度。

个人猜测 OpenAI 是在灰度低额度模式，这样可以省下一大笔钱，只要大部分人都没有注意到额度变化，后续 Pro 20x 的额度可能就只有 800 美金上下了。为什么这么猜测，因为不止国内用户，国外用户在 Twitter 上骂得更凶...这可能会是国外正版用户基数大于国内用户导致的，国内大部分用户还都在通过中转站使用 GPT 。

放狗屁，直接 codex 用一样消耗变多了。

我不讲什么乱七八糟猜测的结论，我就直接列举一些事实.
我从 2 月份开始，在 DMIT 的服务器上使用 Sub2API,5 月份开始稳定两个 Plus 账号,当然也是固定 IP 。
目前从 Sub2API 上的数据来看，没有被降权。每个 Plus 账号每周大概能获得 110 ～ 120 刀的额度。
但是我觉得 Tibo 肯定是没有说老实话的，也没有说全部的，有些事情是不可能说出来的

@waklealone #1 这个结论不能得出，因为没有中转站，所以你无法统计你实际用了多少。就是他说多少就是多少了。

Tibo 没说实话吧感觉😂

@ntdll codex 好像本身就可以直接查用了多少 token ，另外如果用 CC Switch 的话也能看用量的

我是美区买的 20x 帐号，公司内部搭建 sub2api ，看着已经被招安了，后面估计只能用实打实的 api 了

@lgc931018
我有观察 usage 的，看起来并没有 reset 。刚刚开了 sol high+luna max 的子 agent 讨论了大规模重构方案，我驳回了 2 次才消费了 6%。我的场景是本地长期 2 个处理 repo ，偶尔有 1-2 个 repo 偶尔需要修改，每个 repo 不超过 3 个 thread ，网页版隔离上下文讨论其他方案。我不确定其他不使用 sub2api 同样遇到额度快速消耗的场景是怎么样。btw ，我的账号都是走一个固定 ip 的，虽然是机房 ip ，但是纯净度还 ok 。

@zmfang1995 看作者加了狗头 不知道真假

codex 自己检查结果，还有啥好说的 tibo 格局太低，我都是自己的好没用 sub2

结论：你的账户本机记录里，确实出现了很强的“同等本地 token 消耗却更快扣周额度”的断点信号，量级约为 -45%；这与社区说的 Plus 砍半相符。
周窗口 本地总 token 代理值 已扣额度 每 1% 额度对应 token
上一完整窗口（ 8/15–8/19 ） 125.9M 100% 1.26M
当前窗口（ 8/20 起） 31.3M 45% 0.70M


按当前消耗率线性折算，完整窗口约相当于 69.6M token ，较上一完整窗口低 44.7%。再往前一个完整窗口是 169.8M ，因此相对近期历史的下降幅度约 45%–59%。
这不是简单由缓存减少造成的：当前窗口缓存输入占比反而约 96%，高于上一窗口约 92%。当前主要也是 Terra 使用，并非切到更昂贵模型才造成的表面差异。
边界是：本地日志没有服务器端“总 token 上限”的原始字段，且任务长度、模型、推理强度会影响消耗，因此我不能证明 OpenAI 对所有用户统一改了某个固定数值。但对你的账号而言，证据已经足够支持：当前周额度的实际可用工作量大概率已经明显下降，约接近砍半。

我完全没有过 sub2api 但是还是降了， 就是错误标记呗， 把合同当放屁是不是， 当初签了你管我怎么用。 而且当初不是还支持代理出来其他的 cli 用吗

重点错了...重点不是 sub2api 而是 **分发**：把一个订阅分发给多个人使用。sub2api 最多也就是风控的一个权重比较大的特征。
很多人根据没有 xx 行为也降了额度来反驳，这是不了解风控算法。风控不会通过单一特征决定。你的会话/并发/使用时间/使用量/历史是否曾经分发过都可能成为特征。甚至如果同时使用中转站和自己的订阅，不排除自己没有分发行为的订阅被风控连坐的可能。

plus 使用 codex 客户端，目前体感就是翻 2 ~ 3 倍

@fcten 我目前的用法就是一个订阅多个人使用 上周确实消耗很快 好多没有这样使用的也是额度消耗很快 现在在蹲后续

胡说八道，claude 同样的钱耐用多了