比较专题

CLIProxyAPI VS sub2api VS GPT-Load

CLI 订阅转 API 的三条路线：自用代理内核 · 运营级网关平台 · 自持管理型网关，一场「内核 / 整机 / 平台」的三方对决。

router-for-me/CLIProxyAPI Wei-Shaw/sub2api tbphp/gpt-load Go × 3 MIT × 2 / LGPL-3.0 53.6k ★ / 43.1k ★ / 7.0k ★

数据采集于 2026-09-30 · GitHub API + 三方 README_CN（首发 2026-08-22，本次加入 GPT-Load 并全量刷新）

← 返回汇总
TL;DR

一句话裁决

分水岭从一条变两条：
要不要「分给别人」？
要不要「自己管起来」？

CLIProxyAPI —— 给自己用

把自己的订阅变成本地统一 API。单二进制、零依赖、五分钟跑通，只管「能调通」。

sub2api —— 分给别人用

把订阅做成平台：多用户、多租户、Token 级计费、自助充值。拼车 / 收费运营无敌。

GPT-Load —— 自己管起来

订阅 + API Key 同池调度：AccessKey 签发、用量归因、权重/冷却/拉黑。管起来，但不做支付。

先看清关系

它们不是并列竞品：GPT-Load 内嵌 CPA

CPA · 内核供应商
订阅 OAuth 适配的事实标准
五套下游协议 + 六路订阅上游。被 gpt-load 以 third_party/cpaembedded 方式内嵌——gpt-load 的 Codex/Claude/Antigravity/Grok 订阅能力全部由它完成。
GPT-Load · 整机厂
CPA 内核 + Bifrost + 管理层
Bifrost Core（Apache-2.0）做协议转换与流式归一；自研 37 模块做调度、健康、亲和、日志、用量。上游 OAuth 变更时，修复从 CPA 上游开始，gpt-load 要等 re-vendor。
sub2api · 另一家整车厂
独立自研内核
不基于 CPA，自研订阅适配 + 计费平台，413 贡献者众包共建。与 CPA 无血缘，更新节奏取决于自家 issue 队列（3.5k open）。

选 gpt-load ≠ 摆脱 CPA 依赖——只是把它藏进内部。三方真正的分层是：CPA 是内核，gpt-load 是「内核 + 管理层」的整机，s2a 是「自研内核 + 运营平台」的整车厂。

硬数据

仓库体量对比 （2026-09-30，GitHub API）

指标CLIProxyAPIsub2apiGPT-Load
Stars53,61243,1187,019
Forks8,0779,213779
创建至今15 个月（2025-07）9.4 个月（2025-12）15.8 个月（2025-06）
Star 增速≈ 4.0k / 月≈ 3.3k / 月≈ 440 / 月
Commits4,1067,3751,382
贡献者23441322
Open Issues6713,48018
Release 节奏v8.0.4 · 约每日一版v0.2.11 · 约 2–3 天一版v2.0.0-rc.38 · 数日一版
外部依赖无PG 15+ / Redis 7+无（SQLite 内置，可切 MySQL/PG）
版本阶段v8 稳定线v0.2（未承诺稳定）2.0 RC（完整重写，不迁 1.x）
LicenseMITLGPL-3.0（+CLA）MIT（含 Bifrost/CPA 致谢）

三者推送均为 2026-09-30 前后——全部处于日更级活跃。GPT-Load 体量最小但 issue 负担最轻（18 vs 671 / 3,480）。

本质定位

同赛道，三种物种

CLIProxyAPI · 单进程代理
  • 形态：Go 单二进制 + config.yaml
  • 外部依赖：无（DB/缓存都不需要）
  • 用户体系：无，只有一层 API key
  • 计费：无（v6.10 起剥离给第三方生态）
  • 管理：Management API + 社区面板
sub2api · 全栈运营平台
  • 形态：Go(Gin+Ent) 后端 + Vue3 前端
  • 外部依赖：PostgreSQL 15+ / Redis 7+
  • 用户体系：注册 / 登录 / 分组 / 多租户
  • 计费：Token 级账单 + 四渠道自助支付
  • 管理：自带 Web 后台 + 移动端 App
GPT-Load · 管理型网关
  • 形态：Go 单二进制，内嵌 Web 管理界面
  • 外部依赖：无（SQLite 默认，可切三库）
  • 用户体系：AccessKey 签发（分组/协议白名单）
  • 计费：成本估算 + 用量归因，无支付
  • 管理：官方内嵌 UI（分组/健康/日志/用量）

CPA 回答「怎么接进来」，s2a 回答「怎么卖出去」，GPT-Load 回答「怎么管起来」——三问可以同时成立。

架构对比

请求链路：三条不同的路径

CLIProxyAPI
客户端 SDK→ CPA 单进程→ CLI 上游
  • 无状态，内存轮询账号池
  • 可选集群模式（compose 编排）
  • 可复用 Go SDK 嵌入自家产品
sub2api
用户/Key→ 网关鉴权→ 调度计费→ 账号池→ CLI 上游
  • PG 持久化账单，Redis 队列缓存
  • 粘性会话（Nginx 需 underscores 头开启）
  • 可选 datamanagementd 数据组件
GPT-Load
应用+AccessKey→ Group 策略→ 调度/健康→ Channel 凭据池→ 上游
  • 权重 + 冷却 + 拉黑 + 会话亲和
  • Bifrost 协议转换，CPA 内嵌管订阅
  • 三库可切，凭据本地加密落盘
横向扩展
都能扩，方式不同
CPA 集群 compose；s2a 标准三层天然水平扩展；gpt-load 单实例为主（OAuth 固定回调端口限制同机单实例）。
状态管理
无 → 全量
CPA 内存态；s2a PG+Redis；gpt-load 单 DB（默认 SQLite）+ auth.key/encryption.key 三件套。
故障半径
进程 vs 链路 vs 数据
CPA 挂了重启即恢复；s2a 要排查组件链路；gpt-load 重启快但 encryption.key 丢失=凭据报废。
CLIProxyAPI 深度分析

核心能力清单

上游接入 · 6 路

Claude Code / Codex / Grok Build OAuth 登录，Gemini AIStudio API key + Antigravity，Kimi OAuth（官方赞助合作），外加任意 OpenAI 兼容上游。

下游协议 · 5 套

暴露 OpenAI（含 Responses）/ Gemini（含 Interactions）/ Claude / Codex / Grok 兼容端点，任何主流 SDK 直连。

多账户轮询

全上游多账户轮询负载均衡，CLI OAuth 认证流程简单。

零依赖部署

单二进制或 docker run，config.yaml 一把梭，五分钟出活。

桌面客户端

官方 EasyCLIProxyAPI：图形配置、托盘、一键启停、自动更新。

可复用 Go SDK

代理内核可直接嵌入自家 Go 项目——gpt-load 正是这么用的（cpaembedded）。

CLIProxyAPI 深度分析

优势与短板

优势
  • 部署门槛近乎为零：无 DB、无缓存、无前端
  • MIT License：可商用、可闭源二开
  • 协议兼容最全：五套下游端点业界领先
  • 订阅适配最快：上游 OAuth 变更它是第一修复现场
  • issue 负担轻：671 open，文档站三语手册
短板
  • 无用户体系 / 计费 / 限流：分发场景完全做不了
  • 统计靠第三方：v6.10 起官方剥离给生态项目
  • 调度仅轮询：无权重、无粘性、无冷却黑名单
  • 管理无官方 UI：依赖 CPAMC 等社区面板
sub2api 深度分析

核心能力清单

API Key 分发

为终端用户生成/管理 Key，配额、有效期、分组隔离，多租户开箱即用。

Token 级计费

精确到 Token 的用量追踪与成本核算，请求级日志可审计。

内置支付

EasyPay / 支付宝 / 微信 / Stripe 四渠道自助充值，无需独立支付服务。

智能调度

账号智能选择 + 粘性会话（session_id），用户级/账号级并发与速率限制。

管理后台

Vue3 Web 后台监控管理，iframe 嵌工单等外部系统，社区有 Expo/RN 移动端。

Antigravity 专用端点

/antigravity/v1/messages（Claude）与 /antigravity/v1beta（Gemini），支持混合调度。

sub2api 深度分析

优势与短板

优势
  • 运营功能唯一完整：计费+支付+分发+限流全内置
  • 调度强：粘性会话 + 智能选号 + 双层限流
  • 共建最猛：413 贡献者 7.4k commits
  • 工程规范：openspec + DEV_GUIDE + CLA
短板
  • 重部署：PG15 + Redis7 + 前后端全家桶
  • 支持压力大：3.5k open issue 排队求助
  • v0.2 版本号：API 尚未承诺稳定
  • LGPL-3.0 + CLA：魔改分发受传染性约束
GPT-Load 深度分析

核心能力清单

双凭据同池

API Key 渠道与订阅渠道（Codex/Claude/Antigravity/Grok，OAuth）共享同一套调度、健康与亲和体系——订阅账号是一等公民。

调度与故障隔离

权重选路、失败冷却、连败拉黑、会话亲和、RPM 与配额限制，凭据过载不拖垮全量流量。

AccessKey 签发

给应用的每个消费方发独立 Key：限定可访问 Group 与客户端协议，用量按 Key 归因。

协议转换矩阵

9 类客户端协议（含 Responses/Rerank/Mistral 原生）× 30 个内置渠道（含 Azure/Bedrock/Vertex），Bifrost 引擎驱动。

可观测内嵌

请求日志、缓存命中率、Token 分类、成本估算全部内置于管理 UI，数据落自家库。

安全默认

默认环回监听不暴露公网，管理面/数据面密钥分离，凭据本地加密（encryption.key）。

GPT-Load 深度分析

优势与短板

优势
  • 中间地带唯一解：Key 签发 + 用量归因 + 智能调度，且不用背上支付全家桶
  • 渠道覆盖最广：订阅 + API Key + 官方云平台（Azure/Bedrock/Vertex）统一管理
  • 调度最完整：权重/冷却/拉黑/亲和/配额，超出轮询与粘性
  • MIT + 单二进制：内嵌 UI，SQLite 默认零外部依赖
  • issue 负担最轻：18 open，RC 阶段数日一版
短板
  • 2.0 尚在 RC：完整重写且硬断代（1.x 无迁移路径），API 仍在 churn
  • 密钥不可恢复：encryption.key 丢失=凭据报废，暂不支持主密钥轮换
  • 订阅修复慢一拍：内嵌 CPA，上游 OAuth 变更要等 re-vendor
  • 单机单实例：OAuth 固定回调端口（1455/54545/51121）限制
  • 无支付/用户注册：真要做拼车收费仍不够
横评打分

11 维度评分 （10 分制，绿块为胜出方）

维度CLIProxyAPIsub2apiGPT-Load
下游协议兼容
9.5
8.5
8.5
上游覆盖
9.0
8.5
9.0
部署门槛
9.0
6.0
8.0
账号池与调度
7.5
9.0
9.0
多租户与计费
2.0
10
6.5
管理界面
6.0
9.0
8.5
架构与扩展
8.5
8.0
7.5
文档质量
8.5
7.5
8.0
社区生态
8.5
7.5
6.5
维护健康度
9.0
7.5
8.0
License 友好度
10
6.5
9.0

简单平均：CPA 8.0 · s2a 8.0 · GPT-Load 8.0 —— 三方打平，胜负完全取决于场景权重（见后页）。GPT-Load 在「上游覆盖 / 调度」追平最强项，在「社区生态 / 版本成熟度」垫底。

能力矩阵

上游与下游支持对照

能力CLIProxyAPIsub2apiGPT-Load
OpenAI Codex（OAuth）✓ 多账户轮询✓✓ OAuth / 凭据导入
Claude Code（OAuth）✓ 多账户轮询✓ 粘性会话✓ OAuth + 会话亲和
Gemini✓ AIStudio + Antigravity✓ Antigravity 端点✓ Vertex AI + Antigravity
Grok Build（OAuth）✓ 多账户轮询✓✓
Kimi✓ 官方赞助合作README 未提及✓ Moonshot API Key 渠道
官方云平台（Azure/Bedrock/Vertex）✗ 经兼容上游绕行部分✓ 内置 7 家原生模板
任意 OpenAI 兼容上游✓ config 直接接入✓ API Key 账号模式✓ 自定义渠道
OpenAI Responses 协议输出✓✓✓
计费 / 支付 / 用户注册✗ 靠第三方✓ 全内置✗（有用量归因，无支付）
凭据调度（权重/冷却/拉黑）✗ 仅轮询✓ 智能 + 粘性✓ 四件套全有

共同交集覆盖 Claude / Codex / Gemini / Grok 订阅与兼容上游；GPT-Load 独占「云平台原生 + 官方 Key 渠道统一管理」，s2a 独占「支付与租户」。

部署与运维

从零到可用：5 分钟 / 半天 / 10 分钟

# CLIProxyAPI —— 三行出活
docker run -d -p 8317:8317 \
  -v $HOME/.cli-proxy-api:/app \
  ghcr.io/router-for-me/cliproxyapi

# 浏览器 OAuth 登录即用

零状态零依赖；还有桌面端一键启动。

# sub2api —— 全家桶编排
# postgres:15  redis:7
# sub2api-backend/frontend
# datamanagementd（可选）
# 创建管理员→配置上游与支付

Nginx 反代需开 underscores 头，否则粘性会话失效。

# GPT-Load —— 10 分钟带库带 UI
git clone --depth 1 .../gpt-load.git
cp .env.example .env
docker compose up -d
# 读首启管理密钥登录控制台
docker compose exec gpt-load \
  sh -c 'cat /app/data/auth.key'

SQLite 默认零外部依赖；备份 db + 双密钥三件套。

社区与生态

三种生长方式

4.0k
CPA Star / 月
3.3k
s2a Star / 月
440
GPT-Load Star / 月
CPA · 周边工具型

README 收录 20+ 第三方项目：CPAMC 管理中心、Usage Keeper 统计、Tray 托盘、VSCode 插件——官方做内核，社区补外围。

s2a · 贡献者众包型

413 贡献者 7.4k commits 高强度共建，支付/移动端由社区吸收内置。代价是 3.5k issue 求助排队。

GPT-Load · 单核快跑型

22 贡献者、18 open issues、RC 数日一版；获 OpenAI 平台支持与 DigitalOcean 基础设施支持，体量最小负担最轻。

场景决策

八个典型场景对号入座

场景推荐理由
个人：把订阅喂给本地编码工具CLIProxyAPI5 分钟部署，无 DB，随便折腾
小团队共享订阅，只要「能调通」CLIProxyAPI+ CPAMC 面板即可，无需数据库
小团队要「每人一个 Key + 看谁用了多少」GPT-LoadAccessKey 签发 + 用量归因 + 内嵌 UI，无需支付全家桶
API Key 渠道与订阅账号想统一进一个网关GPT-Load双凭据同池，可替代「LiteLLM 类 + CPA」双组件组合
凭据池大、常撞限流，要权重/冷却/拉黑GPT-Load调度四件套最完整（CPA 仅轮询）
拼车 / 对外分发 / 收费运营sub2api计费、Key 分发、限额、支付全内置
企业内部多团队额度管控sub2api用户级配额 + 审计；介意 LGPL 则 GPT-Load
嵌入自家产品做二次开发CLIProxyAPIMIT + Go SDK，法律与集成成本最低
共同风险

选谁之前，先看这五条

最终裁决

结论

自用选 CPA，分钱选 s2a，
「管起来」选 GPT-Load。

综合评分（按通用权重）：CPA 8.0 · s2a 8.0 · GPT-Load 8.0 —— 但请永远用场景权重替代总分。

在线体验

还在纠结？30 秒测出你的答案

交互式选型决策器：回答 5 个问题（使用规模 / 计费需求 / 管理需求 / 运维承受力 / License 敏感度），在三方中即时得到推荐与风险提示。

打开三方选型决策器 →
上一个
Modular
下一个
Archify
1 / 20
← → 翻页 · 汇总 · Playground