凌晨两点，你的 Claude Code 又提示额度用完了。切到另一个账号，改环境变量，重启，三分钟过去了，写代码的思路也断了。这种事一个月发生五次。你开始想：有没有办法让整个团队共享一个 Claude Max 订阅，像家庭共享 iCloud 那样，谁用谁取、用完即止？
Sub2API 做的就是这件事。把 Claude、OpenAI、Gemini、Grok 的订阅账号统一接入一个自建网关，转化成 OpenAI 兼容的 API 接口，再分发给团队的每个人。它不是一个简单的代理转发器，而是一个把”订阅额度”变成”可管理团队资源”的运营平台。中文社区管这叫”拼车”，英文 README 里叫 subscription pooling，背后的逻辑是一样的：与其五个人各付 $200，不如买一个订阅五个人用。
截至 2026 年 7 月，这个项目在 GitHub 上已经积累了 33.9k Stars 和近 7k Fork。从 2025 年 12 月第一个 commit 到现在不过七个月。放在 AI 基础设施类项目里，这个增速排得进前五。但 Star 数从来不是判断这类工具的唯一标尺，有些项目 Stars 高是因为它解决了真正普遍的问题，有些是因为它刚好踩在了一个敏感的灰色地带。Sub2API 两样都占。
翻完源码结构、Issue 区和社区讨论之后，我的判断比一开始复杂得多。它确实把一个真实痛点解决得很漂亮，但你在决定部署之前，有几件事必须先知道。
打动我的几个地方
Sub2API 最核心的能力不是”转发请求”，而是把一堆零散的订阅账号抽象成一套可运营的资源池。这背后有六个工程层，每层解决了一个独立的问题。
协议适配层是入口。Claude 用 Anthropic 私有协议，Gemini 走 Google 的 gRPC 通道，Grok 有自己的一套 SSE 格式。Sub2API 在网关层统一转成 OpenAI 兼容的 /v1/chat/completions 接口。Claude Code、Codex CLI、Cursor 这些客户端不需要任何代码改动，换个 BASE_URL 和 API Key 就能直接跑。
上游凭证池是调度器的燃料。支持 OAuth 登录和 API Key 两种方式接入上游账号，管理员在后台添加账号后，平台自动维护 Token 刷新和过期轮换。一个正确的设计判断：不要把上游密钥暴露给终端用户，他们只需要拿平台发的 API Key。
请求流经这六层，从协议适配到计费落账，每一层都有独立的数据结构和错误处理路径。
智能调度器是整个系统的决策中枢。请求进来时，调度器根据各账号的剩余额度、并发槽位、响应延迟和粘性会话需求来路由。粘性会话对 Claude Code 这类多步 Agent 调用尤其关键，中途换账号会导致上下文断裂，Agent 直接失忆。
双层并发闸门的设计很务实。同时在用户维度和账号维度做并发限制。单用户最多同时跑 N 个请求，单个上游账号也设上限。这防止了一个人把全团队的额度打爆，也防止了上游账号因为瞬时并发过高被风控标记。
幂等计费账本解决分账问题。每个请求的 Token 消耗精确追踪到用户，支持按模型、按时间、按用量出账单。内置支付系统接入了支付宝、微信、Stripe，但这个功能更多是给想半商业化运营的人准备的，内部团队用 Simple Mode 就够了。
Web 管理后台不是花架子。Vue 3 + TailwindCSS 的前端，实时监控请求量、错误率、账号状态和用户用量。Issue 区里很多讨论都是围绕后台的具体配置项展开的，说明用户确实在用，不是 demo 级界面。
架构再漂亮也只是纸面上的东西，实际部署和配置体验才是真正决定要不要用的分水岭。
跑起来看看
部署比想象的简单，官方推荐 Docker Compose 一键部署。整个流程从克隆配置到服务就绪，三行命令就能搞定：
mkdir -p sub2api-deploy && cd sub2api-deploy
curl -sSL https://raw.githubusercontent.com/Wei-Shaw/sub2api/main/deploy/docker-deploy.sh | bash
docker compose up -d
脚本自动拉取 PostgreSQL 和 Redis 容器，生成 JWT_SECRET 和数据库密码。首次启动后浏览器打开 http://YOUR_IP:8080，走 Setup Wizard 配置数据库连接并创建管理员账号。
如果只是团队内部自用，开 Simple Mode 就够了：
RUN_MODE=simple SIMPLE_MODE_CONFIRM=true ./sub2api
团队自用不需要那些复杂的东西，而且功能越少越不容易出错。个人开发者或内部小团队优先走这条路，等真正需要多用户注册和计费了再切完整模式。
常见的卡点有三类，提前知道能省不少时间：
-
Nginx 反代时必须在 http block 里加 underscores_in_headers on，否则粘性会话的session_id头会被丢弃，多账号调度直接失效 -
Issue #2859 报告了高级调度器的 sticky 账号逃逸问题，选了”最快响应”策略的话慢账号可能一直不被选中 -
大量 Open Issues 围绕特定模型兼容性——Grok 图片计费、Gemini 授权登录、OpenAI Responses SSE 事件格式等，遇到问题先搜 Issue 区
部署流程全程自动化，从初始化到服务启动通常不超过三分钟。一键脚本还内置了 systemd 服务管理和在线升级回滚能力，生产环境部署不用额外折腾进程守护。
部署跑通只是一半，更关键的问题是这个网关到底适合谁。
什么时候用，什么时候别用
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| 团队共享 AI 订阅 | 3-10 人开发团队 | 统一 Key 分发、Token 级分账 | 需自建维护服务器 |
| 个人多平台整合 | 同时用 Claude+Gemini 的开发者 | 一个 Key 通吃 | 单人收益不如团队明显 |
| 拼车分账 | 拼车群/小团队 | 内置支付+精确计费 | 上游封号风险，法律灰色地带 |
| 成本可视化 | 需要审计 AI 支出的企业 | 按项目/用户出用量报表 | 报表功能还在快速迭代 |
不适用的情况同样重要。如果你只是一个人偶尔用用 Claude Code，买一个靠谱的商业中转站更省心，一个月几块钱的事，不需要折腾一套 Docker 栈。你的使用场景涉及合规审计或处理敏感数据的话，自建虽然数据归你管，但上游 API 流量依然经过 Anthropic 和 OpenAI 的服务器，数据主权这件事不因为你自建网关就解决了。还有，别指望靠这个项目公开卖 API 赚钱，README 的免责声明写得很清楚：开发者从未授权任何商业运营，所有风险自担。
注意：本项目涉及绕过上游 AI 厂商的订阅共享限制，LGPL-3.0 协议。使用前请自行评估所在地区的法律风险。衍生代码需开源，企业采用需额外合规评估。
三个工具的定位不是并列的替代关系，而是像一栋楼的不同楼层：One-API 是地基，做通用渠道聚合；New-API 是标准层，偏企业级网关治理；Sub2API 是顶层，专攻订阅额度分发和拼车经济。
场景分析明确了它的最佳适配区间，但一个项目能不能长期依赖，还得看社区的健康度。
社区怎么样了
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | 33.9k | 7 个月达成，增速在 Go 生态网关项目中领先 |
| 核心维护者 | 2-3 人 | Bus Factor 中等风险，Wei-Shaw 是绝对主力 |
| Open Issues | 2,252 | 以功能请求和兼容性问题为主，核心稳定性 bug 占比不高 |
| 协议 | LGPL-3.0 | 衍生代码需开源，企业需评估合规风险 |
33.9k Stars 七个月达成，增速无可挑剔。但 2,252 个 Open Issues 直观感受是吓人的。仔细翻一下会发现大部分是各平台模型兼容性的功能请求，像”支持 Opus 4.8″“对接 Microsoft Foundry””Gemini Flash 图片计费错误”这类，真正影响核心稳定性的问题占比不高。
衍生项目生态值得注意。sub2api-mobile 提供了移动端管理面板，Sub2ApiPay 支付模块已经被内置进主仓库。赞助商列表里有二十多家基于 Sub2API 搭建的商业中转服务，包括 CCTK.AI、OpenModel 和 APIKEY.FUN，形成了一个自发的分发网络。但这种繁荣也是双刃剑，一旦有人大规模转卖 API 被上游盯上，反噬的可能不只是那个运营者。
有个数据我没找到：核心维护者的实际响应时间。Wei-Shaw 是主要的合并和发布人，Issue #763 从提出功能请求到合并只花了一个小时。但大量 Issue 处于无人响应的状态，这是维护者数量和项目规模不匹配的典型症状。CodePick 的部署指南里也明确指出，sub2api”适合内部团队自用，不适合新手拿来无脑公开商业化”。
社区数据说清楚了，但数据只能告诉你项目还活着，不能告诉你值不值得跟。该聊点真的了。
我的真实看法
我对 Sub2API 的判断分两层：工程层面和立场层面。
工程层面，它的架构设计是成熟的。六层能力每一层都有独立的数据结构和错误处理路径，不是 CRUD 式的功能堆叠。feei.cn 的深度分析文章追踪了 v0.1.151 版本的一次请求全链路，从路由匹配到计费落账，代码的组织方式比很多商业 API 网关产品还要清晰。Go + Ent ORM 的组合在处理高并发转发时表现稳定，HTTP/2 支持和 fail-close 策略说明维护者考虑过生产环境。
但立场层面的问题绕不过去。这个项目的价值建立在一个假设上：AI 厂商对订阅共享会”睁一只眼闭一只眼”。Anthropic 和 OpenAI 的服务条款明确禁止账号共享，只是目前执行力度不大。如果这个假设未来被打破，比如 Anthropic 开始批量封禁异常使用模式的账号，Sub2API 整个价值基础会动摇。
赞助商生态既是优势也是风险信号。二十多家商业中转站意味着这个项目已经养活了一个不小的产业链。掘金上有用户算了笔账：5 人拼一个 Claude Max，人均 ¥399/月，省了 72%。这个数字确实诱人，但也意味着一旦上游收紧政策，影响面会很广。
趋势上看，项目还在快速上升期。2026 年 7 月仍然保持每日多次 commit 的频率，v0.1.164 是前天发布的。新功能的迭代方向是异步图像任务、WebSocket 会话管理和组合分组路由，说明维护者在往”生产级网关”而非”个人中转工具”的方向走。
和同类项目比，One-API 做的是通用渠道聚合，New-API 偏向企业级网关治理，Sub2API 的独特位置在于”订阅额度分发和拼车经济”。三者不是替代关系，像是一栋楼的不同楼层。如果你的需求就是几个朋友合买一个订阅公平分账，Sub2API 是最对口的那个。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/Wei-Shaw/sub2api |
| 深度技术分析 | https://feei.cn/sub2api |
| CodePick 部署指南 | https://codepick.dev/zh/guides/sub2api-self-hosted-ai-relay |
说完了所有分析和判断，该落回到最实际的问题上了：你到底要不要用。
团队自用可以上，商业化别碰
如果你是一个 3-10 人的开发团队，每人每月都在给 Claude 和 Gemini 各自续费，Sub2API 帮你们把成本砍掉一半是完全现实的。先用 Simple Mode 跑通内部流程，后台管理、账号调度、用量统计这三个功能是真正的生产力。
如果你还在观望，关注两个指标：Anthropic 服务条款的执行力度，以及核心维护者 Wei-Shaw 的活跃状态。前者决定了这个项目的存亡，后者决定了 2252 个 Open Issues 能不能被消化。一旦 Wei-Shaw 因任何原因停更，Fork 里的商业中转站大概率会涌现出各自的分支，但质量会参差不齐。
开源社区里有一种项目，解决的问题太真实、太痛了，以至于你明知道它在灰色地带还是会用它。Sub2API 就是这样。