QuantumNous/new-api

如果你所在的团队已经在多个模型账号之间来回切换，New API 值得先看一眼再决定。它需要你自己部署，不是托管服务。

解决什么问题

团队通常从零散的厂商密钥开始：一个客户端配 OpenAI，另一个配 Anthropic，再来一个配 Gemini 或本地服务。每上一个新应用，就要重做一遍密钥配置，费用和用量也分散在几个后台里。New API 改的是这一步：上游厂商只连一次，对外只暴露一套接口，客户端改为指向网关。结果是你有一个地方统一做路由、发放客户端密钥、查看用量与成本，而不用拼凑多个后台。

有什么不同

它的关键机制是在上游前面做协议转换。同一套部署同时接受 OpenAI Chat Completions 与 Responses、Anthropic Messages、Gemini 的 generateContent/streamGenerateContent，并在上游支持的前提下保留流式输出、工具调用、推理与多模态输入。也就是说，按 Claude 协议写的客户端可以接在由 Gemini 支撑的渠道上，不必重写代码。请求随后经过可配置的路由：模型映射、渠道优先级与权重、重试、渠道亲和，以及一个渠道配置多个上游密钥。

与只代理单一 API 相比，这是运维方式的改变：路由和重试规则集中在一处，新增厂商不必逐个改客户端。配额、订阅、用量日志、缓存计费，以及按用量分档的表达式定价，也都在同一个控制台里处理。

代价是你现在要维护一个处在关键路径上的服务。转换和路由都是额外的环节：同一个模型经过兼容层后行为可能不同，网关本身也成为需要监控和升级的对象。另外，它只适用于你合法持有、并且被允许在内部分发的上游访问权限。

谁值得试

适合已经拿到多家厂商授权访问、希望内部应用和 Agent 共用一个入口并集中管理配额与日志的团队或小公司。也适合想自建多模型服务、偏好网页控制台而不愿逐个客户端改配置的人。

如果你只是单个开发者、手里只有一个厂商密钥、也没有共享需求，那就不太合适：多一跳和一套管理界面带来的收益有限。指望项目本身提供模型访问的人也不适合，它路由的是你已经拥有的访问权限。

使用条件与边界

README 给出的本地方式是 Docker 容器加 SQLite，绑定本机地址，并挂载数据目录做持久化。这只是本地试用的起点，正式使用要自己规划存储与部署方式。项目采用 AGPL-3.0，并附加 Section 7 条款：修改版必须保留作者署名，并在界面上保留指向原仓库的可见链接。组织若不允许承担 AGPL 义务，可按 README 联系商业授权。

日常维护是实打实的：上游厂商、密钥、模型映射、定价表达式都要持续跟进；网关位于每个请求之前，它的升级和可用性会直接影响业务。

HotRepo 点评

HotRepo 的记录显示，2026-10-24 为 50,622 stars，2026-10-25 为 50,630 stars，两天出现在日榜上。只有两天的样本，还判断不了关注度是在上升还是消退。决定使用前，先读项目文档中关于协议转换的具体说明，并确认你的上游厂商允许你按计划进行内部分发。