octopus
个人 LLM API 聚合网关，一站式管理 OpenAI/Claude/Gemini 多渠道与多 K
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
个人 LLM API 聚合网关，一站式管理 OpenAI/Claude/Gemini 多渠道与多 K
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
图1：Octopus 桌面端首页——清晰展示请求统计与模型概览
你有没有这样的烦恼：同时在用 OpenAI 的 GPT-4、Anthropic 的 Claude，还有 Google 的 Gemini，每个月要管理好几个 API Key；在 Claude Code 里配置了 Claude，OpenAI 的项目里又要配置另一套；Claude Code 的 Haiku 模型太贵，想换成国产平替，却发现改起来特别麻烦。
这些问题，正是 Octopus 想要解决的。它是一个专门为个人开发者打造的 LLM API 聚合与负载均衡网关，通过一个本地服务，将多个 AI 供应商的 API 统一管理起来，让你的 AI 工具们只需要连接一个入口。
随着 AI 模型越来越多，开发者面临的接口碎片化问题正在加剧。OpenAI、Anthropic、Google Gemini、Cohere 等主流厂商各有各的 API 格式：OpenAI 用 /v1/chat/completions，Anthropic 用 /v1/messages，Google Gemini 则用 /v1beta/models/...:generateContent。
这带来的麻烦不只是接入代码不同，更深层的问题在于：每个工具链各自为政。Claude Code 原生只支持 Anthropic 接口，Cursor 和 Cline 用 OpenAI 格式，Codex 又是另一套。如果你想在多个工具之间切换模型，或者想用更便宜的替代品，往往要改一堆配置文件。
更糟糕的是，单一 API Key 的速率限制和稳定性问题也会成为瓶颈。一个复杂项目跑起来，AI 请求量一大，API 限流就会导致整个开发流程卡住。Octopus 的作者 bestruirui 正是带着这些痛点开发了这个项目，希望用一个本地网关来解决所有问题。
Octopus 的功能远不止简单的 API 转发，它提供了完整的 LLM API 管理能力。
这是 Octopus 最核心的能力。你可以在系统中添加多个 LLM 渠道（Channel），每个渠道对应一个 AI 供应商的 API 端点。关键的是，单渠道支持配置多个 API Key，这意味着你可以把多个账号的额度汇聚起来使用。
支持三种负载均衡策略：
这种设计对于需要高可用的开发场景特别有价值。比如你在用 Claude Code 做复杂项目，一旦主账号被限流，系统可以自动切换到备用 Key，整个开发过程不会被中断。
Octopus 支持 OpenAI Chat、OpenAI Responses、Anthropic 三种 API 格式之间的互相转换。这意味着 Claude Code 原生只支持 Anthropic 接口，但通过 Octopus 的协议转换，你可以让它访问 OpenAI 的模型，反之亦然。对于需要灵活切换模型的开发者来说，这个功能解决了长期以来工具与模型强绑定的问题。
配置示例（Claude Code）：只需修改 ~/.claude/settings.json 中的环境变量，指向 Octopus 的本地地址，即可透明地切换到任意模型。
Octopus 引入了分组（Group）的概念：可以把来自不同渠道的同一模型聚合为一个统一的分组名称。比如，将 OpenAI 的 GPT-4o、Azure OpenAI 的 GPT-4o、以及某个兼容 OpenAI 格式的第三方 API 的 GPT-4o 加入同一个分组，命名为 gpt-4o。之后只需用 model: gpt-4o 调用 Octopus，网关会自动根据配置的负载均衡策略选择实际调用的渠道。
这个设计让模型切换变成了改一个配置项的事情。当 OpenAI 价格涨了，你可以瞬间把分组切换到更便宜的替代品，所有用到这个模型的上层应用完全不用改代码。
Octopus 会定期从 models.dev 自动同步 AI 模型的最新价格和可用模型列表。这意味着你不需要手动维护模型价格表，系统会自动更新。对于需要精确控制 API 成本的用户来说，这个功能可以避免意外的费用超支。
图2：渠道管理界面——统一配置多个 LLM 供应商的 API Key 与端点
Octopus 提供了三种部署方式，覆盖了从最快上手到深度定制的不同需求层次。
如果你有 Docker 环境，一行命令就能跑起来：
docker run -d --name octopus -v /path/to/data:/app/data -p 8080:8080 bestrui/octopus
或者使用 docker-compose，只需下载 docker-compose.yml 然后 docker compose up -d。整个部署过程不超过 5 分钟，零配置依赖，开箱即用。
不想用 Docker？可以直行从 Releases 页面下载对应平台的预编译文件（支持 Linux/macOS/Windows，x86 和 ARM 架构全覆盖），解压后运行 ./octopus start 即可。
如果你想深度定制或参与开发，可以从源码构建。需要 Go 1.24.4 + Node.js 18+ + pnpm 环境。注意：前端构建产物会被嵌入 Go 二进制，因此必须先构建前端再启动后端。
图3：桌面端设置界面——配置统计保存周期等全局参数
Octopus 并非银弹，有几点值得注意：
数据隐私方面，Octopus 是一个本地网关，所有 API 请求仍然经过第三方 LLM 供应商的服务器，没有任何数据脱敏或隐私保护机制。如果数据有严格合规要求（如医疗、金融行业），使用时需要额外考虑。
模型兼容性方面，协议互转虽然支持主流格式，但并非所有模型功能都能完全转换。某些模型特有的系统提示词格式或工具调用能力，在协议转换后可能存在行为差异。建议在大规模使用前做充分的兼容性测试。
稳定性方面，Octopus 本身是一个单实例服务，如果本地服务崩溃，所有依赖它的 AI 工具都会受到影响。生产环境建议配合 systemd 等进程管理工具使用。
从代码结构来看，Octopus 采用了一个清晰的分层架构：
后端使用 Go 语言 + Gin Web 框架，在高性能和低内存占用之间取得了很好的平衡。官方标称 512MB 内存即可运行，实际上 Docker 镜像也非常轻量。前端使用 Next.js + TypeScript + Tailwind CSS，提供了现代、响应式的 Web 管理界面。前端构建后会打包成静态资源，通过 Go 的 embed 机制直接嵌入二进制文件，最终发布的是一个完全独立的单文件服务。
值得注意的是，Octopus 大量借用了 looplj/axonhub 项目的 LLM API 适配层实现，这大幅降低了维护多渠道客户端的工作量。
Octopus 代表了一种正在兴起的 AI 开发范式——用中间件思维来管理 AI 能力。过去几年，AI 应用架构中网关层的概念主要出现在企业级场景（如 API 管理平台 KrakenD、APISIX AI 插件等）。但 Octopus 把这个思路带到了个人开发者层面：不需要昂贵的商业方案，不需要复杂的 Kubernetes 集群，一个轻量级本地服务就能实现类似的聚合管理能力。
从 GitHub 话题标签（ai-gateway、llm-gateway、self-hosted）可以看出，这个项目正处于 AI 网关这个细分赛道的增长区间。随着 Claude Code、Cline、Copilot 等 AI 编程工具越来越普及，如何高效管理多个 AI 模型的访问，将成为越来越多开发者面临的问题。Octopus 提供的正是这个问题的轻量化解法。
总结：Octopus 是一个功能完整、实现精致的个人 LLM API 聚合网关。它通过多渠道聚合、协议互转、模型分组、负载均衡等能力，有效解决了个人开发者在多 AI 工具场景下面临的接口碎片化和成本管理难题。部署简单（Docker 一键启动），资源占用低（512MB 内存），非常值得有相关需求的开发者一试。