把 AI 订阅当 API 用：cc-switch / Sub2API / CLIProxyAPI / Cockpit 这四个词到底谁是谁

先把结论摆前面：这四个工具经常被混在一起问，是因为它们都围着「把 AI 订阅账号当 API 用」这件事转，但站的层次完全不同。 一个在你本机切配置，一个在服务器上做网关，一个做协议翻译，一个在本地管一堆 IDE 的账号。搞清楚谁在哪一层，就不会再纠结「我到底该装哪个」——很多时候答案是「组合着用」。

先上一张总览表，后面再逐个拆。

一句话记忆法：cc-switch 管「客户端指向谁」，Sub2API 管「多人怎么共用」，CPA 管「协议怎么翻译」，Cockpit 管「本地一堆账号谁还活着」。

一、cc-switch —— 客户端这头的「换挡杆」

它其实和另外三个不是一个方向的东西，所以我单独放最前面澄清。

CPA、Sub2API 都是在上游给你造出一个能用的 API 端点；cc-switch 是在下游——你已经手握一堆端点（官方 Key、第三方中转、自建 CPA 出来的地址……），它帮你在这些 provider 之间一键切换，不用每次手改 ~/.claude/settings.json 或 shell 环境变量。

它管的工具不止 Claude Code：Claude Code、Claude Desktop、Codex、Gemini CLI、Grok Build、OpenCode、OpenClaw、Hermes 都能纳进来。关键特性：

1、配置管理是主业——切 provider 时它直接把配置原子写入各工具的原生配置文件（.claude/settings.json 之类），改完重开终端生效。 2、可选的本地代理模式——内置一个能热切换的本地代理，可以拦截并转换请求，做到自动故障转移、格式转换、不重开终端就换 provider。 3、50+ 内置 provider 预设、一键导入；系统托盘快捷切换；MCP 服务器的双向同步管理；用量看板；配置走 Dropbox/OneDrive/iCloud/WebDAV 云同步。基于 Tauri 2，Windows/macOS/Linux 三平台。

[ 记住它的边界：cc-switch 自己不产生额度、不转换订阅，它只是决定「你的 CLI 这一刻打给谁」。上游端点哪来的，是下面三个的事。 ]

二、Sub2API（CRS2）—— 服务端的「拼车运营平台」

Wei-Shaw/sub2api，Go 写的，部署在自己服务器上的服务端网关。核心动作：把 Claude、OpenAI、Gemini 等的订阅配额转成标准 API 对外提供。

它长成「运营平台」的样子，是因为它假设的场景就是多人共用：

上游兼容 OAuth 授权、API Key、Antigravity 订阅等多种账号类型。「支付 + 限流 + 仪表盘」这一整套，就是它定位在「拼车运营」而不是「个人自用」的信号。

三、CPA = CLIProxyAPI —— 复用 OAuth 的「协议翻译层」

router-for-me/CLIProxyAPI，一个给 CLI 工具提供 OpenAI / Gemini / Claude / Codex 兼容接口的代理服务器，把授权、账号管理、协议兼容、轮询负载均衡整合到一起。支持 Claude Code、Codex、Gemini、Qwen、iFlow、Antigravity 等主流服务的 OAuth 认证，多账号热重载、轮询、模型映射。

它和 NewAPI / OneAPI 那类聚合器有个本质区别，这点最容易被问：

OneAPI / NewAPI 聚合的是「API Key」，CLIProxyAPI 聚合的是「账号认证」。 它不中转 Key，而是通过 OAuth 复用你已有的官方订阅账号。

管理界面从 6.0.19 起随主程序一起发布，服务跑起来后访问 API 端口上的 /management.html。它只调 /v0/management 改配置、传凭据、看日志，不参与流量转发——管理面和数据面是分开的。

四、Cockpit Tools —— 本地的「账号仪表盘」

jlcodes99/cockpit-tools，跑在本地的桌面应用，专门集中管理各种 AI IDE 和编程助手的账号与运行环境。

一块仪表盘同时展示 Antigravity IDE、Codex、GitHub Copilot、Windsurf、Kiro、Cursor、Grok CLI、CodeBuddy、Qoder、Trae、Zed 等十几个平台的账号状态，实时看各模型剩余配额和重置时间。还支持同一平台多账号多实例并行——比如开两个 Antigravity 分别绑不同账号跑不同项目。

有意思的一点：它自带的本地 Codex API 服务，其实是内置 CLIProxyAPI 当 sidecar 在驱动，Cockpit 自己只负责账号同步、配置投影和用量统计。所以你可以把它理解成「给 CPA 套了个盯账号的本地壳」。

那 Cockpit 纯用来看额度，是不是就没封号风险？

常有人这么问，直觉也没错——纯监控是这几种用法里风险最低的，单账号自己看基本可以当没风险。 但「总不存在」还是得打个折。风险从来不来自「读」这个动作本身，而来自另外三件事：

1、它怎么登录、怎么存 token。 要显示配额，Cockpit 得先以你的账号身份认证，再去打各平台的用量/账号接口。它是个非官方客户端：请求签名、User-Agent、调的是不是官方暴露的端点，都可能和真·官方客户端对不上。风控真要抓异常，抓的是「这串 token 的行为特征不像官方 App」，而不是「你查了几次余额」。尤其如果导入的是网页 session 转来的 token（没有正常的 refresh_token），这本身就是异常特征——和前面说 CPA 那条同理。

2、你在一台机器上堆了几个账号。 单账号自己看，行为接近真人、无并发、频率极低，安全；但 Cockpit 的卖点恰恰是一屏盯十几个平台、同平台还能多账号并行——一旦往里塞一个账号池，哪怕只是「读」，同一指纹批量拉多个账号的配额，也开始有「这是被集中托管的账号」的味道。

3、别忘了那个 sidecar。 上面说过，它的本地 API 服务是内置 CLIProxyAPI 在驱动。只要你没开这个、没让它真去跑模型流量，你就还在「看额度」这一层，安全；一旦用它对外发 API、路由模型请求，那已经不是看额度了，直接回到 CPA / Sub2API 那套封号风险里去。

[ 一句话：风险边界是「读 vs. 跑流量」和「一个账号 vs. 一池账号」，不是「Cockpit 这个工具」本身。踩住这两条边界，纯看额度可以近似当无风险。 ]

五、它们怎么组合

把四层叠起来看就顺了：

上游接入 / 协议转换   ← CPA / Sub2API（造出可用端点）
统一管理             ← NewAPI（可选，聚合 Key、做统一计费口）
本地账号盯盘         ← Cockpit Tools（盯着一堆账号活没活）
客户端切换           ← cc-switch（决定 CLI 这一刻打给谁）

1、CPA / Sub2API 做上游接入层——负责资源转接和接口转换（订阅 → API）。 2、NewAPI 做统一管理层——如果你还想在中间聚合一层 Key、做统一计费，就加它；不需要就不加。 3、Cockpit Tools 偏本地账号管理，NewAPI 偏服务端 API 管理，CPA / Sub2API 偏资源转接和接口转换——这三句是最省事的区分口诀。 4、cc-switch 在最下游，把上面造出来的一堆端点收进一个切换器。

六、真问题：CPA 和 Sub2API，哪个更容易封号

这是被问最多的一个。结论直接给：Sub2API 明显更高，而且不是因为代码质量，是因为使用模式本身。

关键在于——风控看的不是你用了什么工具，而是账号的行为特征。 CPA 的典型场景是一个人本地跑：一个 IP、串行请求、频率接近真人写代码；Sub2API 的典型场景是一池账号 + 一群用户 + 长期高并发，这在上游眼里就是「个人坐席被当成 API 服务在卖」。sub2api 的核心价值绑在一个灰色商业模式上——把个人订阅转成多人 API，这件事本身踩 ToS，而且依赖上游协议不变。

具体的风险差异：

有两点要说清楚，避免误判：

1、CPA 不等于安全。 如果你用 CPA 开远程管理、挂十几个账号轮询、或者导入的是网页 session 转来的 token（没有 refresh_token、认证特征异常），风险不比 Sub2API 低多少。CLIProxyAPI 的风险也不完全来自它自己，而是强依赖被封装的 CLI 生态是否稳定——上游一改 OAuth 或客户端签名，这类工具就集体失效。

2、两者都违反各家服务条款。 以 Anthropic 为例，订阅卖的是个人席位，明确禁止共享账号、禁止把订阅额度再分发；封号通常不带申诉余地，Max 这类高价订阅损失更大。所以「哪个不容易封」这个问题的实际答案是：把订阅当 API 用本身就是被禁止的行为，工具只影响被发现的快慢。

最后一句正经话

这几个工具本身是中立的，但用它们做账号共享、接口倒卖基本都踩各家 ToS，个人自用也有封号风险。

如果目的是团队共用，官方 Team / 企业方案或正规 API 计费虽然贵，但不会某天早上突然全员失效——按自建服务的经验，这种「依赖上游默许」的架构，维护成本往往比省下的钱高。个人一个人多机器用，CPA 是这几个里更保守的选择；真要拼车运营，那就要做好整池随时一起没的准备。