CLIProxyAPI
把 Claude Code/Gemini CLI/OAuth 订阅转成 OpenAI 兼容 API，
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
把 Claude Code/Gemini CLI/OAuth 订阅转成 OpenAI 兼容 API，
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
你有没有过这样的经历：花大价钱订阅了 Claude Code 或 Gemini CLI，兴致勃勃想在团队项目里集成，却发现这些 CLI 工具根本没有标准的 OpenAI 兼容 API，只能在终端里手动敲命令？团队里用 Python/Java/Go 的工程师只能干瞪眼，无法直接接入 CI/CD、无法在现有应用里调用。
CLIProxyAPI 就是来解决这个痛点的。它本质上是一个本地代理服务器，把 Claude Code、Gemini CLI、OpenAI Codex、Grok Build 这些闭源 CLI 工具，通过协议转换「伪装」成标准的 OpenAI/Gemini/Claude API。任何能调用这些协议的工具、SDK、CI 脚本，都可以无缝接入——无需任何额外 API Key，也无需改代码。
图1：CLIProxyAPI 的赞助商生态，展示了其在 AI 中转服务领域的活跃度
CLIProxyAPI 的诞生折射出一个有趣的现象：AI 编程工具市场正在经历「订阅制 + 闭源 CLI」向「开放 API」过渡的阵痛期。
以 Claude Code 为例：Anthropic 主推的 Claude Code 是目前最强的 AI 编程工具之一，但它的使用方式局限于命令行终端。对于企业开发团队而言，这意味着：无法通过 REST API 集成到现有系统、无法在自动化流水线中调用、无法让非技术人员使用。更关键的是，Claude Code 采用 OAuth 账号体系，不提供传统意义上的 API Key——这让很多开发者望而却步。
无独有偶，Google 推出的 Gemini CLI 也有类似特性：面向开发者、无传统 API 形态、通过订阅提供高级功能。
CLIProxyAPI 的作者敏锐地捕捉到了这个需求缺口：通过本地代理 + 协议翻译，让这些「只能 CLI 使用」的 AI 工具变成「任何客户端都能调用的 API 服务」。其核心思路是：CLIProxyAPI 运行在本地（默认端口 8317），接收 OpenAI 兼容格式的请求，自动完成身份认证（OAuth 刷新 Token 管理）、请求路由（根据 model 参数分发到对应 CLI）、响应格式转换（CLI 输出 → 标准 API 格式），最终返回给调用方。
这种「透明代理 + 协议适配」的架构设计，让整个过程对调用方完全不可见——调用方还以为自己在调用 OpenAI API，实际上请求被静默路由到了 Claude Code 或 Gemini CLI。
图2：AI Code Mirror 等赞助商反映了该工具在 AI 中转服务领域的重要性
CLIProxyAPI 的功能远不止「换个格式」这么简单。它提供了一整套企业级代理能力：
多账号轮询与负载均衡：CLIProxyAPI 支持同时配置多个 Claude/Gemini/Codex 账号。当请求量增大时，它会自动在多个账号之间轮询，避免单账号的速率限制（Rate Limit）。这对于需要高并发的团队场景至关重要。
函数调用 / 工具调用支持：Claude Code 和 Gemini CLI 原生支持函数调用（Function Calling），CLIProxyAPI 完整保留了这些能力。调用方可以像使用 OpenAI 的 function calling 一样，让 AI 编程助手执行文件操作、搜索、执行命令等真实动作。
多模态输入：支持图片 + 文本的混合输入，与 Claude Code 的多模态能力保持同步。开发者可以直接通过 API 上传截图，让 AI 编程助手「看图」分析代码问题。
流式响应 + WebSocket：除了标准 Server-Sent Events（SSE）流式响应，CLIProxyAPI 还支持 WebSocket 方式推送响应，适合需要实时交互的场景。
OAuth 自动化：Claude Code 和 OpenAI Codex 使用 OAuth 做身份认证。CLIProxyAPI 内置了 OAuth Token 自动刷新机制，用户只需首次在终端完成授权，后续完全透明——无需手动管理 Access Token。
上游 OpenAI 兼容提供商：除了 CLI 工具，CLIProxyAPI 还支持接入 OpenRouter 等兼容 OpenAI API 的中转服务商，灵活扩展可用模型池。
CLIProxyAPI 的技术栈选型非常务实：Go 语言 + Gin Web 框架。
为什么是 Go？ CLIProxyAPI 本质上是一个高性能 HTTP 代理和中转层，需要处理大量并发请求和协议转换。Go 的 Goroutine 天然适合 IO 密集型代理场景，且编译成单一二进制文件，部署极简。CGO_ENABLED=0 的静态编译确保容器镜像可以直接在 Alpine 环境下运行，体积可控。
依赖亮点：
github.com/gin-gonic/gin：高性能 HTTP 路由和中间件框架，负责接收请求、分发路由github.com/gorilla/websocket：WebSocket 协议支持github.com/tidwall/gjson/tidwall/sjson：运行时动态解析和修改 JSON 配置github.com/jackc/pgx/v5：PostgreSQL 驱动（用于可选的用量统计后端存储）golang.org/x/oauth2：OAuth2 协议实现，支持 Claude/Codex 的三方登录github.com/sirupsen/logrus：结构化日志，支持 JSON 格式输出gopkg.in/natefinch/lumberjack.v2：日志轮转，防止日志文件撑爆磁盘代码结构：cmd/server/main.go 是唯一入口，所有业务逻辑在根目录下的包中组织，模块划分清晰，便于后续扩展。
容器化：采用多阶段构建（Multi-stage Build）：第一阶段用 golang:1.26-alpine 编译，第二阶段用 alpine:3.23 运行最终镜像。Alpine Linux 镜像体积极小（约 5-10MB），非常适合容器化部署。
图3：APIKEY.FUN 等赞助商侧面印证了 CLIProxyAPI 在 AI API 中转生态中的核心地位
CLIProxyAPI 的部署门槛极低，完全不需要 GPU 或大内存。
硬件需求：
Docker 部署（推荐）：项目提供了标准的 docker-compose.yml，一行命令即可启动。配置通过 .env 文件或 config.yaml 注入，支持 TLS 加密、远程管理 API（带密钥保护）、多账号池等高级配置。
集群模式：项目还提供了 docker-compose.cluster.yml，用于多实例水平扩展，适合高并发场景。
最令人惊讶的是 CLIProxyAPI 的生态活跃度。目前 GitHub 上已有超过 15 个基于 CLIProxyAPI 的衍生项目：
这种生态繁荣度说明 CLIProxyAPI 解决了真实痛点——它不是一个人的工具，而是整个社区的需求共鸣。
CLIProxyAPI 也有一些需要正视的局限：
无官方 Web UI：项目本身不提供图形管理界面，所有配置通过 YAML 文件或 Management API 完成。对于不熟悉命令行的用户有一定门槛。不过第三方项目（如 CPA-XXX Panel）提供了 Web 管理面板作为补充。
OAuth 依赖风险：Claude Code 和 Codex 的 OAuth Token 有有效期限制，Token 刷新依赖网络连通性。如果 Token 过期但 CLIProxyAPI 未及时刷新，会导致 API 调用失败。
非官方集成：Claude Code 和 Gemini CLI 的 API 兼容层本质上是逆向工程，Anthropic 和 Google 官方并未提供任何保证。一旦官方 API 行为变更，CLIProxyAPI 可能需要紧急更新。
安全考量：CLIProxyAPI 默认监听所有网络接口（host: ""），生产环境建议绑定 127.0.0.1 或配置 TLS + 密钥保护，避免未授权访问。
CLIProxyAPI 的兴起折射出一个更大的趋势：AI 编程工具正在从「一次性买断」走向「订阅制 + CLI 优先」。Claude Code、GitHub Copilot Workspace、Gemini CLI 等头部产品均采用订阅制，不提供传统 API Key。
这催生了一个新需求：如何让订阅制的 CLI 工具接入现有的 API 生态？
CLIProxyAPI 给出了答案：不需要等官方开口，自己动手做协议适配。这种「用户驱动」的集成方式，在 AI 工具生态不成熟的当下尤为关键。随着 Claude Code API、Gemini CLI API 等官方能力的完善，这类代理工具的价值会逐渐降低——但在未来 1-2 年内，它们仍然是连接「订阅制 CLI」和「API 世界」的重要桥梁。
GitHub 34000+ Stars 和 15+ 衍生项目的生态，是对这一判断的最好佐证。