CLIProxyAPI、Sub2API 和 New API 都能把多个上游接到同一个 API 地址，但它们解决的不是同一个问题：CLIProxyAPI 管自己的模型账号，Sub2API 管订阅账号池如何分给用户，New API 管模型请求如何分配到不同渠道。
选择时不用比较谁的功能更多，只要先确定自己需要管理什么。
三个项目的核心区别
| 项目 | 主要用途 | 上游资源 | 用户与计费 | 最小部署 |
|---|---|---|---|---|
| CLIProxyAPI | 统一自己的模型账号 | OAuth 账号、API Key | 不内置完整的多用户计费系统 | 单个程序、配置文件和凭据目录 |
| Sub2API | 把订阅账号池分给多个用户 | OAuth 账号、API Key | 内置用户、额度、计费、限流和支付 | 应用、PostgreSQL 15+、Redis 7+ |
| New API | 统一管理模型 API 渠道 | 模型厂商、云平台和兼容 API 服务商 | 内置用户、令牌、额度和成本管理 | 单个容器或程序加 SQLite |
最简单的判断是：
- 只管理自己的账号，选 CLIProxyAPI；
- 把订阅账号池分给多个用户，选 Sub2API；
- 管理多家模型 API 服务商和渠道，选 New API。
CLIProxyAPI：统一自己的模型账号
CLIProxyAPI 把 ChatGPT、Claude、Gemini 等账号转换成 OpenAI、Claude、Gemini 等兼容接口。客户端只需要连接一个 Base URL，就可以通过同一个入口调用多个上游账号。
它支持 OAuth 登录、多账号轮询、失败重试和协议转换。需要保存的主要是配置和账号凭据，不需要额外部署数据库或 Redis。
它适合个人使用，或者给少量彼此信任的客户端共享入口。如果需要给大量用户开户、分别计算余额和用量，它就不合适，因为这些不是它的核心能力。
具体部署方法见 CLIProxyAPI 简明部署指南；多账号路由和 Docker 选择见 CLIProxyAPI 如何管理多账号，以及是否需要 Docker。
Sub2API：把订阅账号池分给多个用户
Sub2API 面向的是多人共享订阅账号池。平台为每个用户生成独立的 API Key，再根据账号状态、并发限制和会话关系选择上游账号。
它内置用户管理、Token 用量计算、额度、并发控制、速率限制、粘性会话和支付接入。粘性会话会尽量让同一段会话继续使用同一个上游账号，避免上下文和缓存被打散。
这些能力依赖 PostgreSQL 15+ 和 Redis 7+。因此，即使只有少量用户，部署时也要维护应用、数据库和 Redis。
如果主要资源是 ChatGPT、Claude、Gemini 等订阅账号，并且需要把这些账号分配给多个用户，Sub2API 更合适。如果只有自己使用，它通常过重。
New API：管理模型 API 渠道
New API 主要管理 OpenAI、Anthropic、Google、Azure 和其他兼容服务商提供的模型 API。它可以根据模型、分组、倍率和权重，把请求分配到不同渠道。
它内置用户、令牌、模型权限、额度、成本核算和渠道管理，也支持 OpenAI、Claude、Gemini 等接口及部分格式转换。
New API 默认可以使用 SQLite，单机启动不需要 MySQL、PostgreSQL 或 Redis。需要多节点部署时，可以改用 MySQL 或 PostgreSQL，并按共享限流和缓存需求接入 Redis。
如果手里管理的是多家模型厂商或中转服务商的 API Key，需要统一渠道、模型、用户和额度，New API 更合适。如果核心资源是一组订阅账号，需要账号级并发和粘性会话，Sub2API 更直接。
应该怎么选
个人统一多个订阅账号
选择 CLIProxyAPI。它依赖少，配置和账号凭据容易备份，足以为 Codex、Claude Code、OpenCode 等客户端提供统一入口。
多人共享订阅账号池
选择 Sub2API。它负责用户 API Key、账号调度、并发、限流、用量和充值，代价是必须维护 PostgreSQL 与 Redis。
管理多个模型 API 服务商
选择 New API。它更适合按模型、渠道、分组和权重路由，也能管理用户令牌和额度。个人或小团队可以先使用 SQLite，不必一开始就部署外部数据库和 Redis。
使用前需要注意
订阅账号转换、共享和二次分发可能违反上游服务条款，也可能触发账号限制或封禁。技术上可以部署，不代表获得了上游授权。
本文只比较三个项目的产品定位和官方部署要求，没有进行性能压测、长期账号风控验证或代码安全审计。对外提供服务时，还需要自行评估支付、实名、内容安全、日志、税务和许可证等问题。