他俩是个啥关系？我理解 5 小时有余量，就应该让用啊
This topic created in 147 days ago, the information mentioned may be changed or developed.
Supplement 1 · Jun 11
哈哈哈，才看到，太搞笑了各位。
谢谢各位老哥，我以为是优先用每 5 小时的，用完 5 小时后开始用每周的
谢谢各位老哥，我以为是优先用每 5 小时的，用完 5 小时后开始用每周的
 |
1
或
|
1 |
3
鞋子的码小了，你袜子买的再大，也穿不了鞋走路。
|
 |
KJHJun 11
4
if (周用量 > 0 && 5 小时用量 > 0) {
return true; } else { return false; } |
 |
5
很难理解吗？
|
 |
i67c6NJ0r33nC667Jun 11
6
蛤？
|
 |
7
逆天…… 无法想象如果没有 AI 你会写多少 bug
|
 |
xiaomimicoin2Jun 11
8
今天就问了 1 个问题 claude opus 5 小时的量就给干完. 现在死贵啊
|
 |
oop12Jun 11
9
与
|
 |
niubilewodevJun 11
10
如果你周限都用完了，5 小时还有还能用。
那服务商为什么要设置周限制？ |
 |
ovtfkwJun 11
11
||
|
 |
neuthselfJun 11
12
且的关系，两个额度都需要大于 0 。5 小时额度没了用不了，周额度没了也用不了。
|
 |
rtvJun 11
13
用量上限每周、每 5 小时都是固定的，给你显示的时候按照已使用/上限计算
你可以认为这是一个小 bug ，但是不影响理解 |
 |
remarrexxarJun 11
14
一周的量是你账号真的额度，五小时只是限流额度。
|
 |
ziokaiJun 11
15
为什么都喜欢搞 5 小时限额，一下就用完了
|
 |
16
论坛上下限被你扩大了
|
 |
17
我感觉你可能不适合做开发
|
 |
18
无法理解为什么你无法理解，这不是很明显吗
|
 |
layxyJun 11
19
周限是你这周可以使用的总额度，5 小时限制只是限制你每次可以使用多少周限额度，不是说你还有多少额度
|
 |
Fish1024Jun 11
20
够聪明的。
|
 |
tianjiyaoJun 11
21
。。。这就好比一周的总量是 700 升水，每五小时使用量是 100 升水，这 100 每次需要从 700 里去舀水啊。。。
|
|
tianjiyaoJun 11
22
有个办法少许超额一点点 就是让他干一个长任务的活 5 小时额度用完的时候不会直接停止而是会把活干完。。。这一段时间的好像是不消耗额度的。。。
|
 |
FstarKingJun 11
23
之前一直用中转站，想问下，如果我用 ios 的礼品卡， 充值 gpt 会员，使用 codex ，会封号吗？
|
 |
lpe234Jun 11
24
我理解的是周限制是一周的总量。而五个小时主要是限制使用的频率。
--- 最简答的例子：一周给你 100 块钱，但是限制你 5 小时内最多花 20 块钱。 |
 |
EthanV2Jun 11
27
1 周总量 > 5 小时滑动窗口
|
|
28
怀疑楼主如果写一个用户充值打 8 折的活动，是不是会把用户充值的钱乘以 0.8 充到账户
 |
 |
SilentOrFightJun 11
29
|
 |
ntdllJun 11
30
关系异常的简单
if limit_5_hours return if limit_weekly return // continue |
 |
31
银行卡余额：0
单日消费限额：20000 我艹，怎么不让我花钱了 |
 |
heyitsmeJun 11
34
一个月 1000 块的生活费，规定每天最多花 100 ，某一天 1000 花完了，当天花了 50 ，你问：为什么我今天花了 50 就没钱了
|
 |
RickkkkkkkJun 11
35
无法直接从这个现象快速想出原因真的反思一下了...是简单的推导
|
 |
36
虽然一般大家都能理解，但是这一点产品上来说绝对可以做的更好：
session 余量将周余量纳入判断，显示真实可用余量。而非两个独立的进度条。 |
|
niubilewodevJun 11
37
|
|
i67c6NJ0r33nC667Jun 11
38
这个帖子下的回复太好笑了
|
 |
tracebundyJun 11
39
看来即使用上 AI ，大家水平还是有差距
|
 |
datouguaJun 11
40
转行吧
|
 |
zzzzz024Jun 11
41
这个帖子让我加深了认识： 程序员的水平是参差不齐的
|
 |
summerLastJun 11
42
5 小时 平均每小时额度>7 天 每小时平均额度，哪个额度到顶了，都会触发限流
|
 |
43
这能理解不了，你真是程序员吗
|
 |
florentinoJun 11
44
5 小时是控速,7 天是控量,也可以理解为 5 小时限流, 7 天限量
|
 |
FelldeadbirdJun 11
45
这样？啊。你理解成 某个时段限额 是 5 小时。 周额度就是 你总可用资金。
|
 |
paulleeJun 11
46
AI 就是替代‘用量计算方式都搞不明白’这一类程序员。别用了，你在用自己就要失业了。
|
 |
yoruoxxJun 11
47
我懵了 ？？
|
 |
soouuJun 11
49
怎么会有人问这种问题
|
 |
50
“下班顺路买十个包子，如果看到卖西瓜的，买一个。”
你是不是就是那个买了一个包子的  |
 |
zylll520Jun 11
51
哈哈哈哈，你们太过分了～
|
 |
WilliamColtonJun 11
52
天，要是两者之间是或的关系，那还需要周额度干什么。。。
|
|
53
@niubilewodev #37 产品为人服务的，满足需求复杂度作为成本肯定得接受。另外其实也没那么复杂，后端计费限额逻辑完全不用改，只要改展示逻辑，我让 codex 自己做了个 demo: https://output.jsbin.com/watucayudi
|
 |
zenshenJun 11
54
到底是谁在提问，到底是谁！
|
 |
55
我觉得这算是 openai 的一个 bug ，存量不一致。
|
 |
pppandaJun 11
56
看完帖子，我都怀疑自己来错了论坛。。。
|
|
niubilewodevJun 11
57
|
 |
maoqiucuteJun 11
59
仿佛来到了百度弱智吧
|
 |
daodaoJun 11
60
这智商，很难理解吗？
你这个脑袋可能不适合用 codex 写代码。。 |
 |
61
确实有点像弱智吧的帖子，笑死
|
 |
greygooJun 11
62
用户不应该去懂 openai 的业务逻辑,用户看到有余量,就应该让用啊.而前端肯定懂业务逻辑,所以我觉得是前端的锅,不是 op 的,这样写的确会造成歧义的.
估计是 vibe code 出来的.AI 经常在这个层级关系犯迟钝. |
 |
showonderJun 11
63
从程序员角度来讲，这个问题很弱智；但从多数用户角度来讲，这个还真是一个体验问题。
|
 |
tangshengxiangJun 11
64
今晚 18:48 后就是新一轮重置了
|
 |
987NJun 11
65
有点逆天
|
 |
0x0xJun 11
66
这评论区搞得 OP 都不敢回复了
|
 |
67
@KJH 以后写代码记得快速返回或者快速失败
|
 |
ArrowingJun 11
68
哈哈哈 OP 居然是老用户，吃了个惊
|
 |
win8enJun 11 via Android
69
你开车去旅游：
5 小时额度 = 油箱里的油 1 周额度 = 高速公路通行次数 现在情况是： 油箱里还有油（ 5 小时 99%） 这个月高速通行卡次数用完了（ 1 周额度耗尽） 结果： 车还能跑，但上不了高速。 |
 |
kfansupJun 11
70
你让我有点懵了
|
 |
72
 |
 |
73
哈哈哈，才看到，太搞笑了各位。
谢谢各位老哥，我以为是优先用每 5 小时的，用完 5 小时后开始用每周的 |
 |
deplivesJun 11
74
这个问题看的我一愣一愣的
|
 |
YangzJun 11 via iPhone
75
我也觉得这个展示界面有点问题诶，它不应该在没有余量的情况下显示余量啊！
|
 |
clmymjnJun 11
76
哈哈哈笑死
|
 |
chenluo0429Jun 11 via Android
77
@1OF7G 实际上当前的显示是非常合理的，本身的机制就是双滑动窗口，那么显示上自然也是双滑动窗口。你给的 demo 里面存在一个非常大的问题，5 小时窗口的余量和周窗口的余量到底谁多是无法确定的，两者比例压根不是定值，而是不对外公开的可变值。
|
 |
zsj1029Jun 11
78
明明是产品设计问题，各位自适应能力真强，喜欢自我怀疑
|
|
1OF7GJun 11
79
@chenluo0429 比例不是定值怎么理解？我今天用光一个 5 小时，周限额掉了 10%，明天再用光一个 5 小时，周限额可能掉 15% ？这不能吧？周限额与日限额不明说不代表没稳定比例啊。如果真没有，那当我没说。
|
 |
FeedmoJun 11
80
《我以为是优先用每 5 小时的，用完 5 小时后开始用每周的》谢谢让我笑了，不过没关系大家都有脑子“抽”的时候
|
|
chenluo0429Jun 11 via Android
81
@1OF7G 同账号一段时间内的比例应该是固定值，但是不同账号，不同时期绝对是有差异的。codex 的 5 小时窗口一个多月前就砍过一次了，并且每个账号可用的周限额度也是不一样的，上下可能有 10%左右的差距。准确值只有 openai 知道，你只能根据历史扣减数值进行估算
|
|
1OF7GJun 11
82
@chenluo0429 #81 任意账号&时刻 周限额与 session 限额关系是确定的就行，显示也只对当下负责。按你说法 openai 不做的阻碍只能是他们不想 [太直白] 的展示当下 session/周限额的比例关系。这个我无法反驳，但是对有心的用户来说随便用一下就能推测出来了，能藏的也有限。
|
 |
unusualcatJun 11
83
按道理说应该设置成，如果周额度没有了，那么每 5 小时刷新的那个额度应该也归零才对。
|
|
unusualcatJun 11
84
话说你是 Plus 用户吧，如果是做开发的话，这个额度肯定是不够用的。业余没事玩玩的话还凑合。
|
 |
coolmintJun 11
85
@unusualcat #83 周额度在 5 小时内重置了，5 小时额度肯定要保持不变，所以没必要归零
|
|
chenluo0429Jun 11 via Android
86
@1OF7G 推测不出来的，或者严格来说，推测的误差非常大。因为能拿到的只有百分比，只能通过百分比变动推测比例。但是这个比例变动下发的时间点是用户单次 prompt 发起后运行结束，能拿到的变更是非常粗糙的。比如 5 小时减少了 7%，但是周限依然是 100%；再跑一次 5 小时减少 2%，这时候周限就 99%了，拿不到精确变更点的。另一个问题也还是用量变更节点的问题，单次运行是可以超量白嫖的，5 小时最后一次任务跑完，可以超过 100%的用量。而周限这时候表现又不一样，最近更新之前是不扣减额外额度，更新之后是会继续扣减周限额度。再加上周限即将用完的时候，也可以运行长任务白嫖额度，所以根本无法算出精确值的。
|
|
unusualcatJun 11
87
@chenluo0429 是的，在最后一次任务的时候，它不会因为额度用尽而中断运行的任务，而是会把任务执行完毕。
|
 |
vislinsJun 12
88
|
Select Language