xue-y-su/clove-api-1.0.6

如果你已经在运营一个多供应商 LLM 网关，并且需要合规确认、来源归属和公开余额查询这些附加能力，Clove API 值得试试；如果你在找一个经过独立验证的全新网关，现有证据还不足以判断。

解决什么问题

一个组织希望给 OpenAI、Claude、Gemini 等上游提供统一入口，同时集中管理密钥、用户、额度和费用。通常的做法是让各团队各自持有上游 Key，或者自己搭网关再配一套计费表格。用 Clove 的话，管理员在一个控制台里登记上游渠道和令牌，请求经过网关统一记录用量、执行限额。对使用者来说，变化是从管理员那里领 Key 而不是直接找供应商，并且可以在公开页面查看剩余额度。

有什么不同

Clove 基于 New API v1.0.0-rc.21，README 明确说明已合入该上游版本，Clove 在其上增加了若干功能。最有辨识度的是公开余额查询：/token-balance 页面和 POST /api/token-balance 接口让人只凭 API Key 就能查询剩余、已用和受限额度，无需登录。这对向外部用户发 Key 的团队能省掉不少支持来回，但也多了一个匿名入口，项目称通过脱敏 Key、禁用缓存和匿名限流来缓解。

另外两项增强偏向组织流程而非技术：合规声明系统支持带版本号、内容哈希、勾选确认和短语确认的声明，以及记录确认信息；来源归属系统由管理员配置选项、用户确认来源，两者都可以设为访问 Token API 的前置条件。服务受监管或机构用户时，这些把政策确认变成强制步骤；如果只是个人自建，它们只是额外配置，不是核心价值。项目同时保留 Default（React）和 Classic（Semi Design）两套前端，意味着两套界面要并行维护和配置。

谁值得试

合适的是已经熟悉 New API 式渠道和令牌管理、需要多模型计费和额度，并且明确需要合规确认、来源归属或公开余额查询的运营者；也适合必须把控制台和数据留在自己基础设施上的组织。不合适的是只想用一个 Key 调多家供应商的人，或者想要一个由上游持续维护的极简网关的人：这些增强才是选择它的理由，而 AGPL-3.0 义务和运维面是代价。如果把它当作全新的替代方案来评估，要注意项目自述是 New API 的增强集成，很多行为是继承来的，而非独立设计。

使用条件与边界

生产部署假定使用 Docker Compose、PostgreSQL、Redis，并由可信反向代理终止 HTTPS。首次启动前必须配置一批密钥，包括会话、加密、Token HMAC 和 Token 加密密钥，README 也提醒不要把填好真实密钥的 .env.production 提交进仓库。部署指南里的备份、回滚和监控流程值得在上线前读一遍，因为网关持有凭据和计费数据，丢失代价不小。

运维层面，项目要求运营者自行确保上游 Key、模型服务、支付、用户数据、内容安全、备案、许可、日志留存和税务合规；软件提供合规勾选项并不代表这些义务消失。Compose 默认把数据库连接池限制为 80 个打开连接，README 说明多节点部署时要按 PostgreSQL 的 max_connections 重新分配每节点上限。另外，仓库元数据没有声明许可证，尽管 README 提到 AGPL-3.0，二次分发前最好确认实际许可条款。

HotRepo 点评

HotRepo 在 2026-10-25 记录到 104 个总 star 和新项目榜第 10 名（注意是新项目榜，不是总榜），项目当时仅创建 3 天。榜单覆盖仅从 2026-10-24 到 2026-10-25，没有可比的每日历史，因此还无法判断关注度能否持续。采用前建议对照仓库核实 AGPL 许可的说法，并拿部署指南里的恢复步骤对照自己的备份方案看一遍。