router-for-me/CLIProxyAPI

如果你已经有编程 CLI 账号，又想用普通模型 API 的方式调用它们，CLIProxyAPI 值得看一眼。它本质上是网关而不是模型托管，价值取决于你愿意接入哪些账号和上游。

解决什么问题

你的客户端或 SDK 是按 OpenAI、Gemini 或 Claude 的 API 形状写的，但模型入口在 Claude Code、Codex、Grok Build 这类 CLI 产品后面，登录和账号管理各有一套。为每个供应商重写客户端，或者在工具之间手动搬运凭证，会让换模型变成实验里最贵的一步。

CLIProxyAPI 放在两者中间。你先把 CLI 供应商认证一次，再让现有客户端指向代理提供的兼容端点，由代理把请求翻译给上游。这样同一个应用或 SDK 就能访问多个 CLI 供应商，包括多账号，而不需要为每家单独做集成。

有什么不同

核心机制是协议翻译加基于 OAuth 的上游登录。README 列出了 OpenAI（含 Responses）、Gemini（含 Interactions）和 Claude 兼容端点，以及 Codex、Claude Code、Grok Build、Gemini 的 OAuth 流程。它还支持流式、非流式和 WebSocket 响应（在上游支持时）、函数调用、文本加图片的多模态输入。这些特性决定现有代码切换后能否继续工作，而不只是能不能拿到回复。

多账号是另一个区别点：对 Gemini、OpenAI、Claude、Grok 账号做轮询负载均衡，也能通过配置接入 OpenRouter 等 OpenAI 兼容上游。这会把多个 CLI 订阅变成一个可寻址的池子，对限流余量和团队统一入口都有用。代价是代理会继承上游的脾气：协议保真度取决于翻译层，某家 API 原生的特性不一定能完整带过来。

v6.10.0 之后，内置用量统计被移除了。可观测性改由独立项目提供，比如独立的用量保存服务，以及多个管理控制台，能记录请求历史、延迟、token 和估算成本。如果你期待开箱即用的仪表盘，需要额外部署一个；如果只需要路由，精简后的核心反而更小。

谁值得试

适合已经握有多个 CLI 账号、想要一个 OpenAI 兼容地址给本地脚本、Agent 框架或评测工具用，并且不介意运行 Go 服务、完成 OAuth 登录的开发者或小团队。多账号轮询和上游配置是它相对直接连接各客户端的理由。

不适合想要图形化配置桌面应用的人，项目为这类用户单独提供了桌面客户端。也不适合要求内置分析、不想再加组件的人，或者客户端依赖翻译层未暴露的供应商特有行为的人。

使用条件与边界

你需要目标 CLI 供应商的账号和 OAuth 访问权限，以及服务端本身或图形化桌面客户端来完成配置。项目是 MIT 协议、用 Go 编写，提供可嵌入的 SDK 和文档化的管理 API，所以集成不限于普通 HTTP。安装说明和管理 API 在 README 之外单独维护。

持续的约束主要在运维：账号要保持在已认证状态，多账号轮转依赖有效凭证，v6.10.0 之后用量追踪是独立服务。README 没有逐家说明各供应商的服务条款影响，也没有覆盖所有协议边界；重要场景前，请核对供应商条款，并针对你实际使用的客户端路径做验证。

HotRepo 点评

HotRepo 目前唯一的带日期记录是 2026-10-27：仓库 56,573 stars，当天新增 298，并在日榜出现 1 次。单次快照不足以判断关注度是在上升、消退还是持续。仓库已有 482 天、star 基数很大，文档里的接口值得核对，但是否采用，应看你的账号、客户端和协议需求能否对上项目说明与安装指南中的兼容范围。