- cesign2026-09-02
项目地址
https://github.com/gesta-run/subpool
, 兄弟们，求 Star, tar, ar, r...背景
最近在做团队内部的 AI 订阅管理，遇到几个比较实际的问题：
- 团队有多份 Codex 或 API 账号，缺少统一管理入口
- 不清楚成员的被分配到了哪个账号
- 账号额度、健康状态和使用情况比较分散
- 部分成员用量较高时，需要人工切换账号
因此做了 Subpool 。
Subpool 是一个面向团队的轻量化 AI 订阅管理工具。管理员可以接入团队有权使用的 Codex 或 OpenAI-compatible 账号，组成 Pool ，再给成员分配独立 API Key 。
目前支持：
- Codex Device Code 授权
- 多订阅账号统一接入
- Pool 化管理和请求路由
- 团队成员独立 API Key
- Key 与上游账号分配关系
- 账号健康、额度和冷却状态
- Token 用量统计
- Responses 、Chat Completions 和 Models API
- Codex 与 API 账号混合池
- Docker Compose 自托管
Subpool 不保存 Prompt 、回复或源代码，只记录账号分配、路由状态和 Token 用量。
技术上是一个 Go 服务，内嵌 React 控制台，使用 PostgreSQL ，部署比较简单。
市面上已经有 sub2api 。Subpool 不打算做功能上的重复竞争，定位更偏团队内部管理：不做支付、套餐和 Key 售卖，重点解决订阅接入、成员分配、容量治理和使用审计。
简单来说：
Subpool 想做的是团队 AI 订阅的管理层，而不是另一个卖 Key 平台。
欢迎体验，也想听听大家的意见：团队订阅管理场景里，还缺哪些关键能力？
主楼 - Kinnice2026-09-02
关键能力：不被封号
- cesign2026-09-02
- crackhopper2026-09-02
客户端一键配置，以及客户端网络接入问题。
我个人更希望比如类似这里的 subpool 的东西，部署到海外机器上。这样似乎封号风险会降低？（我也不太了解，欢迎拍砖。）
我虽然觉得，代理池部署国内节点，然后这个节点走单独的网络链路，也是一个方。不过不管哪个都需要一个稳定的网络链路的解决方案，其实和上面的也没太大差。无非是网络方案在服务器还是在客户端上。
但更进一步考虑，比如代理池不是直接请求外部 api ，而是直接对一些 coding agent 的 cli 进行封装，那么部署海外节点风险似乎更低。（并且，我觉得有的供应商就是只允许自家 cli 接入，也不提供 api 接入，这种情况说不定还会在 cli 上做各种探测动作，发现 ip 或者什么东西不对，就触发风控，也挺恶心的） - Kinnice2026-09-02
tls 指纹和官方对齐
- vexify2026-09-02
我在用 sub2api 感觉没啥问题，除了审计，我加了一个小组件，把请求响应都保存下来，每天压缩到 S3
- cesign2026-09-02
@crackhopper 还是各种实验中，看怎么最稳定，后续更新
- vexify2026-09-02
需要能长期跟进 sub2api 或者 cpa 的风控能力吧
- Mandyer2026-09-02
支持 gpt 的指纹和 ws 功能吗？
- deqiying2026-09-02
支持 codex 的 websocket 吗
- liuhamood2026-09-02
希望能尽快支持国模，MiniMax
- cesign2026-09-03
- cesign2026-09-03
- Leon68682026-09-03
路由会考虑前缀缓存吗？截图中没有显示五小时限制，实现是否有考虑？