API Key 多到记不住？这个开源 AI 网关，帮我把所有模型套餐“一网打尽”！

APIKey多到记不住？这个开源AI网关，帮我把所有模型套餐“一网打尽”！

大家好，我是星哥。最近这段时间，星哥一直在深度折腾各种 AI 编程工具。从 Cursor 到 Claude Code，再到自己写的一些自动化脚本，用得是不亦乐乎。

但用着用着，一个非常现实且让人头疼的问题就暴露出来了：API 和套餐越买越多，管理起来简直要命。

你的 AI 配置，是不是也成了一锅粥？

一开始，可能只是充了一个基础模型的 API。 后来为了写代码丝滑点，买了几个 Coding Plan；为了跑批量任务，又开了几个 Token Plan；看到哪个平台打折、哪个模型效果好，顺手又接了几个。

结果就是，星哥手里攒下了一堆“资产”：

• • 一堆不同的 Base URL

• • 一堆各种平台的 API Key

• • 一堆记不住的模型名

• • 一堆分散的套餐额度

最痛苦的莫过于“配置”和“切换”。

Cursor 里要配一次，脚本里要配一次，内部工具还要配一次。某个 Key 快用完了，得挨个平台去查余额；想临时把某个客户端切到另一个更聪明的模型，还得去改 Base URL、换 API Key、改模型名……

讲真，这时候真正折磨我们的，已经不是“没有模型可用”，而是入口太散、账单太碎、管理太乱。

我就在想，能不能有个统一的地方，把这些乱七八糟的模型 API、Coding Plan、Token Plan 全接进去，对外只给我一套 Base URL 和 API Key？

带着这个需求，星哥最近挖到了一个非常对胃口的开源项目：OctaFuse Gateway。

OctaFuse Gateway

Octafuse Gateway 是以 npm workspaces 组织的单仓：共享 @octafuse/core，对外提供 推理 Proxy（OpenAI / Anthropic / Gemini 兼容），以及面向运维与自动化的 Admin（Next.js 16 + OpenNext）。

• • 统一接入入口 — 客户端一个 Base URL、一个 API Key；兼容 OpenAI / Anthropic / Gemini 等协议，背后路由到任意已配置上游

• • 密钥与预算 — 用户 / Key 管理、预算上限与周期重置、 GET /v1/me 额度查询

• • 路由与容错 — Provider / Model / Route 管理，route group 与优先级 failover

• • 计费与对账 — metered_cost / standard_cost / charged_cost 三套成本口径

• • 审计与观测 — 全局与按 Key 的请求日志、用户级审计轨迹

• • 错误告警 — 管理台配置飞书 / 企业微信 Webhook，Proxy 转发失败时主动推送

• • 用量分析 — 管理台按时间范围汇总模型、供应商、用户用量及可靠性概况

• • 联调与自检 — Playground 单路由试调用（不占用户额度）；Simulator 浏览器内模拟客户端调用

• • 灵活部署 — Cloudflare（Worker + Pages + D1）或自托管（Docker / Node + Postgres / MySQL）

• • Admin API 集成 — 门户与业务系统通过 /api/admin/* 对接，自动开通用户、创建 Key、同步预算

很多同行可能用过一些模型代理工具，但 OctaFuse Gateway 的格局要大得多。

它不是单纯地帮你“转发”几个请求，而是把 Provider 管理、模型路由、API Key 池、用户权限、预算控制、用量审计、财务记账 全部整合在了一起。

用一句话概括星哥的体验：

OctaFuse Gateway 想做的不是“多转发几个模型”，而是把 LLM 接入做成一套可管理、可审计、可计费的基础设施。

对于咱们个人重度玩家，它是多模型统一控制台；如果你在做 SaaS 产品，它直接就能当产品里的 LLM 服务底座。

下面星哥给大家拆解一下，它到底解决了哪些核心痛点。

痛点一：客户端配置重复，换模型如脱层皮

解法：统一入口与 Route 路由

现在大部分 AI 客户端都支持自定义 OpenAI 兼容接口。以前接多个供应商，每个客户端都要填一遍配置。

用了 OctaFuse，体验就像加了一个“总控台”。 你在网关里配好各种 Provider 和模型，对外只暴露一个统一的 Base URL 和 API Key。客户端里只需要填一个虚拟的模型名（也就是 Gateway 里的 Route）。

最爽的是什么？ 假设你今天觉得 A 家的代码模型好用，明天发现 B 家的更便宜。你根本不需要去改 Cursor 或者脚本的配置，只需要在 Gateway 后台把 Route 指向换一下，所有客户端瞬间无感切换！这就把“模型选择”和“客户端配置”彻底解耦了。

痛点二：多套餐额度分散，无法统一调度

解法：Provider API Key 池与智能调度

这是星哥最喜欢它的地方（v1.4.0 引入的神级功能）。

真实场景里，咱们手里往往不止一个 Key。有的对应 Coding Plan，有的对应 Token Plan，有的专门跑测试。散在各处根本没法统筹。

OctaFuse 允许你给同一个 Provider 配置多条上游 Key，并且可以给每条 Key 设置：

• • Label（标签）

• • Status（状态）

• • Weight（权重）

• • Priority（优先级）

网关会按优先级进行 Failover（故障转移），同批次里按权重随机分配。如果某个 Key 报错，还会自动进入冷却期（默认 60 秒）避开它。

这意味着什么？ 你可以把余额充足、稳定的 Key 设为高优先级；把便宜的 Token Plan 设为低优先级或者按权重分流。多套额度终于能像“池子”一样统一调度了，再也不用手动切 Key 了！

痛点三：不仅兼容 OpenAI，还要兼容百家

解法：多协议入口

很多网关只支持 OpenAI 格式，但现在的生态里，Anthropic (Claude) 和 Gemini 的调用形态并不一样。 OctaFuse 直接提供了 /v1/chat/completions (OpenAI)、/v1/messages (Anthropic) 和 /v1beta/* (Gemini) 多种协议入口。前端工具爱用什么协议，网关就接什么协议，底层统一收口。

给 SaaS 产品提供 LLM 底座

如果说上面的功能只是让个人玩家爽，那接下来的能力，就是为 SaaS 团队量身定制的。

现在很多 SaaS 产品都在加 AI 功能（AI 写作、AI 客服、AI 数据分析等）。一开始大家可能直接在业务代码里调 API，但很快就会遇到一堆“非业务核心”的脏活累活：

• • 用户的 Key 怎么发？权限怎么控？

• • Token 用量怎么统计？超预算了怎么拦截？

• • 出错了怎么审计追踪？

• • 最要命的：财务怎么算账？

OctaFuse 把这些全沉淀到了网关层。特别是它的三层财务记账模型，星哥觉得非常懂行：

成本口径

星哥大白话解释

metered_cost 进货价

（上游模型实际扣你的钱）

standard_cost 目录价

（平台标准定价）

charged_cost 卖价

（你向最终用户收取的费用）

把“采购成本”和“商业定价”分开，内部用户走成本价，外部客户走溢价，或者做套餐赠送超额扣费……这些复杂的逻辑如果在业务代码里写，绝对是一场灾难。交给 Gateway，业务系统就能轻装上阵，只专注产品逻辑。

此外，它还自带了一个非常完善的 Admin 管理后台。产品经理看用量、财务看成本、工程师查日志，不用再去翻数据库了。内置的 Playground 和 Simulator 还能直接在浏览器里模拟调用，排查问题极其方便。

怎么安装OctaFuse？

说了这么多，怎么部署呢？OctaFuse 支持 Docker 自托管，也支持 Cloudflare Worker 边缘部署。

如果你想先在本地体验一下，直接用 Docker Compose 最快：

                                                                 mkdir -p /data/docker
cd /data/docker
git clone https://github.com/OctaFuse/octafuse-gateway.git
cd octafuse-gateway
# 启动服务
docker compose -f docker/compose/quickstart.yml up --build


 # 检查健康状态
curl -sS http://localhost:8787/health

启动后，默认的服务地址是：

• • Proxy (代理接口) : http://localhost:8787

• • Admin (管理后台) : http://localhost:8789

⚠️ 星哥避坑提醒： Admin 后台的默认账号密码是 admin / changeme。如果是部署在公网或生产环境，第一件事绝对是改掉默认密码和 MASTER_KEY！

进入后台后，流程非常清晰： 配置 Provider -> 配置 Model Route -> 创建用户 API Key -> 客户端调用。

配置好后，你的 Cursor 或者脚本里只需要填：

• • Base URL: http://你的网关地址/v1

• • API Key: 你在网关里创建的 Key

• • Model: 你在网关里配置的 Route 名

世界瞬间清净了。

总结：谁需要这个神器？

过去我们看 AI 网关，只关心它转不发得快、兼不兼容 OpenAI。但现在，LLM 接入已经变成了一项复杂的基础设施工程。

星哥建议以下朋友重点关注 OctaFuse Gateway：

1. 1. 重度 AI 玩家/开发者 ：买了多个 Coding Plan / Token Plan，受够了到处配 Key 和查额度。

2. 2. 多工具切换者 ：经常在不同客户端、脚本间切换，需要一个统一的路由层。

3. 3. 企业内部 AI 平台 ：需要统一管理公司内部的 Provider、Key 池、预算和审计告警。

4. 4. AI SaaS 创业团队 ：需要把 LLM 的计费、审计、多租户管理从核心业务代码中剥离出来。

当然，如果你只是偶尔写个小脚本调一下 API，那直接写在代码里就行，上网关确实有点“杀鸡用牛刀”了。

但如果你已经陷入了“模型太多、Key 太乱、账单太碎”的泥潭，或者正准备把 AI 能力商业化，OctaFuse Gateway 绝对值得你花个周末折腾一下。

项目地址都给大家准备好了：

• • GitHub 仓库 ：https://github.com/OctaFuse/octafuse-gateway

• • 项目官网 ：https://octafuse.dev

如果这篇文章帮到了你，别忘了点个 “赞” 和 “在看”，咱们下期再见！