额度的对错，在于烧掉它归谁

thsottiaux 发了条简短的恢复公告，三句话：我们恢复运行了；所有付费用户的用量限额将重置（Codex 与 ChatGPT 工作区一并）；对这次短暂的中断道歉。他还补了个耐人寻味的括号——"是的，我们有一个特别的备用 Codex，在系统宕机时帮我们自己"。

"重置限额"这个补偿动作，是今晚订阅这条线里少见的正面案例。前一天刚发过那篇"不是卖得贵、是卖的无法验证"——用户愤怒的核心从来不是额度紧，是紧得不明不白、且没人负责；这次反过来：故障造成额度被白白烧掉，团队直接整单豁免。

两个故事放在同一天看，结论就很清楚了：额度本身没有对错，对错在于烧掉它的原因归谁——归系统故障就该赔，归你自己用多了就该认；把这笔账分清楚，订阅的信任才立得住。

"备用 Codex"这个彩蛋更值得琢磨。作为做 Coding agent 的团队，他们在自己的生产事故里塞了一个自用的 agent 当应急预案——吃自己的狗粮吃到救火层，这大概是"用 agent 干没人爱干的活"最硬核的一次官方示范：半夜三更处理故障的值班活，正好落在"该交给机器"的清单上。顺带也说明了他们对自己的产品足够信——宕机时拿来救场的，就是平时卖给你的那个。

从流程上，这条公告还传递了一个不易察觉的信号：恢复、补偿、致歉三件事一次性给齐，没有挤牙膏式的分批发通知。这与今晚"可兑现的透明"那篇的纪律暗合——承诺要小而全，比大而缺更得人心：用户原谅一次故障，很难原谅一次吞吞吐吐的故障。

给同样在跑服务的人一句落地的：把"故障后的第一份公告"模板现在就写好——三句话：恢复了没有、受影响的部分怎么赔、原因什么时候讲。三句齐了再发；等拼齐再发往往错过窗口，而第一时间把补偿说出口的团队，事后的骂声总会小一半。