反代 灰产 中转 应该都在这里了👇 一、综合型多协议网关 CLIProxyAPI 是这个赛道的标杆，把 Gemini CLI、Antigravity、ChatGPT Codex、Claude Code、Qwen Code、iFlow 包装成 OpenAI/Gemini/Claude/Codex 兼容的 API 服务 AIClient-2-API 是 Node.js 实现，通过模拟 Gemini CLI、Antigravity、Codex、Grok、Kiro 的客户端请求，封装成本地 OpenAI 兼容接口 2026 年初还加了 Grok 的 Cookie/SSO 逆向，是目前对 Grok 支持最完整的 Antigravity-Manager 是桌面客户端路线，Tauri + React 写的，把 Google/Anthropic 的 Web Session 转成标准化 API 接口，带 OAuth 链接生成和账号池调度。这个适合拿来讲"账号管家"这种场景化内容 9router 和它的 TypeScript fork OmniRoute 是"智能路由 + 多档 fallback"的代表，iFlow、Kiro、Qwen 被标为 FREE 的是真免费无限，通过 OAuth 和 device auth 接入 ccproxy-api Python 实现，特点是直接复用 Claude CLI SDK tokens 和 Codex CLI 的 credential store，插件系统做得比较干净 CliGate 带可视化 Dashboard，支持 ChatGPT Account Pool、Claude Account Pool OAuth PKCE login、Antigravity Account Pool，一键配置 CLI 工具 二、Claude 专项 claude-relay-service 是国内最火的 Claude 中转方案，集成 Anthropic 的 OAuth 授权流程，在 Web 界面点击 Add Account 生成授权链接，登录 Claude 账号授权后接入服务。拼车党的基础设施，教程必讲 ClewdR 是 Rust 写的，支持 Claude 网页和 Claude Code，单一静态二进制覆盖 Linux/macOS/Windows/Android，Docker 镜像齐全，带 React 管理界面。性能路线代表 claude-code-proxy 是 Claude Code 转 OpenAI 的经典实现，教程里讲"双向转换"的基础案例 claude-relay（npow）是另一个思路，直接起一个 claude -p 进程来代理，而不是逆向协议 claude-unofficial-api 和 unofficial-claude-api（st1vms）是更早期的纯 Session Key 逆向（前者 JS、后者 Python），适合在教程里讲"历史演进" Claude Code Action with OAuth是官方 Claude Code Action 的 fork，支持 OAuth 认证，让 Claude Max 订阅者在 GitHub Actions 里使用订阅 opencode-claude-auth 走 Keychain 路线，从 macOS Keychain 读取 Claude Code OAuth credentials，支持多账号自动检测 三、ChatGPT/Codex 专项 PawanOsman/ChatGPT 是元老级项目，把逆向成本打到几乎为零 acheong08/ChatGPT（revChatGPT）是逆向 ChatGPT Web 的祖师爷仓库 codexProxy（J1aDong/codexProxy）你自己做的那个方向，类似的还有不少把 Codex 包成 Anthropic Messages 入口的。 四、Gemini 专项 gemini-proxy（KashifKhn）是目前最干净的实现，Bun + Hono + TypeScript，OAuth 2.0 + PKCE 浏览器登录，自动刷新 token，不需要付费 API key，不需要 gcloud CLI gemini-openai-proxy（Brioch）、gemini-cli-proxy（ubaltaci）、geminicli2api（gzzhongqi）是同类的三个竞品，各有侧重。 openai-gemini（PublicAffairs）是 Serverless 路线，可以直接部署到 Vercel/Cloudflare Workers，讲部署那集必备。 五、Copilot 专项 copilot-proxy（hankchiutw）一个简单的 HTTP 代理，把 GitHub Copilot 的免费额度暴露成 OpenAI 兼容 API，思路清晰。 github-copilot-proxy（BjornMelin）做的是反向，让 Cursor 调 Copilot 的后端，绕过 Cursor 的 500 次 premium 限制。 copilot-proxy（lutzleonhardt）是 VS Code 插件路线，通过 Language Model API 暴露，思路很野 六、Kiro / Qwen / Grok 逆向 kiro-gateway（jwadow/kiro-gateway）是 Kiro IDE / Amazon Q Developer 的网关，免费白嫖 Claude 模型的核心姿势。 Qwen-Copilot-Proxy（edwardgj）伪装成 Ollama 接口来对接 Copilot Chat，思路巧妙。 GrokProxy（CNFlyCat）走 Cookie 路线，从开发者工具 Network 面板抓 sso= 开头的 cookie 配置进 cookies.yaml，教程里讲 Cookie 型反代的标本。 七、Cursor 专项 Cursor-To-OpenAI（JiuZ-Chn/Cursor-To-OpenAI）把 Cursor 编辑器的 AI Chat 包成 OpenAPI，从 Cursor 客户端 cookie（user_ 开头）提取认证，网页 cookie 不能用。这个对讲"客户端 Cookie vs 网页 Cookie 差异"是绝佳案例 八、逆向号池 + 商用平台（拓展视野） FakeOAI/tokens（FakeOAI/tokens）是商用级别，轮训号池将各大平台的模型能力转化为 OpenAI、Anthropic、Gemini 等平台的 API 接口标准格式，支持 Claude Code、Codex、GeminiCli 等终端调用。

今天芯片圈最大的新闻，莫过于Gerard在创立Nuvia CPU被高通收购五年之后，重新出发，新创立了ARM CPU公司，名字也跟之前非常像，叫Nuvacore 现在这个时间点做数据中心CPU，确实是赶上了CPU十年来最好的时代: AI agent带来CPU短缺潮已经经隐隐浮现，AWS多个客户都提出要包揽所有Graviton ARM CPU产能 ------------ 这个消息对硅谷的芯片打工人吸引力是巨大的，Nuvacore这次的阵容都是功成名就的明星阵容，以前Nuvia创始团队重新集合，拿了红衫的投资，做面向 AI 基础设施/agentic computing 的通用ARM CPU。当年还是一个尚未完全被验证的大方向都能大获成功，而现在ARM CPU服务器正在风口浪尖上，前景和想象力和2019年Nuvia比起来大了太多了 上一次Gerard把Google，苹果platform architecture组的架构大佬挖了好多过去，这次的号召力只会强得多，240m的融资，已经验证过的路径和创始团队，肉眼可见的下一个增长风口，一定会让Nuvacore成为湾区最热门最受追捧的芯片startup，没有之一。毕竟这是一个肉眼可见能财富自由而且风险收益比极好的机会 ---------- 遥想当年Nuvia第一代CPU的发布赶上苹果M2时代，还是挺震撼的，Nuvia让高通在一年的时间CPU跑分进步了整整三代，单核跑分从2300变成3200，竟然超过了苹果M2 max一大截 可惜Nuvia Phoenix core从发布到最后上市拖了太久太久，中间苹果把牙膏挤爆了连着上市了M3/M4，于是Nuvia CPU上市之后从跟M2比较变成了跟M4比较，从期待中的C位变成背景板了 当年Nuvia的眼光非常超前，在2019年ARM CPU服务器市场占有率几乎为零的情况下，就是想从零开始打通这个市场，2021年被高通14亿美元收购之后，高通也给了无限的资源支持，扩招力度很大，给的薪水都是市面上最高一档的。 可惜大环境在2022年恶化的很快，加上高通的管理层战略眼光实在太差太短视，在业界ARM服务器生态都开始有起色的时候，为了股价节约开支，竟然再一次把自家的Nuvia CPU 服务器团队解散了（算上2015年已经解散过一次ARM服务器团队） 直到2025年，Nvidia的Grace ARM CPU都已经发布四年了，Vera ARM CPU都已经自研好久了，Amazon的ARM CPU Graviton都快占据CPU服务器新出货的50%了，高通才后知后觉谨慎的重启ARM服务器项目 所以这次Gerard从高通的高管位置把之前的创始团队拉出来自己干，可能是因为高通高层战略眼光实在太差屡屡错过机会，上次Nuvia想做ARM服务器，高通的承诺也因为大环境恶化没做数，结果被收购之后被高通取消了项目直接改做了laptop芯片和手机芯片 加上高通今年在手机销量上因为内存和存储历史级的巨额涨价，可以预见要受到重创(市场萎缩30%)，能拿出的扩张预算有限，在高通能拿到的资源是受到掣肘的 而在创业公司里比在 Qualcomm 这种大平台里更容易拿到足够快的决策速度、团队纯度、产品定义权和资本叙事，于是选择在窗口已经被验证时重新集结老班底 但更可能因为，AI时代的CPU前景想象力真的太广阔了，完全值得重新投入一次，不是Gerard变了，而是外部市场变了 ------------------------ 进入2025年之后，AI agent的出现，隐隐让CPU重新变成了瓶颈 CPU服务器重新步入增长轨道，而且潜力巨大，有好几个因素： 1. 随着推理时代的到来，GPU演化到针对推理的系统级新架构，CPU 是永远在忙的总指挥orchestrator, 因为要追求token throughput，所以异构计算阶段变多 + 批处理数量batch越来越大，scheduling/routing/data flow复杂度变高，对orchestration要求也变高 所以在系统级异构推理架构里，AI加速器和GPU在CPU：GPU的配比上，也变得更为激进，从以前的1：4到Grace Blackwell的1：2，以后是很有希望达到1：1的比例的。Google TPU配Axion，Amazon Tranium配Graviton，Nvidia Rubin配自家Vera CPU 这条在我的去年11月半导体年终回顾写过，基本上在2026年成为了共识，虽然这部分主要是各家AI 芯片自研，并不是纯粹的CPU服务器，其实不算是外部CPU服务器的机会 2. 也是同一篇年终回顾里写到的： 从CPU视角去看agentic workload，routing和工具处理都在CPU上，如果把常用的agentic框架做profiling，比如SWE-Agent, LangChain, Toolformer，CPU最长可以占到90%的E2E端到端延迟，throughput瓶颈也更多的卡在CPU，CPU甚至能耗也超过了总能耗的40% Agentic AI目前是一个CPU瓶颈更多的事情，Agent管理很多个CPU，再加上agent经常要开sandbox，很可能会成就CPU需求的新一波回暖 现在回看去年写的这个逻辑，潜力是非常大的。但其实年初可能并没有很大规模发生，年初的CPU增长和各家渲染的CPU短缺潮和这个逻辑暂时关系不大，更多可能是前几年的capex投入GPU的比例太大，造成传统CPU服务器投入不够，所以需求上升是一个回补之前传统服务器投入不够的部分。 但到了下半年甚至2027，agent会开始更广泛的铺开，比如智能导购和客服，已经占到了Amazon去年年底100万CPU采购的相当部分比例，这部分的增长是很快的 前两个逻辑，基本上是今年主流叙事在讲CPU潜力的共识，但是我的感悟是，还有另外两个逻辑被低估了： 3. 造成CPU服务器潜力更大，更长线的主逻辑，可能和agent本身没有直接关系，而是code agent带来的副产物： coding门槛和速度的大幅优化，让“构建软件 + 连接软件 + 调用软件 + 自动化软件”这整件事便宜了一个数量级，Jevons 悖论在software供给端的展开，最终把世界推向更高的软件密度和 API 密度，这直接带来了CPU传统workload的线性上升 从2025年年底开始，coding agent迎来了质变，Claude code迎来了爆发式增长，三个月的token营收增长了三倍，那么导致的下一步必然是Code量的十倍增长,以及App数量的巨量增长 即便是在大厂，每天1m token消耗只能算是个平均水平，人均coding量必然是翻倍的（小厂就是翻十倍了），code供给量暴增，不会只停留在 repo 里，而会逐步变成更多长期运行的软件资产，长期存活的feature变多，product变多，microservice变多，API变多 长线来看，App/API所有的生产成本和生产周期会变成原来的10%，API实现极大富足。那么API的Usage就会大量的上升,这就会造成传统CPU Workload或者说CPU Seconds大量的上升，这甚至和agentic没有直接关系 时间维度上，这个逻辑并不是短期性质，Claude code的爆炸是这几个月刚发生的事情，那么产品上线，microservice，api上线，可能都要向后延迟。当软件变便宜，社会不会少用软件，只会把更多事情软件化 所以也许到下半年甚至更久才会看到，传统cpu云的需求又莫名其妙增加了，表面上看，甚至和AI agent没有直接关系 4. CPU是一个技术上很难通缩的东西，不像内存/存储有很多压缩算法会降低单任务对存储的用量，CPU workload增长转化成硬件需求增长是实打实的 比如说kvcache其实每年都有各种压缩技术出现，老的压缩技术比如kvcache的multi-head它会share一个head（GQV），这个大概会相当于4倍的压缩，再比如说去年turboquant这个技术也会新带来几倍的压缩。然后加上数据精度从FP16到现在的下一步要到FP4，精度的下降都会带来kvcache的压缩，从而带来存储方面的技术通缩。 但CPU是一个技术层面上通缩量很小的事情，目前任何的agentic的cpu workload（CPU seconds）增长都是硬件需求增长，它通缩的方面只有每年每一代跑分提高的10%到15%。如果说另外通缩因素，比如云的五倍六倍的超卖会不会影响？不会，因为它一直是超卖的，所以说超卖/利用率低这个CPU技术通缩的因素不会继续扩大了，每个增长的CPU seconds都是不怎么带打折的硬件线性增长 ARM的指引是CPU的供需缺口可能会到30%以上，这几个原因的叠加，加上AI服务器对CPU服务器产能和订单的挤压，可能会让缺口更大，各个hyperscaler的反应可能是会滞后的 ------------------ CPU整体需求潜力增长的同时，ARM服务器CPU也赶上了历史上最好的时代： Hyperscaler为了节省成本，接近50%的新增传统server CPU都是ARM，Google的Axion，Amazon的Graviton，Microsoft的Cobolt，Graviton甚至2026年的产能已经全部卖完，瓶颈成了产能 Google TPU配Axion，Amazon Tranium配Graviton，Nvidia Rubin配自家Vera CPU，这部分CPU为什么会集体转向ARM，除了成本因素之外，也因为推理系统为了追求token throughput，batch越来越高越做越复杂，自研ARM CPU以及系统性软件硬件的co-design会更方便，比如Nvidia是Dynamo去控制Vera和Rubin之间的协同 Nuvacore的规划上来看，不仅仅满足于做IP，也要做成品，因为在招聘网站上出现了validation engineer的职位 但是这次Nuvacore面临的挑战也不小：起步太晚了，无论是市场上，还是技术上，竞争都激烈了很多。CPU服务器和七年前比，已经复杂了很多，已经不再是单片CPU的竞争，而是rack系统级别的复杂度 现在开始做2028~2029年上市的CPU，要做到rack级别有竞争力，规模要大很多，基本上要几十个chiplet，500+个core拼起来，还要考虑如何适配AI agentic workload，工作量比以前明显要大的多，对一个startup的挑战比七年前也大得多 ---------------- 上次Nuvia在成立两年之后成功的以14亿美元出售，这次市场热度比五年前高了一个数量级，Nuvacore之后的路会怎么走呢？ 如果是被收购路线，其实买家可能比五年前比并没有更多，这五年里，Google有了Axion，微软有了Cobalt，Amazon有了Graviton，Nvidia自研的Vera CPU已经成型，连ARM也打破了35年来只做IP的常规，开始做自己的AGI CPU芯片 最有可能的是Softbank系，softbank已经在ARM CPU服务器生态上布局深耕了多年，65亿美元收购了Ampere，再收购Nuvacore是很正常的事情，这个市场想象力足够大 其他的选择也可能是Meta，因为几家互联网公司里，只有Meta的silicon house没有稳定可靠的CPU服务器，有限的资源在MTIA都做AI加速器去了 但是Meta的问题在于稳定性极低，决策每个月都在变化，注意力非常短期化，项目随时取消，对Nuvacore来说完全无法兑现潜力，是一个非常糟糕的买家 但总体来说，Nuvacore的选择肯定比五年前宽了太多了，对ARM CPU服务器的潜力大家的共识都很明确，融资的难度要小很多，自己运营扩张起来，阻力比以前小很多，合作伙伴的配合程度上也因为未来预期，会容易很多 完全可以自己做大到比Nuvia当年更大的规模再考虑出路，根本不着急卖

看到晚点LatePost也更新了谈千问换帅事件的播客，深度依然是全网无出其右，确实单口播客这种媒介形式也更适合即兴的去跟一些热点选题，比文稿生产的效率要高。 总之，光速听完之后，阑心一言咔咔启动： - 简单化的去理解林俊旸的离职，一定会被牵着鼻子走，比如我们看到投放的料五花八门，有把阿里HR挂成万恶之源的，也有对冲说林俊旸在搞独立王国的，这些都是噪音，不是说对错不重要，只是很多时候你很难用对错来评价所有事情，需要接受个人意志和组织生长之间的摩擦必然有概率发展到不相容的地步； - 三个需要厘清的事实是，其一，林俊旸不是被离职的，阿里不可能主动开掉这个级别的Leader，其二，DAU是和千问App的产品团队捆绑，这是吴嘉/智能信息事业群的工作，不太可能牵扯到从属于阿里云的模型团队，其三，今年1月空降的周浩，是接替已经确定要走的后训练负责人喻博文，并不是来管林俊旸的； - 所以林俊旸的离职，更接近于一种「道心破碎」的结果，晚点主播曼琪的用词很微妙——「 长期知其不可为而为之的付出」——最后被组织架构调整这根最后的稻草给弄崩了，宣布离职的整个过程，就是没考虑给阿里的管理层留太多反应时间，是铁了心不想干下去了； - 千问的模型团队属于通义实验室，而通义实验室又属于阿里云，最后阿里云再属于集团，这个嵌套关系已经很复杂了，在叠加了千问模型作为阿里全村希望的战略定位，资源匹配问题就很大了，所以才有了连阿里CEO吴泳铭也不知道千问模型团队被卡资源的说法； - 林俊旸这边的人马高度依赖阿里云的Infra支持，但实际上他们觉得阿里云在服务外部团队上甚至好于服务自家千问基模——这也太离谱了——于是去年年底林俊旸绕过阿里云直接找吴泳铭争取了自建Infra的权限，这个越级操作也为后来发生的事情埋下了伏笔； - 还有一个比较难绷的是，去年春节前后，o1带动推理模型开始崛起，千问在后训练方面遇到了瓶颈，然而转用字节开源的强化学习框架veRL来做训练，发现效果有了比较明显的提升，相当于通过控制变量，发现了问题是在Infra上，这才有了林俊旸对Infra一直不满意的根源，要做垂直一体化的建设； - 但阿里云的判断不是这样的，因为混合多模态已经是明显的趋势，把各个模态、预训练和后训练都拆出来搞单元制，是一定要做到事情，但对原千问模型团队来说，这就是在被收窄范围，尤其是时间点卡在Qwen 3.5训练完成后不久，大家都很疲惫，突然又得到了这种不太像是奖励的调整； - 阿里的管理层比较懵逼，或者说被动，也有反思组织变动没有考虑办公室政治的因素，把明明是要扩大对基模投入的事情，干成了让基模团队觉得是要收缩的效果，沟通上没有把控好，现在尽量要去平稳解决矛盾； - 千问在开源社区赢得的名声，到底怎么转化成阿里的资产，这个量尺很难找到，在2B市场，开源意味着很难卖API，在2C市场，开源⋯⋯好像也没啥意义，用户不会因为你开源了就来用你的App，然而林俊旸是一个相当理想主义的Leader，万亿参数的Qwen Max旗舰模型是阿里没有选择开源的，但他也想推动开源； - 千问的模型团队从创建之初就保有着一个相对独立的工作环境，少被拉扯和打断，这种专注力被视为千问模型屡出成果的原因，但是当AI行业进入一场谁也输不起的All In战局后，这种与真实市场保持距离的自驱型团队还能不能存在，既是一个原则问题，也是一个选择问题。

Claude max 要对触发风控的账号做 KYC 了 😂 人工智能初创公司 Anthropic 正在其 Claude 平台逐步推行身份验证机制。当用户访问特定功能或触发常规平台完整性检查时，系统会要求通过第三方合作伙伴 Persona Identities 完成验证。此举旨在防止滥用、执行使用政策并履行法律义务。验证过程通常在 5 分钟内完成，用户需提供有效的政府签发证件（如护照、驾照或国民身份证）并拍摄实时自拍。 Anthropic 强调，身份验证数据仅用于确认用户身份及合规用途，不会用于模型训练，也不会共享给第三方用于营销。相关证件和自拍图像由 Persona 托管，Anthropic 仅在必要时访问记录，不会在自有系统中存储图像。此外，若验证后发现用户多次违反政策、来自不支持的地区或未满 18 岁，其账号仍可能被封禁。 Claude Help Center