oneshot许愿吗？还是让他研究代码仓库然后讨论视频脚本后才出的？

先在work里用半小时看看有没有降智，没降智的话就搭个站里的codex-proxy-rs，json丢进去，再搭个sub2api透传+分发。 请求链路：你 → sub2api → codex-proxy-rs → OpenAI

每天有用量限制，明天就又可以用了，不过怀疑bps用多了也会封号。

excel会403，需要分几天来跑，天天403应该也是会封号的。

目前就打票和excel两种路子，能接受后续封你号的话，找那些接受托管的中转站，跑astra肯定是能够蹬完周限的。

换ip找不降智的节点强行挤进去，cookie有时效过期就得重新找，并且ip池太小的话也很难找到不降智节点，所以只能间歇缓解。 只有大站点持有很多号轮流来才能把空窗期填上。

小站点的号基本全部黑了，就算提高成本，打票和excel也存在空窗期。 只有大站独立高倍率号池能好点。

temperature不是这么用的，别学个词就显摆。

智驾模型的输出，只是决策系统的输入。目前还有大量硬编码if else，场景覆盖显然是不如拥有常识的语言模型的。

当算力足够1秒内判断100次的时候，错误一次已经不值一提。

一定会用于智能驾驶，因为智能驾驶的场景恰好是：输入是大量文本，输出是有限决策，延迟要求极高。

我觉得对大厂来说去洽谈私有化部署claude gpt虽然不现实，但这种级别的模型应该毫无压力。

预设场景可以事先用LLM生成好模板，通过程序注入选项，通过RAG注入背景信息

6位数字.xyz，挂nas直接买10年。

你以为厂商真有算力和数据库去一个一个标记IP么，ASN纯净度是非常可靠的粗筛，同时不会产生性能瓶颈。

这种情况一般是你的号已跌落斩杀线

按8月的规律，降额其实才是风控的第一阶段，那时候一刀降到25%也是有的。后续才是降并发和降智。 现在这种大规模直接降智是9月出现的新情况。

灰产有定制过的软路由，routeros多线接入并分发成几十个无线ssid。

目前无解，2周以来没见过完全恢复的案例。

web端和codex端是完全不同的风控体系 web基本只要换到干净的IP就能立即恢复满血 codex目前来看是账号级别标记，至今没看到完全恢复的例子

连github认证开发者的6个月兑换码都用不了了，不太可能只是按钮没了。

这个流程里单一卡片的上下文就有这么多，总共大概要跑几千个。

astra的缓存读取很贵 如果你的5分钟里包含大量工具调用堆积了很多上下文，很正常。 如果你的5分钟里全是高强度思考和等待，花不了多少额度。

想畅通无阻的话还是搞个bybit。 国内卡头都没法在网页端直接订阅，必须套appstore或者play的订阅，所以开啥卡都没什么区别。选你的工资卡对应的银行开就行了。

不建议用手机app，不小心泄露定位或者梯子开错就有可能暴露真实环境。需要web端随便找个指纹浏览器，我用的roxybrowser。反正你有家宽代理，配进指纹浏览器就行了。 我用sub2api反代，因为我是拼车的。如果你不拼车就不建议反代。openai一定能查出反代，只不过目前低并发的不怎么管而已。

你可以去ip查询网站看一下出口ASN，如果不是ATT那么大概率是伪家宽。 倒也不是说必须ATT的IP才行，顶级云服务商的IP也大概率是高质量独享IP，小型服务商则很难判定。

国内能买到的，美国真正的家宽应该只有ATT。 我相信自用是完全没问题的，我的环境是gmail别名邮箱（烂大街），低价菲区U卡直付（烂大街），sub2api（烂大街）走美国ATT家宽出口（据我所知使用ATT家宽的人不多），和朋友3人拼车（烂大街），账号总并发5以内（烂大街），从来未出现降智情况。

中转站用真家宽也只能顶过新订阅账号第一天的那几个小时。 gpt的老风控策略依旧还在，高并发+请求分析画像，仍然可以分析出是分发账号进行风控。并且一旦这个IP下风控帐号多了，这个IP也废了。


本来是无所谓那点降智的，但是astra的缓存读价格太离谱了，只能缩到400k以内用。