38K Star 的 CLIProxyAPI：把 Claude Code、Codex、Gemini 统一成一个本地 API 入口

很多人开始用 AI 编程工具之后，都会遇到一个很现实的问题：

工具越来越多，入口也越来越乱。

今天 Claude Code，明天 Codex，后天 Gemini CLI，再加上 OpenCode、Cline、Roo Code、Continue、Cursor 这类客户端，每个工具都有自己的登录方式、配置文件、模型名字和 API 兼容格式。

如果只是自己偶尔用一下，还能手动切换。

但一旦你有多个账号、多种模型、多台机器，或者想把这些能力接到自己的 SDK、Agent、自动化脚本里，事情很快就会变得很碎。

今天看的这个项目，就是为了解决这类问题：

项目地址：https://github.com/router-for-me/CLIProxyAPI

官方文档：https://help.router-for.me/cn/

它叫 CLIProxyAPI。

一句话概括：

CLIProxyAPI 是一个本地代理服务器，把 Claude Code、OpenAI Codex、Gemini、Grok 等 CLI 或 OAuth 登录能力，统一封装成兼容 OpenAI、Gemini、Claude 协议的 API 入口。

这句话听起来有点绕。

翻成普通开发者能理解的话就是：

以前你要分别处理 Claude、Codex、Gemini 的登录、配置、接口格式和客户端适配。

现在可以先让 CLIProxyAPI 在本地跑起来，再让各种工具统一访问它提供的 API。

它更像是 AI 编程工具时代的**“本地模型网关”**。

它是什么

CLIProxyAPI 官方介绍里说得很直接：

它是一个为 CLI 提供 OpenAI、Gemini、Claude、Codex、Grok 兼容 API 接口的代理服务器。

它当前重点支持几类能力：

• OpenAI Codex，也就是 GPT 系列相关能力，可以走 OAuth 登录
• Claude Code，可以走 OAuth 登录
• Gemini 和 AIStudio API Key
• Grok Build，可以走 OAuth 登录
• OpenAI 兼容上游，比如 OpenRouter
• 流式响应、非流式响应，以及部分场景下的 WebSocket 响应
• 函数调用、工具调用和多模态输入
• 多账户轮询和负载均衡
• 可复用的 Go SDK

截至 2026-06-24，GitHub 页面显示这个仓库已有约 38.2k star、6.3k fork。

这个数据说明它不是一个小众脚本，而是已经被大量 AI 编程工具用户关注。

原因也不难理解。

AI 编程工具正在从“一个编辑器插件”变成**“一组可编排的 Agent 和 CLI 工具”**。

当工具链变多之后，真正麻烦的不是某一个模型怎么调，而是：

• 登录态怎么维护
• 多账号怎么轮询
• 客户端怎么统一接入
• 不同协议怎么互转
• 配额和可用性怎么管理
• 新工具怎么少改配置就能接进来

CLIProxyAPI 切的就是这一层。

它不是一个新的大模型，也不是一个新的聊天软件。

它站在模型和客户端之间，把上游账号、模型和协议整理成一个更稳定的本地入口。

解决的核心问题

如果你只用一个 ChatGPT 网页版，可能暂时感受不到它的价值。

但只要你开始用 AI 编程工具，问题很快就出现了。

比如 Claude Code 很好用，但它有自己的认证和调用方式。

Codex 很适合写代码和跑任务，但你也要处理它自己的登录态。

Gemini 在长上下文和多模态场景里有优势，但客户端未必都原生支持。

一些第三方工具只认 OpenAI 协议，另一些工具只认 Claude 协议，还有些工具支持 Gemini，但不支持你手上的账号形态。

结果就是你为了让一个 Agent 跑起来，要在不同配置文件里来回改：

base_url
api_key
model
provider
auth path
proxy

这些配置单独看都不难。

难的是它们散落在每个工具里。

CLIProxyAPI 的价值，就是把这些分散配置尽量收敛到一层代理里。

上游可以是 Codex、Claude Code、Gemini、Grok 或 OpenAI 兼容服务。

下游可以是任何支持 OpenAI、Gemini、Claude 兼容协议的客户端、SDK 或 Agent 工具。

这样一来，很多工具不需要知道你背后到底接的是哪个账号、哪个 CLI、哪个 OAuth 提供方。

它只需要访问一个统一入口。

它适合什么场景

第一类场景，是多账号 AI 编程。

很多重度用户并不是只有一个账号。

Claude、ChatGPT、Gemini、Grok 可能都有，甚至每个服务还有多个账号。

这时候最怕的是手动切换。

CLIProxyAPI 支持多账户和轮询负载均衡，可以把多个账号组织成一个池子，让请求按策略分发。

这对 Codex、Claude Code、Gemini、Grok 这类工具尤其有用。

第二类场景，是让旧工具接入新模型。

不少客户端只支持 OpenAI 兼容接口。

但你手里真正可用的，可能是 Claude Code 登录态、Codex OAuth、Gemini AIStudio，或者某个 Claude / Gemini 兼容服务。

CLIProxyAPI 可以在中间做协议适配，让客户端少关心上游细节。

第三类场景，是团队内部统一入口。

如果一个小团队都在用 AI 编程工具，每个人各配各的 API、各改各的模型名，很容易混乱。

更好的方式是由一个统一代理管理上游账号、模型、路由和配置。

成员只需要拿到固定的 base URL 和访问方式。

第四类场景，是Agent 自动化。

现在很多 Agent 并不只跑在编辑器里。

它可能跑在终端、CI、远程服务器、浏览器自动化任务，甚至多个 Agent 协作系统里。

这些 Agent 最需要的是稳定、统一、可脚本化的模型入口。

CLIProxyAPI 在这里更像一个基础设施组件。

怎么开始用

CLIProxyAPI 的安装方式比较多。

macOS 用户可以直接用 Homebrew：

brew install cliproxyapi
brew services start cliproxyapi

如果是 Linux，官方文档提供了一键安装脚本：

curl -fsSL https://raw.githubusercontent.com/router-for-me/cliproxyapi-installer/refs/heads/master/cliproxyapi-installer | bash

Arch Linux 用户可以从 AUR 安装：

yay -S cli-proxy-api-bin

或者：

paru -S cli-proxy-api-bin

Docker 用户可以直接跑容器：

docker run --rm -p 8317:8317 \
  -v /path/to/your/config.yaml:/CLIProxyAPI/config.yaml \
  -v /path/to/your/auth-dir:/root/.cli-proxy-api \
  eceasy/cli-proxy-api:latest

如果你想从源码编译，也可以克隆仓库后用 Go 构建：

git clone https://github.com/router-for-me/CLIProxyAPI.git
cd CLIProxyAPI
go build -o cli-proxy-api ./cmd/server

Windows 用户则可以从 GitHub Releases 下载程序，或者使用官方提到的桌面图形程序。

这里要注意一点：

CLIProxyAPI 不是安装完就自动拥有模型能力。

它本质上是代理层。

你仍然需要配置上游 Provider，比如 Codex、Claude Code、Gemini、OpenAI 兼容服务等。

也就是说，先有账号或上游服务，再通过 CLIProxyAPI 统一转出来。

配置以后有什么变化

配置好之后，你会得到一个统一的本地 API 服务。

默认 Docker 示例里暴露的是 8317 端口。

后续你可以让不同客户端指向这个入口。

比如某个工具只认 OpenAI 风格的接口，那就把它的 base_url 改到 CLIProxyAPI。

某个 Agent 需要 Claude 协议，也可以通过对应兼容入口接入。

如果后面你更换上游账号、增加新模型、调整路由策略，理论上不需要每个客户端都重新改一遍。

这就是代理层最大的好处：

客户端稳定，上游可变。

对普通用户来说，它能减少配置混乱。

对重度用户来说，它能把多账号、多模型、多协议这件事管起来。

对开发者来说，它还能作为本地 SDK 和 Agent 的统一模型入口。

使用量统计为什么单独拿出来说

README 里有一个变化值得注意：

自 v6.10.0 以后，CLIProxyAPI 和 CPAMC 不再预置数据统计功能。

如果需要使用量统计，官方 README 推荐了两个方向：

• CPA Usage Keeper：独立的使用量持久化与可视化服务
• CPA-Manager-Plus：面向 CLIProxyAPI 的完整管理中心，提供请求监控、费用预估、账号巡检和异常账号定位等能力

这说明 CLIProxyAPI 本体的定位更偏代理和协议层。

监控、费用、可视化、账号池运维这些事情，可以交给周边管理工具来做。

这个取舍是合理的。

如果一个代理服务什么都内置，最后很容易变成又重又复杂的管理平台。

把核心代理保持轻量，把统计和运维交给外部项目，反而更适合开源生态扩展。

周边生态已经起来了

CLIProxyAPI README 里列了不少基于它构建的项目。

比如：

• vibeproxy：macOS 菜单栏应用，让用户通过订阅服务使用 Claude Code 和 ChatGPT
• Claude Proxy VSCode：VSCode 扩展，用来快速切换 Claude Code 模型
• ZeroLimit：Windows 桌面应用，用于监控 AI 编程助手配额
• CLIProxyAPI Dashboard：基于 Next.js 的现代化 Web 管理仪表盘
• ProxyPal：跨平台桌面 GUI，封装 CLIProxyAPI 并提供使用分析和自动配置
• CLIProxyAPI Quota Inspector：跨平台配额查询工具
• CLIProxy Pool Watch：macOS SwiftUI 账号池额度监控工具

这些项目说明了一件事：

CLIProxyAPI 已经不只是一个**“转发 API 的小工具”**。

它正在变成一类 AI 编程工具的底层代理标准。

因为大家都遇到了同一个问题：

账号、配额、协议、模型和客户端太分散。

有了一个统一代理层，周边工具就可以围绕它做图形界面、配额监控、自动配置、团队管理和多端支持。

它和普通 API 中转有什么区别

很多人看到这里，可能会问：

这不就是 API 中转吗？

有相似之处，但重点不太一样。

传统 API 中转更多是把一个 OpenAI 兼容服务转给另一个客户端，核心是价格、可用性、网络和模型聚合。

CLIProxyAPI 更偏AI 编程工具场景。

它关注的是 CLI、OAuth 登录、多账户轮询、Codex、Claude Code、Gemini、Grok 这类具体工具链，以及 OpenAI、Gemini、Claude 多协议兼容。

简单说：

普通中转解决的是“我怎么访问模型 API”。

CLIProxyAPI 更关心的是**“我怎么把手上的 AI 编程账号和 CLI 能力变成统一 API，给各种 Agent 和客户端用”**。

这个差别很关键。

因为 AI 编程工具不只是一次普通聊天请求。

它经常涉及流式输出、工具调用、多轮上下文、长任务、账号配额、模型别名、协议差异和客户端兼容。

这些都需要更贴近开发工具链的代理层。

谁最值得试

如果你是下面几类用户，CLIProxyAPI 值得花时间研究：

• 同时使用 Claude Code、Codex、Gemini、Grok 等多个 AI 编程工具
• 有多个账号，需要轮询、切换或统一管理
• 想让只支持 OpenAI 协议的客户端接入更多上游能力
• 想把 AI 编程能力接进自己的 Agent、脚本或内部工具
• 想搭一个本地或团队级模型入口
• 不想在每个客户端里反复配置 provider、model、base_url 和认证信息

如果你只是偶尔打开一个网页聊天，或者只用一个官方客户端，那它可能暂时不是刚需。

它真正的价值在**“工具链变复杂”**之后才会显出来。

最后说说

AI 编程工具这两年的变化很快。

一开始大家关心的是模型会不会写代码。

后来开始关心编辑器插件好不好用。

现在问题又往下一层走了：

多个 Agent、多个账号、多个模型、多个协议，怎么被稳定地组织起来。

CLIProxyAPI 解决的不是“让模型更聪明”。

它解决的是**“让模型能力更容易被调用、复用和管理”**。

这类工具短期看起来不如新模型发布那么热闹，但对重度开发者和团队来说，它更接近基础设施。

如果你已经在用 Claude Code、Codex、Gemini CLI、OpenCode、Cline、Roo Code 这些工具，并且开始被配置和账号切换折腾，CLIProxyAPI 可以重点看一下。

它不是让你多装一个玩具。

它更像是给 AI 编程工具链补上一层路由器。

如果你也在折腾 Claude Code、Codex、Gemini CLI 或各种 Agent 工具，可以把这篇文章转给同样被配置、账号和协议折腾的朋友。

==关注我==。后面我会继续拆解这类 AI 编程基础设施工具：哪些值得装、哪些适合团队用、哪些只是看起来热闹。