最近AI开发圈出现了一种非常有意思的玩法：不再让每一个AI客户端单独配置一套API，而是在本地或者自己的服务器上搭一个统一的AI API网关。

你可以把Gemini、WorkBuddy、CodeBuddy、Codex等不同来源的账号和模型集中到一个入口，再让不同客户端通过统一的Base URL访问。这样一来，原本需要分别折腾API Key、模型地址、客户端配置的工作，就变成了“上游账号 → 网关 → OpenAI兼容接口 → 各种AI客户端”这一套统一架构。

你给出的YouTube视频《Gemini反代实现Token自由sub2api接入work Buddy接入codex》和“Sub2Api邪修项目”正是围绕这个方向展开。不过需要注意，视频标题中的“Token自由”“邪修”等属于内容标题化表达，并不等于官方提供无限Token或可以绕过第三方服务的配额。Sub2API官方定位本身是AI API网关和订阅配额分发管理平台，负责鉴权、用量统计、负载均衡和请求转发。

一、Sub2API到底是什么？为什么突然被AI玩家盯上？

简单来说，Sub2API可以理解成一个放在AI客户端和上游AI服务之间的“中间层”，正常情况下，Codex、WorkBuddy或者其他AI客户端需要直接连接对应的AI服务，每个客户端都需要自己处理API地址、认证信息以及模型配置。而使用Sub2API之后，可以把多个上游账号统一放进网关，再由网关向客户端提供统一的API入口。

官方项目介绍显示，Sub2API支持多账号管理，可以管理OAuth和API Key类型的上游账号，同时提供API Key分发、Token级用量追踪、成本计算、智能账号调度以及粘性会话等能力。

所以它真正解决的并不是“凭空增加Token”，而是把原本分散的AI账号和API访问方式集中起来管理。

二、所谓“Token自由”，真正应该怎么理解？

“Token自由”是这类视频标题里最容易吸引人的说法，但如果从技术角度理解，千万不要把它直接理解成“无限Token”。

Sub2API可以管理多个上游账号，并根据请求进行账号选择、负载均衡和用量追踪。因此，当多个合法的上游账号被集中到同一个网关之后，用户感觉上的确会比单账号使用更加灵活，但这并不意味着Google、OpenAI或者其他AI服务的实际配额凭空消失。上游服务仍然拥有自己的账户政策、速率限制、配额和服务条款，因此，更准确的说法应该是：

这也是搭建这类系统时最需要注意的地方。

三、Gemini为什么适合放进Sub2API？

Gemini是目前AI开发工作流中非常重要的一类模型，而Sub2API已经提供Gemini相关的接入方式，当前项目文档显示，Sub2API支持Gemini OAuth，其中包括Code Assist OAuth和AI Studio OAuth，同时也支持直接使用Google AI Studio API Key。对于Code Assist OAuth，项目提供了相应的OAuth流程；API Key方式则更加直接。

这意味着用户不需要把所有Gemini访问逻辑硬编码到每一个客户端里，而可以把Gemini账号统一放到网关进行管理，这种架构特别适合经常切换不同AI客户端的人，因为客户端只需要认识网关提供的接口，而不需要理解后面的每一个上游账号。

四、Gemini反代到底解决了什么问题？

所谓Gemini反代，本质上就是增加一个中间层，原本是：客户端 → Gemini

加入网关之后：客户端 → Sub2API → Gemini，这样做最大的价值不是“神奇地改变Gemini”，而是让客户端与上游服务解耦。

如果以后更换账号、更换OAuth方式、增加另一个上游，客户端甚至可以不需要大幅修改配置，只需要让网关负责新的连接方式即可。

这也是Sub2API这类项目真正有价值的地方。

五、WorkBuddy接入之后，玩法就开始变了

如果说Gemini反代解决的是上游AI服务管理，那么WorkBuddy、CodeBuddy等客户端解决的则是AI Agent工作入口，目前社区已经出现专门的Buddy2API项目，用于把WorkBuddy / CodeBuddy、QClaw、QwenWork和TraeWork等本地AI客户端连接到统一的OpenAI兼容接口。项目说明显示，其本地网关默认监听 127.0.0.1:8787/v1，不同渠道可以分别导入本地登录状态，再向客户端提供统一接口。

这样就形成了一个很有意思的架构：WorkBuddy → 本地API网关 → 上游AI账号，而Sub2API则可以进一步承担上游账号和API网关层的管理，也就是说，用户真正需要管理的东西开始从“一个个客户端”转变成“一个统一的AI基础设施”。

六、Codex为什么是这套玩法里的关键角色？

Codex最大的特点，是它并不是单纯聊天，而是一个面向软件开发的Agent工作环境，因此，如果能够给Codex提供一个兼容的API入口，那么理论上就可以把网关作为Codex与上游模型之间的连接层。

Sub2API官方配置中已经出现了专门针对Codex CLI的处理选项，例如 force_codex_cli，用于在特定情况下将 /openai/v1/responses 请求按Codex CLI方式处理。官方文档同时提醒，这类强制设置会影响所有客户端，因此需要谨慎使用，这说明现在的AI网关已经不只是传统意义上的“API转发器”，而开始针对不同Agent客户端的请求格式和行为进行适配。

七、为什么OpenAI兼容接口如此重要？

在整个“Sub2API邪修工作流”中，OpenAI兼容接口可以说是最关键的一层连接标准。如果每一个AI客户端都采用完全不同的API协议，那么用户想要更换模型、切换服务或者同时使用多个AI工具，就必须针对不同客户端重新配置接口和认证方式，整个使用过程会变得非常繁琐。而OpenAI兼容接口提供了一种更加统一的调用方式，让大量已经支持OpenAI API格式的AI客户端，可以通过同一种接口与不同的上游模型进行通信。

这也意味着，网关可以把复杂的上游差异隐藏起来。客户端不一定需要知道后面究竟连接的是Gemini、其他AI模型还是多个账号，只需要按照兼容接口提供的Base URL、API Key和模型信息发起请求即可。以社区的Buddy2API为例，其项目提供OpenAI兼容接口，并针对Codex使用 /v1/responses，其他客户端则可以根据自身支持的接口形式使用相应的Chat Completions方式。这样一来，原本需要分别适配多个客户端的工作，就可以集中到中间网关完成。

八、Sub2API真正厉害的是“多账号调度”

很多人第一次接触Sub2API，会把注意力放在“反代”两个字上，实际上，反向代理只是基础能力，真正值得关注的是它后面的账号调度系统，官方项目提供智能账号选择和粘性会话能力，同时支持并发控制、速率限制等机制，例如，一个网关后面可能存在多个上游账号：

客户端只看到一个统一入口，而网关负责判断请求应该交给哪个上游，这就是所谓的账号池。

九、粘性会话为什么重要？

AI Agent与普通API请求还有一个非常明显的区别：上下文连续性。如果同一个Agent任务第一次请求使用账号A，下一次请求突然切换到了账号B，那么上下文、速率状态或者上游会话可能产生问题。

所以Sub2API提供了粘性会话相关能力，并且官方文档特别提醒，如果使用Nginx进行反向代理，需要注意带下划线的请求头。例如 session_id 这类Header如果被Nginx默认丢弃，就可能导致多账号环境中的粘性会话失效，这对于Codex、Agent等长任务尤其重要。

十、为什么Nginx也成为这套系统的重要一环？

当你只是本机测试时：127.0.0.1 → Sub2API，基本就够用了，但如果准备让其他设备访问，或者把网关部署到服务器，那么通常就会加入Nginx，典型结构变成：

这样可以进一步处理域名、HTTPS、访问控制和反向代理，不过这里也有一个非常容易踩坑的地方：Sub2API官方文档指出，如果Nginx代理Sub2API并搭配Codex CLI使用，需要在Nginx http块中开启 underscores_in_headers on;，否则像 session_id 这样的Header可能被Nginx丢弃，从而影响粘性会话。

十一、这套AI工作流为什么越来越像“自己的AI基础设施”？

当你把Gemini、WorkBuddy、Codex、Sub2API以及其他客户端放到一起之后，整个系统已经不太像传统意义上的“安装一个软件”，它更接近一个小型AI基础设施：

账号层负责身份和上游服务，网关负责统一管理，协议层负责兼容不同客户端，Agent负责执行任务，而最上层则是用户真正使用的开发工具。

这种架构的好处是，一旦未来增加新的AI模型或者客户端，不需要重新设计整个系统，只需要增加对应的适配层。

十二、对于开发者来说，真正值得学的是“API抽象”

Sub2API这类项目真正值得研究的地方，并不是所谓“Token自由”，而是它背后的API抽象思想，过去我们使用AI工具，经常会遇到一个问题：

当中间增加一个兼容层以后，客户端与模型之间就可以实现一定程度的解耦，客户端只需要知道：

至于后面到底连接Gemini、其他模型还是多个账号，则可以由网关处理

十三、“邪修”真正邪在哪里？

如果一定要解释为什么社区喜欢把这种玩法称为“邪修”，其实不是因为它做了什么神秘操作，而是因为它把原本需要多个官方客户端分别完成的事情，重新组合成了一条非常工程化的链路：

每一个环节单独看都不算特别神秘，但组合起来以后，整个AI使用方式就完全不同了，不过这里必须强调：网关只能管理你有权使用的账号、Token和API资源。 不应该把它理解成绕过服务商认证、突破账户限制或者制造虚假额度的工具。上游服务的配额、账户政策和服务条款仍然有效。

十四、Sub2API部署需要什么环境？

如果准备自己搭建，Sub2API当前官方项目采用Go、Gin、Ent等后端技术，前端使用Vue、Vite和TailwindCSS，数据库使用PostgreSQL，缓存和队列使用Redis。官方部署文档推荐Linux服务器，并提供脚本安装和Docker Compose等方式，因此，它并不是一个简单的“下载一个EXE双击运行”的小工具，而更接近一个完整的Web服务。

如果只是个人测试，可以优先使用本地部署；如果准备提供多人访问，则需要进一步考虑HTTPS、管理员认证、API Key安全、数据库保护、日志以及访问控制。

十五、为什么我更建议把它理解成“AI API路由器”？

如果用一句话概括Sub2API：

它自己不负责替代Gemini、Codex或者其他大模型，而是负责把请求正确地送到对应的上游，同时处理账号、认证、计量、调度等问题，这其实也是未来AI基础设施非常重要的一条路线，因为随着AI模型越来越多，用户真正需要的可能不是几十个独立客户端，而是一个能够统一管理这些模型的入口。

十六、未来的AI客户端可能只需要一个Base URL

这也是Sub2API这类AI网关项目最值得关注的发展方向之一。随着AI模型数量不断增加，未来用户电脑中可能同时存在多个AI客户端，例如 Codex、WorkBuddy、Claude Code、Cherry Studio、Chatbox以及其他AI Agent工具。如果每一个软件都需要单独配置API地址、账号授权、模型参数以及使用额度，那么管理成本会越来越高。

而统一AI网关的出现，则提供了一种更加简单的方式：客户端只需要连接一个Base URL，后端由网关负责管理多个AI服务。 用户不需要关心当前请求到底发送给哪个模型，也不需要频繁修改不同软件的配置。当增加新的模型、替换账号或者调整调用策略时，只需要在网关层完成修改即可，这种模式实际上正在改变未来AI工具的使用方式：

未来的AI工作流可能不再是“每个软件绑定一个模型”，而是“多个AI客户端连接一个智能调度中心”。

在这种架构下，网关不仅仅负责简单转发请求，还可以进一步承担更多功能，例如：

因此，未来AI客户端之间的竞争可能不只是“谁支持更多模型”，而是谁能够更好地接入统一AI基础设施。而像Sub2API这样的项目，本质上是在探索一种新的AI使用方式：让模型成为后台资源，让网关成为统一入口，让Agent和应用负责完成具体任务。

对于普通用户来说，这意味着未来可能不需要记住几十个AI平台的网址、API Key和账号，而只需要连接自己的AI入口，就可以调用背后的多个模型和工具。对于开发者来说，这则意味着可以更加灵活地搭建属于自己的AI工作流系统。

总结：真正值得关注的不是“Token自由”，而是AI网关时代来了

Sub2API这类项目能够快速受到AI开发者关注，本质上是因为它解决了一个越来越现实的问题：AI模型越来越多，AI客户端越来越多，但它们之间缺少一个统一的连接层。Gemini反代解决的是上游连接，Sub2API解决的是账号、配额和请求管理，OpenAI兼容接口解决的是客户端兼容，而Codex、WorkBuddy等Agent则负责真正执行任务。把这些东西组合起来之后，就形成了一套完整的AI工作流基础设施。

所以，与其把“Sub2API邪修项目”简单理解成一个所谓的Token神器，不如把它看成一次非常典型的AI API基础设施实践：模型负责提供能力，网关负责调度资源，兼容协议负责连接客户端，Agent负责执行任务，而随着AI Agent越来越普及，未来真正有价值的可能不再只是“哪个模型最强”，而是你能不能把不同模型、不同账号、不同Agent和不同工具组合成一套真正属于自己的AI工作流。