听说现在codex进行一个大型任务时，如果到了0%，不管是否做完都会直接停止。拜两个大聪明所赐。简言之就是用一个小型的harness，每次都插入wait for user input，这样就能近乎无限地让任务处于turn中而不结束turn。
我刚买了pro20x，还没到0%试过。佬友们有验证这个说法的吗？
如果是真的，那么真的和奥德赛很像了——
听说现在codex进行一个大型任务时，如果到了0%，不管是否做完都会直接停止。拜两个大聪明所赐。简言之就是用一个小型的harness，每次都插入wait for user input，这样就能近乎无限地让任务处于turn中而不结束turn。
我刚买了pro20x，还没到0%试过。佬友们有验证这个说法的吗？
12 个赞
真是纯傻逼，这波就事论事我真站open ai，本来人家留个口子给用户更好的体验（顺带也算点福利了）挺好个事儿，非要这样搞…
11 个赞
这俩人估计还在以为自己发现了什么了不得的技巧和秘密的，我只能说蠢得要命
还剩一丢丢额度的时候寻思给codex丢个大任务多白嫖点流量，有这种想法是人之常情，我也干。不过把这事儿搞成漏洞级别的硬薅然后还要四处广而告之就有点太弱智了…
1 个赞
这个就是薅羊毛吧，和那些薅羊毛的人也没区别
1 个赞
本来算一个小福利了，考虑用户体验，硬断太难受了
1 个赞
从工程角度看这个 harness 技巧本质是利用了交互式会话的生命周期语义：只要 turn 还挂着 wait for user input，配额检查就不触发，等于把单次任务的额度消耗摊到了多个交互点上。但有两个现实风险：一是这种模式特征太明显（大量空转的 pending turns），平台要检测很容易，真到封号层面就不值当了；二是长任务跨多个 turn 之后上下文压缩会累积失真，最后产出的质量未必比拆成几个带 checkpoint 的独立任务好。与其赌 0% 不停机，不如把大任务设计成阶段化交付，每段结束落盘状态，断了也能接着跑。
不奇怪，那个theo一直以来就是个2b，纯的。
1 个赞
没办法, 这种薅羊毛还要叫出来的人就是坏逼
偷着用, 别说, 不被大范围传播, 也还好. 非要显摆出来.
或者说, 就不该这么用. 大家都清楚, 用codex做工作难免会遇到0%但是还正在跑的情况. 这时候掐断就容易让任务出错, 不到里程碑硬停, 容易搞坏项目, 再续接起来就比较麻烦. 本来是OAI开发组好心, 给大家行个方便. 能薅羊毛人家自己不知道? 睁一只眼闭一只眼罢了. 现在好了, 官方彻底掐死.
毕竟花多少钱用多少token天经地义, 直接一刀切了.
1 个赞
https://linux.do/t/topic/2804060
发过了，实际上有限额限制的，补上了无限这个漏洞
目前可以给跑到50多刀
至于还能跑到800多刀还需要证实
怎么现在才死啊，原来一直都还能用的吗
前天试了一下，能多跑一点点，但是再跑就自己断了
codex我也跑0过，但我记得是跑到压缩就断了
这不就是从次数时代过度到token时代的滥用方式么，都变成token模式就没见到了，还得从cursor500说起…
1 个赞