Codex109天重置23次,明天还要再送一次

简介: Codex近109天完成23次额度重置,7月14日将迎来第24次。Tibo高频响应用户反馈:优化GPT-5.6高消耗问题、补发失效福利、调整重置时间——形成“反馈→回应→修复→补偿”正向闭环,彰显以用户为中心的产品哲学。(239字)

Image

这几天用Codex,额度刚见底,Tibo(Codex的核心开发者和负责人)又把它按回100%,你敢信?几乎是每天来一次!

很多次老金我还没想好这次Reset拿来干什么,下一次已经在路上了。

我把Tibo从3月底到现在的公开记录按北京时间排了一遍。109天里,Codex已经完成23次可核验的额度重置。明天,也就是7月14日,还会再发一次Banked Reset(重置券),届时就是第24次。

不过老金想说的是OpenAI最近处理用户体验的方式,简直是深得我心。

我说的不是它给福利,而是它对于问题处理的态度和积极性。

用户说额度掉得太快,他们查原因。发现GPT-5.6 Sol的上下文、推理预算和多Agent带来了额外消耗,他们就回滚和优化。重置券没有到账,他们补发。福利时间选得不好,用户刚提意见,Tibo第二天又送一次。

用户说出问题,Tibo公开回应,团队完成修复,额度随后补回来。

一个完美的正向产品闭环!

用户反馈 → 公开回应 → 修复问题 → 重置补偿 → 体验恢复。

作为公开回应者,Tibo也被用户拥戴成了这样,看图。

Image

先把23次怎么算的说清楚

正常的5小时窗口恢复、每周额度恢复和邀请好友奖励都不算,3月27日至7月13日共109天,Codex完成了23次可核验的重置动作,其中19次是直接重置,4次是Banked Reset。

这是我根据公开记录做的统计。

3月底到4月底一共6次。插件上线、300万周活跃用户、Codex一周年、400万用户和GPT-5.5体验,都成了按下Reset的理由。那时的重置主要用来庆祝产品更新和用户增长。

5月又来了4次。除了增长节点,5月24日那次和长会话压缩中的缓存命中率下降有关。Codex重复处理了本可以复用的内容,修复后官方用重置补偿用户。

6月最密集,共8次。可靠性事故、Banked Reset上线、异常用量调查,让Reset逐渐多了一层含义。哪里影响了体验,官方修完以后就把额度补回来。

7月截至13日又有5次。GPT-5.6 Sol上线后两次,达到600万活跃用户后一次,另有约50万名用户因为Banked Reset未正确生效而获得补发。Tibo还预告,7月14日达到700万活跃用户后,会给ChatGPT Work和Codex用户再发一次Banked Reset。

Image

所以,23次重置既是福利记录,也是一份产品体验改进记录。

用户嫌福利时间不好,第二天再送一次

最能说明OpenAI听劝的,是4月庆祝300万用户时的一件小事。

当时Codex刚完成一次额度重置,用户很快提出,重置时间和上一周几乎重合。很多人的旧额度还没用完,新福利就覆盖上来了,实际获得感不强。

Tibo没有让这条反馈停在评论区。他直接承认时间选得不够好,然后宣布第二天再重置一次。

用户提意见,负责人当天回应,补偿第二天到账。

这件事没有多复杂,却很容易让用户记住。大家先看到Tibo回应,第二天又收到重置,意见真的改变了结果。

明天要发的第24次也延续了这个,它既庆祝700万用户,也是对最近用量波动和Banked Reset问题的一次体验补偿。

GPT-5.6为什么突然更费额度

4月2日以后,Codex大部分套餐开始按Token用量计算Credits。输入Token、缓存输入Token和输出Token都会影响消耗。

这会带来一个很容易误判的场景。你看到的是自己只发了一条指令,系统实际处理的可能是整个项目上下文、此前的工具结果、多个Agent的工作和审查过程。

Image

GPT-5.6 Sol上线后,最近额外消耗主要来自几处变化。

上下文上限从272K提高到372K。更大的上下文能装下更多资料,也让工具调用之间搬运和读取的缓存内容增加。用户开始反馈额度下降太快后,团队已经把上限回滚到272K。

Image

底层推理预算也做过实验。用户没有改变任务,模型背后的思考强度却可能变了。相关实验现在已经撤回。

High和xHigh下的多Agent使用量高于预期,Auto Review一度过于积极,辅助Agent和后台建议做了太多工作。这些流程也已经被调整。

Tibo在7月13日的说明里表示,这轮修改预计能让用量降低约10%。这不代表每个人都会固定省下10%,至少说明团队已经找到主要问题,并把几项最影响体验的改动回滚或优化了。

所以,最近额度掉得快,并不全是用户突然用得更猛。GPT-5.6上线后的几项系统调整确实增加了消耗,OpenAI收到反馈后也确实动手处理了。

如果对你有帮助,记得关注一波~

重置福利为什么让人有获得感

单看一次Reset,它只是把额度恢复。连续看109天,感受完全不同。

产品更新有福利,用户增长有福利,Bug影响使用有补偿,补偿按钮自己出Bug还会再补一次。加上可以留到真正需要时再用的Banked Reset,用户至少不用独自承担产品快速迭代带来的全部试错成本。

这也是Tibo频繁站在前台的价值。大家不用对着一个沉默的公司账号猜测,可以直接看到哪里出了问题、团队正在查什么、今天改了什么、明天准备补什么。

福利当然会带来讨论,也会吸引更多人尝试Codex。对已经在用的人来说,更重要的是用户体验有人管。

问题出现后,官方没有只说正在调查。他们会解释、回滚、修复,再用真实额度补偿。用户自然更愿意继续用,也更愿意把产品推荐给别人。

现在怎么用,才不会莫名其妙烧完

GPT-5.6的几项高消耗改动已经处理,但日常使用仍有几个地方值得注意。

日常修改先用5.6的Terra中等推理强度,复杂重构再开High、xHigh或Max。发现一条指令掉得特别快时,先看是否启动了多Agent、Auto Review或自动化。

长会话也别无限续。需求确认、执行、验收各自收口,完成一段就留一份简短交接,让下一段只带真正需要的上下文。

如果额度突然异常下降,至少记下套餐、模型、推理强度、任务前后额度、多Agent或Auto Review状态、运行时间和失败重试。这几项比一句额度掉得很快更容易帮官方定位问题。

Banked Reset先确认到账再使用。明天的新一轮发放完成后,也建议看一眼账户里的实际状态,避免重复点击。

第24次重置之前,我的判断

把这109天的记录翻完,23次福利很醒目。更深的感受是,他们愿意让用户看到产品怎么改。

用户说重置时间不好,第二天再送一次。用户说GPT-5.6消耗太快,团队查上下文、推理预算和多Agent,随后回滚和优化。50万人的Banked Reset没生效,官方确认后补发。

这些动作都落在同一条路径上。听到反馈,承认问题,马上修改,再把用户损失补回来。

明天第24次Reset到账时,它当然是一份真金白银的福利。它也再次说明,Codex正在快速迭代,而OpenAI愿意把用户体验放在这轮迭代里一起处理。

对普通用户来说,这比单纯看到一个新版本号更有安全感。

这也是老金作为产品人一直所提倡的,产品为王以及用户为王的观点。

用户反馈 → 公开回应 → 修复问题 → 重置补偿 → 体验恢复。

这个正向闭环,能带来更高的用户留存,以及产品迭代。


飞书****开源知识库(实时更新 交流群):
https://tffyvtlai4.feishu.cn/wiki/OhQ8wqntFihcI1kWVDlcNdpznFf


每次我都想提醒一下,这不是凡尔赛,是希望有想法的人勇敢冲。
我不会代码,我英语也不好,但是我做出来了很多东西。
我真心希望能影响更多的人来尝试新的技巧,迎接新的时代。

谢谢你读我的文章。
如果觉得不错,随手点个赞、在看、转发三连吧🙂
如果想第一时间收到推送,也可以给我个星标⭐~谢谢你看我的文章。

相关文章
|
8月前
|
人工智能 前端开发 算法
大厂CIO独家分享:AI如何重塑开发者未来十年
在 AI 时代,若你还在紧盯代码量、执着于全栈工程师的招聘,或者仅凭技术贡献率来评判价值,执着于业务提效的比例而忽略产研价值,你很可能已经被所谓的“常识”困住了脚步。
5143 91
大厂CIO独家分享:AI如何重塑开发者未来十年
|
3天前
|
存储 人工智能 JSON
Qwen 本地部署搭配 ComfyUI 生成 AI 漫剧完整实操指南(小白零基础可落地,零成本无限生成+角色一致性天花板)
2026全网最优本地漫剧流水线:零成本、离线运行、角色统一、低配(8G显卡)可跑。融合Qwen本地大模型+ComfyUI双引擎,实现剧本生成→分镜绘图→动态成片全自动,隐私安全、无审核限流,新手30分钟上手,日更无忧。(239字)
|
3天前
|
运维 负载均衡 数据可视化
手把手教你在阿里云上百炼调用DeepSeek-V4-Pro(Chatbox图形化界面)
本文介绍如何通过阿里云百炼平台调用DeepSeek-V4开源模型。用户只需开通百炼、获取API Key,下载Chatbox客户端并配置deepseek-v4-pro模型,即可在图形界面中零命令行操作完成调用。平台提供免运维、自动扩缩容与高稳定API服务,并赠送新人免费额度。在阿里云百炼官网:https://t.aliyun.com/U/fPVHqY 免费领取千万Tokens
|
1天前
|
人工智能 并行计算 前端开发
绕过摩尔定律的时钟独裁
本文提出一种摒弃全局时钟的异步类脑AI芯片架构,以“握手协议”替代同步节拍,实现按需激活、分层异构(成熟工艺控路+尖端工艺运算)与稳态零功耗,兼顾高能效、强容错与可扩展性,为突破摩尔定律瓶颈提供新路径。(239字)
|
16小时前
|
存储 Web App开发 缓存
从环境异常率看多账号浏览器:指纹、网络、存储如何共同决定账号安全
稳定性不是某个神秘参数,而是指纹一致性、网络隔离、存储边界、行为自然度与跨维度校验共同作用的产物。
|
17小时前
|
缓存 人工智能 NoSQL
两年,1444 次提交,我给自己撸了一套 .NET10 模块化框架(XiHan.Framework)
XiHan.Framework 是一个基于 .NET 10 的轻量级、模块化后端框架,强调“原生优先、完全可控”。它通过拓扑排序模块加载、动态 API 自动生成、声明式事务/缓存/多租户等能力,大幅减少胶水代码与重复配置。已真实应用于中后台系统,开源可学、可改、可信赖。
51 3
|
18小时前
|
人工智能 C++
GEO讲师王耀恒:我为什么不看好GEO运营外包模式?
本文深度剖析GEO运营外包模式的三大根本矛盾:批量复制 vs 定制深耕、外部视角 vs 内部认知、交付数量 vs 竞争结果,并指出其核心症结——AI推荐只青睐独家知识,而外包难以生产不可替代的一手洞察。强调“有限外包”原则:体力活可委托,脑力活必须自主。(239字)
|
17小时前
|
弹性计算 运维 网络协议
阿里云国际站代理商:ECS安装Docker后容器无法访问外网?转发与DNS排查全攻略
不少开发者在阿里云ECS上部署Docker后,都会碰到一个让人摸不着头脑的场景:宿主机yum或apt更新丝滑流畅,容器内却curl、wget超时,外网请求像掉进了黑洞。这类问题通常不是云平台安全组直接导致的,而是宿主机内核转发、iptables规则或容器DNS解析在捣乱。要理清脉络,就得回到「阿里云ECS Docker容器外网访问故障排查」的核心逻辑,把网络路径从头拆一遍。
|
15小时前
|
弹性计算 小程序 关系型数据库
一次真实录屏:我只说每月别超过 200 块,小程序后端就搭好了
iac-code 通过自然语言交互,自动规划、创建并管理符合预算的小程序后端云资源。本文结合真实录屏,展示它如何准备多套方案、给出架构与费用、在创建前等待确认,并在 RDS 规格下线后自动处理、继续部署,大幅降低阿里云的使用门槛。
一次真实录屏:我只说每月别超过 200 块,小程序后端就搭好了