尝试从历史角度出发，并建模讨论GPT额度与Tibo的重置问题

（额啊懒惰了没有做到一天一发，明明手里有好几篇存稿的，好讨厌排版和找图片）

最近几个月，Tibo 按过很多次重置键。^[14]

就在我刚刚说 Tibo 不会再继续重置之后，没过多久8 月 8 日，他又宣布为所有付费的 ChatGPT Work 和 Codex 用户重置使用限额，还答应星期一再来一次 “performative reset”。^[1]

消息传来，社区的反应有些诡异。从之前玩梗呼唤reset，到出现了一些别样的声音。有人当天刚好把额度跑完，觉得来得正是时候。有人自然重置才过去没多久，只用了 2% 或 3%。还有人的账户本来就是 100%，被 Tibo 从 100% 重置回了 100%。^[12]

牢骚肉眼可见地越来越多，几拨人讲的都是真话，慢慢也就变成了争论。

有人化用了朝三暮四的典故，精妙地引导思考重置的本质。

接着有人说，免费送额度还嫌弃，多少有点不识好歹。也有人拿着套餐价格、当前余额和下一次重置时间计算，认为这并不是单纯的赠送，甚至可能把原本快要到来的自然重置向后推。

这很interesting啊，声音一旦出现了反对，正反合的辩证法就将指引我们思考事物的本质了。

我是惯例喜欢站在反对派一边的，于是开始也按这个思路算过。把一周额度除以七，算出每天对应多少。再看自然重置日被推迟了几天，最后得出一个正数或者负数。

算到后来，我觉得问题不完全在算术。

额度它不是一个东西呀。对于我这种一天就能跑完一周pro 20x的额度人来说，我就完全不亏。对于没有那么大使用需求的人，他肯定就亏炸了。

OpenAI 官方对 Plus 的描述不是“每天使用若干次”，而是指出这是每周进行几次相对集中的工作。官方也明确提醒，实际消耗会随着模型、任务规模、上下文、推理强度、工具调用和缓存情况变化。因此，两个看起来相似的任务，额度消耗也可能完全不同。^[2][3]

两件事情合起来就产生了一个现实和思维的裂缝，多数人的实际体验侧方面验证了这一点，也就是没项目的时候，Codex 可以几天不开。事情一来，一个重构、一批材料或者一次交付，又可能让 Agent 连续运行很久。

所以，这件事如果只看余额，单纯只计算额度的得失，很容易陷进一个奇怪的假设里。好像用户每天都应该吃掉七分之一的额度，今天没吃就是今天亏了。

现实里的 AI 使用是没有这么整齐的。

我后来把问题换了一下。先不问一格额度值多少，改问重置前后，用户原本准备完成的工作还能不能完成。

同时，我也自然地朝着已经发生过的事情，也就是历史中去寻找一个原型，以能够将额度和重置放置到一个语境下进行探讨。

我找到了期权。期权是一个不错的入口，但也只是入口。

---

聊聊期权、备用授信和配给规则

现代标准化期权市场通常把 1973 年视为一个重要节点。那一年，芝加哥期权交易所开始提供标准化的上市期权交易。期权有了统一的期限、行权价格和交易规则，不再只是一对一谈出来的场外安排。^[4]

期权最基本的结构并不复杂。买方取得的是一项权利，而不是一项必须履行的义务。他可以在约定期限内买入或者卖出标的，也可以一直不行权。^[5]

这一点参照着对理解 AI 额度很有启发。

没有使用，不一定意味着浪费。今天没有适合交给 Codex 的任务，保留额度可能比随便找点事情把它消耗掉更合理。用户不可能等待模型性能上升，而是一个值得调用算力的任务。

不过，Codex 额度当然不是金融期权。

它没有可交易的标的物，没有明确的行权价格，不能转让。把剩余 70% 对应的价格塞进 Black—Scholes 公式，算出的价格也不够可信。

而且普通期权一般只讨论一次行权，AI 使用通常会发生很多次。

这时候，能源市场里的摆动期权反而更接近一点。

摆动期权的提出是源于“天然气和电力的需求不会每天保持同一个水平”这个常识。买方知道整个冬季大概需要多少，却不知道寒潮会在哪几天出现，也不知道工厂会在什么时候突然增产。

摆动合约因此允许持有人在一定时期内多次调整提取量，同时受到单日数量、总量和行使次数等限制。相关研究也把它归为多次行使、带有数量约束的合同。^[6]

这和 Codex 的使用方式有相似之处。

用户不知道任务什么时候来，可以在短期窗口和周限额之内多次调用。平台给了一定灵活性，又不能让任何账户无限占用共享算力。

但摆动期权仍然没有解释完。

还有一些用户长期不触顶，甚至整周都不使用。他们到底买到了什么呢？这部分用户我相信不会占据少数，也许只是出自对AI的追捧，或是图个新鲜，亦或是买了之后很显然有了别的事情去做。更可能的，是这些用户平时没有很多任务，却希望真正有活时可以立即使用。

我力求一个完备的模型去完整描述额度这件事，这样我们才能推进下去对这件事情本质的探寻。

于是我又找到了备用授信，它可以补上这一块。

美国银行业很早就发展出贷款承诺和循环授信。银行承诺在一定期限内准备好资金，企业真正需要时再提款。1975 年里士满联储回顾这类安排时提到，正式授信经常按照未使用部分收取承诺费。即使客户最后没有提款，银行仍可能保留这笔费用，因为它在整个期限内都要保持放款准备。^[7]

企业买了一亿元备用授信，全年没有动用，不能说它损失了一亿元。它买到的是流动性突然紧张时还有钱可借，不必等到出事以后临时找银行。

AI 订阅里的低频用户也可能是这样。

高余额不一定代表这项权利对他不重要，有时恰恰说明他把调用能力留在了后面。

最后还有配给这一层。

为什么呢？是因为 OpenAI 明确区分 rate-limit reset 和 usage credit。重置不会产生现金余额、API 余额或者可以转让的信用，这一点我们在思考额度以及重置时已经有考虑到了。与此同时，Codex 仍然受到五小时共享窗口和额外周限额约束。^[2][8]

这说明额度并不是平台已经交付给用户的一桶 Token。它同时是一套共享算力的准入规则。用户可以在规则之内调用，平台则用窗口和总量控制负载。

截止目前，大概我们可以将额度、重置这件事情的模型建设完全了。

期权能说明择时为什么有价值。备用授信提醒我们，没有使用不等于没有获得服务。摆动合约比较接近多次、突发的调用。配给规则则解释了平台为什么要设置窗口和上限。

在这个视角下，如果要定义额度究竟是什么，就可以将 AI 额度理解成一份按任务触发的服务能力。

用户先付订阅费，在一定时期内取得有限的调用空间。任务什么时候出现，由用户的工作决定。什么时候补充、最多使用多少，则由平台的规则决定。

这比一桶每天蒸发七分之一的 Token 更接近实际情况。

---

期权视角下的重置

简单用数学建模用户未来的任务，

即假设第 j 个任务可以写成：

这里的 t_j 是任务出现的时间，c_j 是它需要消耗的额度，d_j 是截止时间，v_j 是完成任务给用户带来的价值。

这个价值不一定是收入，也可以是省下的时间、按时交付、修复生产故障，或者只是把一个个人项目做完，whatever，就先这样。

基于此，把用户未来遇到的全部任务放在一起，记作 \omega。

而某一套额度规则 R 会决定哪些任务组合能够完成，文字工作和编程工作很显然不能是一套工作流，还有模型搭配使用等复杂场景，在这里我们也简化地把所有可行的组合记作：

用户在这套规则下能够取得的最大任务价值，可以写成：

其中 x_j=1 表示这个任务得到完成，x_j=0 表示没有完成。

这条式子不是为了给每个用户算赔偿。它只是把分析对象换了一下。

以前大家盯着余额，问还剩多少。

现在问的是，在当前额度日历下，哪些值得做的事情还做得成。

如果今天没有任务，额度的即时边际价值可能很低。项目做到一半、额度突然成为瓶颈时，同样一格额度的价值又会很高。月费除以四、再除以七，算不出这种变化。

接下来把重置放进去。

设一个完整周期的额度为 Q，用户目前还剩 q。原来的下一次自然重置时间是 r，Tibo 重置以后，新的补充时间变成 r'。

重置前的状态是：

为了把两个效果分开，我们再设一个不存在于现实中的中间状态。假设平台只把当前额度补满，却不改变原来的重置日：

实际 hard reset 后的状态则是：

这样，一次重置产生的总变化就可以拆成：

第一对方括号里，重置日没有改变，只是当前额度从 q 补到了 Q。

这是补量。

用户已经归零，补量接近一个完整周期。还剩 80%，实际只补了此前使用的 20%。本来就是 100%，这一部分等于零。

第二对方括号里，当前额度同样是完整的 Q，变化的只有下一次补充时间，从 r 换成了 r'。

这是换期。

补量一般不会让用户变差。换期则不一定，它要看任务落在什么地方。

重温一下， OpenAI 对 banked reset 的官方说明很清楚。用户兑换后，五小时窗口和周窗口会重新开始，下一次周重置大约移动到兑换后的七天。对于平台直接进行的全局重置，OpenAI Support 曾解释，新的七天窗口还可能从用户下一次使用 Codex 时开始，因此界面上的日期会继续移动；Support 也承认，目前的显示方式不方便用户规划。另一次回应则把全局重置描述为一份新的 allocation 替换原有周期及其剩余余额。^[3][9][10]

这就解释了为什么“恢复到 100%”容易引起误会。

它把补量和换期合在了一次操作里。

假设用户原本还有 0.8Q，两天后自然重置。今天被重置到 Q，下一次补充改到七天以后。

界面告诉他的是，从 80% 回到了 100%。

模型告诉我们的则是，他得到了 0.2Q 的当前补量，同时原来的两天后重置被换成了另一张日历。前一项是正数，后一项需要看后面的任务。

举个简单例子。

用户目前有完整额度 Q，原本第 3 天自然重置。Tibo 今天进行 hard reset，新的重置时间变成第 7 天。每个大型任务需要 0.8Q。

第一条任务路径里，任务 A 在第 2 天出现，任务 B 在第 4 天出现。

旧日历下，第 2 天完成 A，第 3 天自然重置，第 4 天继续完成 B。

新日历下，第 2 天完成 A 后只剩 0.2Q，第 4 天还没有重置，B 做不了。

再换一条路径。

任务 A 在第 6 天出现，任务 B 在第 8 天出现。

旧日历在第 3 天补过一次，下一次要到第 10 天。第 6 天完成 A 以后，第 8 天无法完成 B。

新日历在第 7 天补充，两个任务反而都能做完。

同一次重置，在两条路径里得出了相反结果。

不是因为模型前后矛盾，而是额度日历本来就会和任务时间发生配合。

Tibo 只是把原来的配合关系改掉了。

如果要严格地把某项活动称作单纯赠送，可以给它设一个条件。

设旧规则允许完成的任务组合为 \mathcal{F}_{\mathrm{old}}(\omega)，新规则允许完成的组合为 \mathcal{F}_{\mathrm{new}}(\omega)。

纯粹增加用户选择，至少应当满足：

不管任务怎样到来，旧规则下能完成的事情都还能够完成，新规则只是多给了一些选择。

保留原重置日，另外增加一个奖励额度池，基本符合这个条件。

发放一枚 banked reset，也比较接近。用户不兑换时，原有日历继续运行。只有在当前额度、任务和时间都合适时，他才主动换期。官方机制也确实把 banked reset 设计为用户自行兑换，而不是自动使用。^[3][11]

hard reset 就没有这个选择。

它打开了一些新路径，也会关掉一些旧路径。不能据此说所有用户都受损，但它确实不是对所有任务路径都只做加法。

---

四种情况

确定了分析对象以后，社区里的各种说法其实可以放进一张很普通的表里。

选定一个用户确实打算完成的任务组合，然后问：

旧日历下能不能完成？

新日历下能不能完成？

每个问题只有能和不能两种答案，两两组合后就是四种情况。

第一种常见于真正的轻度用户。

他没有接近上限，或者任务规模很小。星期三重置还是星期日重置，对他想做的事情没有影响。此时不能只因为日历推迟了四天，就说他损失了七分之四。

第二种是 hard reset 最容易得到感谢的情况，也就是我这种。

用户已经触顶，手上的工作却没有结束。旧规则要求他等待或者付费购买 credits，Tibo 一按，任务可以继续。8 月的重置以后，社区里就有人表示自己当天刚好耗尽，因此这一轮来得很及时。^[12]

第三种才是争议里比较有力的损失情形。

用户不是抽象地“少了几天”，而是按照原重置日安排了两段工作。旧日历下两段都能完成，新日历下第二段被卡住。

第四种多见于需求远超套餐容量的用户。

不论重不重置，任务都做不完。hard reset 可能多给几个小时，但最后仍然需要购买 credits、切换 API、升级套餐或者换服务。

这四种情况之所以有用，不是因为表格看起来很完整，而是它避免了两种过度概括。

从 100% 回到 100%，不代表一定没有影响，因为后面的日历变了。

从 100% 回到 100%，也不代表一定发生损失，因为用户可能永远不会靠近额度边界。

要判断结果，还是得把任务放进去。

---

用户状态分类

用户的状态也是可以分的。初步在遇到这个问题时，我是倾向把我自己分成勤快的和懒的时候，对应勤快用户和懒用户。

每天把额度跑满的是勤快用户，一周只开两次的是懒用户，也就对应之前直接将额度除以日期的计算方法。

这个分类暗中假定使用得越多越好，额度利用率越高越划算，但跑一些无意义的工作空耗token又没有什么意思，又不是报复OpenAI（等它变畜了再这么干好了）。

基于我此前的判断，在这里还是以工作怎样出现为标准。

基于之前的分析，大概能分出项目型用户、持续高频使用用户、自动化使用用户三种用户类型。

项目型用户通常几天不用，交付前集中运行。他们对重置时间最敏感。一个重置点刚好夹在两批任务之间，和提前几天被覆盖，结果可能完全不同。

持续高频使用用户经常接近上限，补量对他们通常更有价值。

再往上是自动化使用。只要获知重置消息，用户就能让 Agent 持续运行，迅速把当前额度消耗掉，再接上新的一轮。这类用户最容易把活动的名义额度兑现出来。

在社区的讨论中，用户状态也可以就购买的套餐类型进行状态的分类。实际上我的这套方案是可以囊括进去的，以这套计算方法来看，套餐只是在这些使用路径外面又加了一层边界。

OpenAI 目前将个人套餐分为 Free、Go、Plus 和 Pro。Free 用于快速任务，Go 每月 8 美元，面向轻量任务；Plus 每月 20 美元；Pro 从每月 100 美元起，提供 Plus 的 5 倍或 20 倍使用容量。^[2]

Tibo 这次宣布的是所有付费用户，因此 Free 并不在活动范围内。^[1]

以 Go 和 Plus 为例，这种更容易出现突发使用。尤其 Plus 官方本来就把场景写成每周几次集中工作，而不是每天固定消费。这样的用户可能在一次 hard reset 中获益，也可能正好围绕原重置日安排项目。^[2]

Pro 5×和 20×不能直接按倍数计算。

更大的额度会降低普通任务触顶的概率。一个从未接近上限的 20×用户，换期以后可能什么都没发生。

但真正能耗尽 20×的用户，背后又可能是大型代码库、长时间自动化或者商业交付。一旦额度真的卡住，任务代价可能比普通用户高得多。

可以把这种关系近似写成：

Pro 套餐提高以后，前一个概率往往下降。

专业任务变重以后，后一个数值又可能上升。

这两个方向同时存在，所以 20×的容量不意味着每次重置的收益或损失也是 Plus 的 20 倍。

套餐决定边界画在哪里，任务路径决定用户会不会撞上这条边界。

有人会提到中转站的情况，在之前社区的讨论中经常出现。我觉得中转站也可以基于这个关系进行拟合，毕竟中转站随时可能烂在手里的 plus（即站长手中的号没用额度就直接死了）迫使他们必须要高频持续使用，大概是属于高频使用用户的类型的。当然，这不算是正常的用户，其中还有复杂的供应链问题，就不作进一步展开了。

---

OpenAI 这边的账

有人算过平台这方面的问题吗？基于上述的模型顺手可以进行，只是计算方法又不一样。

为了便于比较，先把不同套餐的额度换算成同一种容量单位。

设第 i 个用户的完整周期额度为 Q_i，重置前还剩 q_i。

如果宣传时把每个账户都按照“恢复一个完整周期”来计算，活动的名义规模是：

这个数字会很大。所有付费账户都计入，Pro 还按照更高容量放大。

但重置当下真正补回的空间只有：

用户已经归零，补回 Q_i。

还剩 80%，补回 0.2Q_i。

原本就是 100%，这一项为零。

即使系统补回了容量，也不代表用户一定会使用。于是还需要比较两个反事实。

没有重置时，这个人本来会运行多少任务？

有了重置以后，他实际多运行了多少？

在一个观察期 H 内，把这部分额外使用记作：

方括号右下角的加号表示只统计因为重置而增加的使用，不把正常情况下本来就会发生的调用算进去。

如果一定要给活动计算一个容量兑现率，可以写成：

这个比例会随着观察期、用户余额分布和任务到达情况变化。外部没有 OpenAI 的账户数据，算不出具体数字。

但结构是清楚的。

“全体付费用户恢复 100%”是活动覆盖范围。

此前实际使用掉多少，决定了当下补回多少。

补回以后又有多少被真正使用，才接近平台承担的新增推理负担。

Tibo 早先说过，不应当随便重置 Codex 限额，因为重置会花钱。这在总体上完全可能成立。已经归零的重用户恢复以后继续运行，会给平台带来真实成本。^[13]

但活动会花钱，不等于每个用户都收到了一整个周期的新增服务。

一个从 100% 回到 100%、之后仍然没有任务的账户，几乎不会因为这次重置增加计算消耗。

一个从 0% 回到 100%、随后继续跑满的账户，则可能兑现接近完整的一轮。

所以，活动覆盖所有人，成本却不会平均落在所有人身上。它主要落在已经触顶、能够在新窗口里继续工作的那批用户身上。

这也是社区里有人提前烧额度的原因。

如果知道周一会重置，当前额度的使用门槛就会下降。本来没那么着急的任务，也可以先跑起来。越早看到 Tibo 的帖子、越容易连续运行 Agent，越能取得这次活动的实际价值。另一边，几天没开 Codex 的用户醒来以后，只看到自己的 100% 又变成了 100%。^[12]

这大概只能说 Tibo 在搞一种很新很超前的营销方式，却像之前社区的一种声音所表述的那样，认为 OpenAI 有意用低频账户压低促销成本。

没有内部数据，无法从结果直接推断动机。我早就说过，OpenAI内部的精算师还是会更聪明一点的。

因此，我认为能够确定的只有三件事。

活动的传播规模、账户即时增加的容量、平台最终承担的推理成本，不是同一个数字。

把三者混在一起，就会出现“每名用户都收到了价值几十美元 Token”这种听起来很精确、实际没有根据的计算。

---

多次重置

现在我们将单次重置推进到多次重置的情形。

在此时另一个问题出现，即用户需要知道下一次什么时候能工作。

OpenAI Support 曾说明，全局重置后，新的七天窗口可能从用户下一次使用 Codex 时开始，并承认现有显示方式不容易规划。社区里有人提议固定每周重置日，甚至表示自己已经用表格跟踪 Codex 和 Claude Code 的用量。也有人抱怨，不应当为了弄清楚付费产品的日历，一直盯着产品负责人的 X。^[1][10][15]

Max Woolf 统计，7 月 9 日至 17 日，OpenAI 进行了六次直接重置，期间还发放过 banked reset。他为了管理使用量，会持续打开额度页面、设置提醒，也开始考虑是不是应该在下一次重置以前把额度先用掉。^[14]

这种成本不会显示在余额里，所以，可以在前面的任务价值模型上再减去两笔：

CE 可以理解成用户实际感受到的服务价值。

\mathbb{E}[W] 是平均能够完成多少有价值的任务。

\operatorname{Var}(W) 是结果的不确定程度，\rho 表示用户有多在意这种不确定。

K 则是查看额度、关注公告、调整项目和临时迁移工作产生的成本。

在这里，我学着把可预测性放进模型中。

即使两套制度平均提供的额度一样，只要其中一套经常改变时间，用户就要付出更多精力安排工作。对偶尔玩一下的人，这可能只是小麻烦。对已经把 Codex 接进生产流程的人，日历本身就是工具的一部分。

我想到了一句话**“订阅制是一种傲慢”，从这个角度出发，可以补上下半句“额度制是一种诅咒”**。

界面上的百分比会不断提醒用户，某种东西正在减少、到期或者即将被下一次重置覆盖。用户慢慢不再只考虑任务有没有价值，而被逼迫着开始考虑额度能不能用完。

8 月的社区讨论里，就有开发者直接问，既然几天后还会重置，难道自己应该在今天运行一批并不需要的项目吗？^[1]

这大概就是为什么社区讨论一开始会直接奔着简单的除法去。

继续回到历史中，这类行为并不新鲜。

一项研究美国联邦采购的论文发现，政府部门在财政年度最后一周的支出是其他周平均水平的 4.9 倍，年末启动的 IT 项目质量也显著更低。预算即将失效以后，原本不值得做的项目更容易被赶在期限前花掉。^[16]

政府预算当然不是 AI 额度，两个场景的规模也完全不同。

相似之处在于，只要资源采用 use it or lose it 的形式，使用者就会被鼓励提高消耗，而不一定是提高产出。

平台看到的 Token 使用量增加了，用户真正完成的有价值工作未必同步增加。

订阅原本让人不用每做一件事都看价格，额度又给订阅装回了一块反向计价器。传统计价器越用数字越大，AI 额度越用数字越小。再配合不定期的全员重置，用户很容易一边担心额度不够，一边又怕额度用不完。

这情绪属实是拿捏的很到位了。

---

最后说一下违约

最后我想回应一下违约的说法。

直接认定 hard reset 构成违约，我觉得还是不太妥当。

OpenAI 没有把套餐额度承诺为某个固定数量的 Token。官方反复说明，我也想反复说明一下，实际消耗受到模型、上下文、推理强度和工具调用影响。rate-limit reset 也不属于现金或者可转让的 credit。^[2][3][8]

所以，把一周额度除以七，再主张平台拿走了四天对应的 Token，根基是不牢靠的，用户买到的又不是每天固定交付的一笔储值资产。

所以在损失论证上，我比较坚持我的这套任务路径的分析方法比较有力。

旧日历下，用户原本有一套可以执行的工作安排。

新日历下，这套安排变得不可行。

用户因此购买了额外 credits、切换服务、推迟交付，或者失去了订阅期内本来能够取得的一次自然重置。

社区里已经有人提供过类似时间线。

一名用户称，7 月 14 日账户还剩 77%，原定 7 月 19 日重置。7 月 15 日被恢复到 100% 后，下一次重置移动到 7 月 21 日。由于订阅在 8 月 10 日结束，按照他的计算，原本落在 8 月 9 日的最后一次重置被推到了 8 月 11 日，越过订阅期。该帖子属于用户陈述，不能代替账户后台记录，但它展示了一条可以验证的损失路径。^[17]

这里不需要假设每天应得七分之一。

只要确认旧日期、新日期和订阅结束日，就能判断一轮原本位于付费期内的使用窗口是否被推出去了。

当然，主张违约在我这套分析下也不是不成立，只是还要继续看购买页面如何描述额度、用户是否确实有使用需求、平台是否作过通知，以及损失能否证明。

至于要追究法律责任…额，我是觉得没那个必要了…没损失就没必要追究嘛。

不过你要问有没有更好的解决方法，这个我是同意有的，也就是如果是补偿，可以保留原自然重置日，把额外容量单独放进奖励池。如果一定要重新启动七天窗口，可以发放 banked reset，由用户自己选择什么时候使用。

至少在触发以前，界面可以把当前余额是多少，这次实际补回多少，原重置日是哪一天，使用以后新重置日是哪一天。

比如用户目前还剩 83%，原定星期三重置。系统可以直接告诉他，这次操作会补回 17%，并把下一次重置移到下周一。用户愿意就立即使用，不愿意就存起来。

做到这一步，社区大概也不需要再请出期权、备用授信、摆动合约和一长串公式。

下次 Tibo 再把额度按回 100%，大家至少会知道，这个 100% 是加在原来的日历上，还是顺手把日历也换了。

开发周期最讨厌被人动来动去的了。

除另有说明外，本文文字及作者自制图表采用 CC BY-SA 4.0 国际许可协议发布。

转载、改编及商业使用应当适当署名、注明来源和修改情况，改编成果应采用相同或兼容许可。

文中第三方图片、商标、引文及另行标注的材料不在本许可范围内。

文章使用AI辅助生成图片并进行格式调整，保证全文内容为我本人方寒真人写作。

---

参考文献

[1] OpenAI Developer Community：《Codex rate limits reset for all paid plans on August 9 and again on Monday》，2026 年 8 月 8 日起

[2] OpenAI：《Pricing | ChatGPT Learn》，访问日期：2026 年 8 月 13 日

[3] OpenAI Help Center：《Using Codex with your ChatGPT plan》，访问日期：2026 年 8 月 13 日。

[4] Cboe：《The Creation of Listed Options at Cboe》，2024 年 3 月 1 日

[5] FINRA：《Options》，访问日期：2026 年 8 月 13 日

[6] Patrick Jaillet、Ehud I. Ronn、Stathis Tompaidis：《Valuation of Commodity-Based Swing Options》，2003 年 12 月获 Management Science 接受发表

[7] Bruce J. Summers：《Loan Commitments to Business in United States Banking History》，Federal Reserve Bank of Richmond, Economic Review，1975 年 9—10 月

[8] OpenAI Help Center：《ChatGPT Desktop Referral Promotions》，访问日期：2026 年 8 月 13 日

[9] OpenAI Developer Community：《Questions about an unexpected Codex usage reset and new quota period》，2026 年 6 月 4 日起

[10] OpenAI Developer Community：《Weekly limits reset date suddenly changed》，2025 年 10 月 31 日起；文中引用 OpenAI Support 于 2026 年 7 月的解释

[11] OpenAI Developer Community：《Flexible Rate Limit Resets for Codex and a method to get a Reset》，2026 年 6 月 12 日起

[12] Reddit r/codex：《Tibo just reset》，2026 年 8 月

[13] OpenAI Developer Community：《Codex Rate limits reset for all paid plans April 28, 2026》，2026 年 4 月 28 日

[14] Max Woolf：《What’s the deal with all the random weekly quota resets for agents lately?》，2026 年 7 月 18 日

[15] OpenAI Developer Community：《RANDOM Codex weekly quota reset still happening. WHY?!?》，2026 年 6 月 29 日起

[16] Jeffrey B. Liebman、Neale Mahoney：《Do Expiring Budgets Lead to Wasteful Year-End Spending? Evidence from Federal Procurement》，American Economic Review，Vol. 107, No. 11，2017 年 11 月，第 3510—3549 页

[17] OpenAI Developer Community，Dragonrin：《The “Free” Non-Banked Codex Reset May Have Reduced My Total Usage》，2026 年 7 月 14 日起