Sub2API 原理与合规边界：订阅账号转 API 到底是什么

它解决的是什么问题

官方 API 按 token 计费，网页订阅按月固定收费。一个 Claude Pro 订阅在重度使用下的等效 token 量，折算成 API 价格可能高出订阅费十倍以上。

这个价差就是 Sub2API 这类项目的空间：把订阅的「用量」变成可以转售的「额度」。

技术原理：三层结构

一、协议逆向

网页版订阅没有对外 API。所以要先把网页端的请求协议逆向出来：登录态如何维持、对话如何提交、流式响应如何解析。这一层是纯逆向工程，随上游前端改版而失效。

二、账号池

单个订阅账号有速率与并发限制，所以要把多个账号组成池子。池子的核心设计是调度：

• 轮询（round-robin）：均匀分发，简单但会让长对话断上下文
• 粘性会话（sticky session）：同一会话固定落在同一账号，保证上下文连续 —— 这是能用于 Agent / 长对话任务的前提

sub2api 这类实现的关键卖点就是「智能调度 + 会话粘性」，还有账号被限流时自动摘除、恢复后重新入池。

三、接口包装

对下游暴露标准协议（OpenAI 兼容 或 Anthropic 兼容），让你改个 base_url 就能用。同时做 token 级计费，方便按用量转售。

它在什么情况下会整体失效

这是使用前必须想清楚的一点 —— 失效模式是整体性的，不是渐进式的：

1. 上游前端改版：逆向协议失效，全池不可用，恢复时间取决于维护者的响应速度；
2. 风控策略调整：批量封号。账号池可能在一夜之间被清空；
3. 条款执行：上游明确禁止程序化访问订阅账号。这个风险不是「可能」，是「随时」。

对比一下失效模式：

• 官转站出问题 → 通常个别渠道不可用，可切换
• 逆向站出问题 → 通常整站不可用，无备用

三条边界

边界一：条款合规

上游的服务条款普遍禁止「通过自动化方式访问」以及「转售 / 共享账号」。使用这类服务首先要意识到：这不是技术灰区，是明确的条款违反。

风险分配上：

• 对服务提供方：账号被封、按条款追责；
• 对使用者：服务随时中断，且预付余额的追索缺乏依据（因为交易标的本身不被上游认可）；
• 对企业用户：如果业务链路依赖它，一次集体封号就是一次业务中断事件，且很难向内部解释为什么选了这个方案。

边界二：能力缺失

订阅账号没有官方 API 的这些能力：

• 批量 API（Batch）
• 提示缓存计费（cache_control）
• 稳定的 /v1/models
• 承诺的并发与 TPM/RPM 配额
• 结构化输出保证

也就是说，任何依赖上述能力的架构，都不能建在逆向站上。这不是质量高低的问题，是能力有无的问题。

边界三：预付风险

逆向站的价格优势建立在极低的边际成本上，同时也意味着它没有稳定的现金流支撑。加上整体性失效的可能，预充大额的风险显著高于官转站。

合理用法：按周或按月小额充值，把它当消耗品而不是长期基础设施。

那么它适合谁

诚实地讲，它有明确的适用面：

• 个人学习与试验：想低成本体验 Claude / GPT 的能力边界；
• 非关键的原型验证：快速验证一个想法，不投入基础设施成本；
• 低频、不可并发的个人任务：写作辅助、代码问答、日常问答。

反过来，不适合的场景也很清楚：

• 生产环境的关键链路（无论并发高低，因为可用性无保证）；
• 任何需要 Batch / 缓存 / 结构化输出的批处理任务；
• 需要向客户或同事承诺 SLA 的场景；
• 企业采购流程要求供应商资质与合规审查的场景。

怎么识别一家站是不是逆向

三个迹象：

1. 不返回真实 /v1/models，或返回的清单里模型名与官方不一致；
2. 报错文案不像官方：官方报错结构规整、有 type 与 code 字段；逆向站的报错常常是自定义文本；
3. 价格低于官方价 20% 且不支持 Batch / 缓存：价格与能力同时指向订阅池。

本站收录时会在详情页标注「底层引擎」与核验状态。看到标注为账号池类底层的站点，把它放在「试用」而不是「生产」栏里。