Codex限额投票与上下文容量调整
AI科技 · 7 篇公开推文 · 6 位作者 · 曝光 149604 · 评论 192 · 点赞 465 · 书签 35
OpenAI相关推文聚焦Codex使用限额和上下文容量变化,包括Pro用户投票、额度重置及默认上下文调整;用户质疑决策透明度及实际可用额度。
创作角度
- 追踪OpenAI订阅限额、Codex重置与默认上下文调整的时间线
- 解释Pro用户关于5小时限制与周额度的投票内容
- 核对上下文长度变化及其对Token消耗和使用体验的影响
- 比较用户对限额透明度和产品决策的不同看法
相关公开推文
卧槽,细思极恐…… Tibo 到底是昨天被骂怕了,还是突然良心发现了? 今天居然宣布 GPT-6.1 Sol 在超过 272k 上下文后,不再额外计费。 总不能是先给大家一点甜头, 回头就宣布 Pro 用户也要加上 5 小时限制吧……😨
曝光 40872 · 评论 39 · 点赞 117 · 书签 5
查看原帖Day 7 tibo开始整烂活了,把默认上下文改成272k调整到500k,默认上下文变大反而会极速加快token消耗🤣 但是其实几个月前,GPT就支持通过配置调整上下文大小打1M,如果你没调整过,说明根本不需要 model = "gpt-6.1-sol" model_context_window = 1000000 # 将上下文窗口设置为 1M (100万 Token) model_auto_compact_token_limit = 900000 # 设置自动压缩阈值为 900K
曝光 20665 · 评论 27 · 点赞 21 · 书签 6
查看原帖昨天 Codex 刚全员 Reset,Tibo 又开了个投票问 Pro 用户,要 5h 限制加双倍周额度,还是不要 5h 限制、额度不变 最后 24 万票,不要 5h 限制 38%,双倍那边 33%,剩下 29% 是来看结果的。只算真投的大概 54 比 46 Tibo 自己都说看懵了,他本来以为大家肯定会一边倒选 2X,哪怕代价是为了平滑需求曲线把 5h 限制加回来 我感觉大家是真被 5h 窗口搞烦了,干到一半被卡住的体验,比多一倍周额度更让人记得住。不过投票谁都能点,里面到底有多少真 Pro 用户也不好说 https://x.com/thsottiaux/status/2109439315570999598?s=46
曝光 20125 · 评论 38 · 点赞 27 · 书签 1
查看原帖这个事情实在是太有意思了。早上 Tibo 发起了一个投票,其实本质上还是耍猴,他其实早就有了想法。 他想让大多数人都投,加上 5 小时限制,但是额度翻倍. 因为额度本来就已经减半了,所以说这个翻倍就是恢复原来的额度,然后再加上5小时的限制。 但是没想到,OpenAI的信誉已经降到了冰点,大家都认为额度这个事情是说不清楚的,而且它后台是可以调的; 但是5小时的限制加上与不加上,是实实在在看得见、摸得着的。所以大家反而都叛逆地选择了不要加上5小时限制,不要额度翻倍。 这样导致 Tibo很难推进他自己想要的想法,就是顺水推舟地恢复额度,加上五小时限制。 因为毕竟太多人已经停止订阅 OpenAI,想通过这样一个所谓“民主”的投票挽回用户。
曝光 19922 · 评论 25 · 点赞 115 · 书签 11
查看原帖两天前 Codex 负责人 Tibo 还在说,Codex 选 300k 上下文是算过数据的,1M 也能跑,只是更费额度,好的默认值很重要。 今天 GPT-6.1 Sol 在 Codex 里的默认上下文就从 272k 提到了 500k,说这是大多数用户新的最佳平衡点,订阅额度里也不再收长上下文费用了。 Good defaults are important,确实,两天就换一个。 Claude Code 这边正好反过来,默认到 1M 才 autocompact。rohit 拿自己最近一周的用量回放了一遍,调到 400k 能省 29% 的周额度,按他的说法效果也没受影响。 https://x.com/thsottiaux/status/2108778939057664357?s=20
曝光 19613 · 评论 8 · 点赞 34 · 书签 6
查看原帖