关于Any 429的新发现！重开一个新对话就能正常调用

都是随机的，只是你这一次挤进去了那个账号所以没有429.

没有啥规则吧，倒是要求节点干净好像

我一直怀疑any用的是令牌桶类似的算法，因为claude我基本都是挂在那retrying，然后直到retrying成功，最近大概是10-20分钟。之后保持请求基本可以持续很长一段时间 ^-^ 搁这里抢线程呢

因为是旧会话之前的上下文太大，我用any 的codex就经常显示请求太大

可以强制压缩一下对话，就可以继续了

根据我的使用体感，后端大概率是有一套排队机制的，根据请求的内容长度和质量（maybe）等等因素决定排队顺序

感觉是不是旧会话就不能弄进来，或者说上下文太大，我也遇到这样的情况，然后我就会新开会话，让他去读之前的会话，然后继续

是的我也验证了，其他中转站也有类似的问题，当一个对话框内容非常多时，大概几百行的提示词，就会出现429，切换一个新的对话，提示词少一些就正常了！

人多了就会这样，以前很少这样的，后台加了限制，听说是根据任务复杂程度或者代码任务来审核

应该就是上面佬说的抢线程

早上早点和下班之后，很少出现429

我都是暴力解 勉强能用 ^-^

即使挤进去了，上下文100K左右的时候就会出现假死现象，然后又重开，没办法啊~

是的，只要你挤进去了就可以持续使用，闲置一会就需要重新排队

至于怎么挤进去全看运气。那些邪修基本没啥用，连上只是运气好正好挤进去了。

所以感觉和令牌桶，抢线程一样。就看谁可以卡到点抢到释放出来的资源了。然后一直别让释放就行了 我之前一次请求200秒都一直挂着

真的能这么随机吗，我甚至测试了三次，新开对话描绘，切回我原有对话马上429重试无数次了，最后只能用新开的对话继续 ^-^

感觉挺随机的，有时候我多重试几次就出了，有时候得新开对话才能出。不过挤进去的话基本就可以一直用，不断了

我感觉any是看session id的，本质还是碰运气，新开对话就有新session id，新session id可能会打到可用的账号上，就能用了