为什么codex的重置实际上对用户是亏损的?本质上更是违约

Neo-Isshin 2026-08-09 17:13 1

我们来做一个简单的计算:

在不考虑用户每日消耗量的前提下,假设用户每日平均消耗14%的额度(约7/100)来预估,且正常使用重置为每周一早上10点。


如果周二重置, 而该用户周一的使用量为0%,那么本应在周一的重置被延后了一天,那么就相当于用户在八天本应有114%的额度,但只剩下100%,也就是少了约12.3%。而不得不接受重置延后带来的损失。

如果周三重置, 而该用户周一周二的使用量均为0%,同理可得,该用户承受了21.9%的亏损

当然,你为了应对这种损失,也可以尽情在周一就消耗100%的额度,然后周二重置时,这样你就获得了8天200%的额度,你获取了75.4%的收益。


然而问题在于:无论任何时间的重置,你的7天100%的额度都不应该被调整,这属于违约!


换句话说,按照假设来走的话,你应该确保使用每天超过14%的额度,在理想计算的前提下你才能够防止重置带来的亏损。

但你真金白银购买的是7天100%的订阅,而非8天114%的订阅,更无法接受8天100%的订阅。openai不应该随意调整你的订阅额度。

你更不需要为了让自己为了避免这种损失,从而自己逼迫自己每天消耗14%以上的额度。你将额度都存在最后两天用,是非常合理的。

真正的重置,应当是发放bank的类型,这才是用户能够自己掌控额度的方式。


理性讨论

最新回复 (19)
  • 潮汕牛肉丸享受者 08-09 17:14
    1

    重置但是不改变原有周限时间是最好的吧 这样不分青红皂白的延后确实有问题

  • KTpQS 08-09 17:19
    2

    所以利好大刷特刷的用户&中转站么 ^-^

  • _zhang 08-09 17:20
    3

    所以你的结论是如果不发bank 重置, 不如不重置对吧。

  • kiddoo 08-09 17:21
    4

    亏损倒不至于,但是现行规则下,每次重置后 尽快消耗掉大部分额度。就是最优解。

  • Neo-Isshin 楼主 08-09 17:21
    5

    尤其利好中转站。但是对用户仍然不好。

  • pboy 08-09 17:22
    6

    重置并立即开始周限计时就可以解决这个问题了。

  • neri 08-09 17:22
    7

    (帖子已被作者删除)

  • Neo-Isshin 楼主 08-09 17:22
    8

    看算法啊。重置后如果不用,那就是实打实的亏损

  • Neo-Isshin 楼主 08-09 17:22
    9

    还升米恩斗米仇上了。你看过我的算法了吗就来这扣帽子?

  • Meowretti 08-09 17:23
    10

    亏损只是指前两天少用的情况,如果刚拿到重置就开始用确实能多用token。加上没有五小时限制,总体还是利好的吧,至少开始重置后我确实用量更多了

  • kiddoo 08-09 17:23
    11

    它不重置,你不用也是亏呀。相信对大多数用户来说,重置仍然是利好。

  • neri 08-09 17:23
    12

    如果能选择能够重置和不重置,这种回复不利好用户的人你觉得他们是会开还是不会开呢?

  • Sakiko 08-09 17:24
    13

    开头“假设用户每日平均消耗14%的额度(约7/100)来预估,且正常使用重置为每周一早上10点”,你只能说明这种情况下重置是亏损,但对蹬的快的人来说,这确实是不亏损的。所以你这帖子的标题是扩大化的

  • William 08-09 17:24
    14

    什么叫如果周二重置,我有点看不懂,周一开的能周二重置?

  • Neo-Isshin 楼主 08-09 17:25
    15

    并没有扩大化,因为重置的亏损是实际存在的。用户是否使劲用是用户自己的自由。

    我的算法重点表达的是,openai不应该随意延后用户的重置时间,这是重点

  • 天地无极羹 08-09 17:25
    16

    有额度但是两天一点都不用的人,大概率本来也用不完额度,谈不上亏

  • 天地无极羹 08-09 17:25
    17

    人家做活动想怎么做就怎么做,你这样完全没道理的

  • ironfish 08-09 17:26
    18

    不太理解,实际上每周都有额外的1-2次重置的情况下,实际怎么都是利好吧?

  • ksw_one 08-09 17:26
    19

    我理想的重置是重置我的额度但是不要重置我的时间^-^

* 帖子来源Linux.do
返回