Clipal 登陆 npm，本地多模型调度装起来更省事了

行业快讯

本地 LLM API 反向代理工具 Clipal 正式支持 npm install -g clipal 全局安装，同时仓库迁移至 PAIArtCom 组织。这款主打 Claude Code、Codex CLI、Gemini CLI 的路由调度工具，把部署门槛又降了一截。

Clipal 上了 npm，本地搞多模型调度不用再折腾二进制

这两天 Clipal 在 linux.do 上更新了一条动静：从这周起，这个主打本地 LLM API 反向代理的小工具正式支持通过 npm 全局安装，命令一行搞定：

npm install -g clipal

作者在帖子里说，这是回应社区用户 @hhdong 的提议。顺带一提，GitHub 仓库也完成了主体迁移，从个人账号 lansespirit 转到了新的组织 PAIArtCom 下，地址变成 github.com/PAIArtCom/Clipal。原来的链接还在，但要 Star 的话建议认准新地址。

对一个装机工具来说，这不是什么惊天大事，但对 Clipal 的目标用户——每天跟 Claude Code、Codex CLI、Gemini CLI 打交道的开发者——确实挺实在。毕竟在此之前，你得去 Release 页挑平台、下二进制、chmod、丢进 PATH，整个流程要五六步。现在 npm i -g 一条命令，升级也是一个 npm update，和装 pnpm、pm2 这种日常工具没啥区别。

Clipal 通过 npm 一键安装的终端截图

它到底解决什么问题

如果你没用过 Clipal，一句话概括：它是一个跑在本地的 LLM API 反向代理，负责把各家 CLI 工具的请求按规则分发到不同的上游服务商。

这个场景这一年变得越来越常见。现在一个重度 AI 开发者手里，大概率同时攥着这么几样东西：

  • Anthropic 官方的 Claude Code，或者通过各种渠道拿到的 Claude API Key
  • OpenAI 的 Codex CLI（包括 Plus 订阅附送的额度、API 付费额度、free tier）
  • Google 的 Gemini CLI
  • 若干个第三方聚合平台的 Key
  • 可能还有本地跑的 Ollama、vLLM

问题是，这些工具各自只认自己家的端点和鉴权格式。你想让 Claude Code 走某个便宜的中转、让 Codex CLI 轮询多个账号、在主力 Key 额度耗尽时自动切备用——原生客户端都做不了。

Clipal 干的就是中间那一层：它在本地起一个服务，把自己伪装成 Anthropic / OpenAI / Google 的 API 端点，下游客户端照常发请求，它按照 YAML 配置里的规则把流量路由到真正的上游。

配置长什么样

从仓库的 README 看，路由规则是纯 YAML，几段就能表达比较复杂的调度策略。大致结构是这样：

providers:
  - name: claude-official
    type: anthropic
    base_url: https://api.anthropic.com
    api_key: sk-ant-xxx
    priority: 1

  - name: claude-relay-a
    type: anthropic
    base_url: https://relay-a.example.com
    api_key: xxx
    priority: 2

  - name: codex-pool
    type: openai
    accounts:
      - api_key: sk-1
      - api_key: sk-2
      - api_key: sk-3
    strategy: round_robin

routes:
  - match: claude-*
    providers: [claude-official, claude-relay-a]
    failover: true
  - match: gpt-*
    providers: [codex-pool]

几个值得一提的细节：

热重载。改完 YAML 不用重启进程，Clipal 会监听文件变化，新的路由规则立刻生效。这个体验对边调边试的人很友好，尤其是在调故障转移策略的时候。

优先级 + 自动 failover。主上游报 429、5xx 或者超时，会自动降级到下一个 provider。对于那些靠白嫖额度维生的同学来说，这等于是给手里几百个账号装了个自动调度器——作者自己在帖子里就说，他用 horo SMS 注册机搞了几百个 free tier 的 Codex 账号导入 Clipal 测额度，"还挺爽的"。这个玩法合不合规是另一码事，但工具能力本身确实到位了。

协议兼容。Clipal 同时暴露 Anthropic、OpenAI、Gemini 三套接口格式，所以 Claude Code、Codex CLI、Gemini CLI、Continue、Aider、Cherry Studio 这些客户端全都不用改代码，改个 base_url 就能接管。

和同类工具比，定位在哪

这个赛道其实不空。LiteLLM、one-api、new-api、Portkey，每一个都在做 "API 网关" 这件事。Clipal 的差异点比较清晰：

它是给个人开发者的本地工具，不是给团队的服务端。LiteLLM 和 one-api 更像企业网关，有 UI、有用户体系、有配额管理、有日志面板，适合团队自建；Clipal 走的是另一条路——单二进制（现在是单个 npm 包）、YAML 配置、跑在 localhost、只管调度不管多租户。你可以把它理解成 LLM 领域的 nginx.conf，而不是 Kong。

它原生对齐三家 CLI。Claude Code、Codex CLI、Gemini CLI 是最近一年在开发者群体里扩散得最快的三个工具，而它们的协议细节又有各自的坑（比如 Claude 的 system prompt 位置、Codex 的 reasoning 参数、Gemini 的 safety settings）。Clipal 在这几个协议上做了专门适配，路由规则里可以按模型名前缀匹配，不用自己写 middleware。

它活得还挺稳。作者在最新帖子里有一句很有意思的话："最近因为太稳定了，没人给我提新需求了"。然后他就顺手加了统计功能，主要是想测一下 free 和 plus 的 Codex 账号到底能用出来多少刀。对一个工具项目来说，"没人提需求" 是个好信号——说明核心路径已经跑顺了。

谁会真的用上

几类人适合关注：

  • 多 Key 轮询的重度用户。手里有多个 Claude / OpenAI / Gemini 账号，想做负载均衡和故障转移的
  • 想在 Claude Code 里接非官方模型的。比如让 Claude Code 的 base_url 指向 Clipal，然后 Clipal 在底层把请求转给 DeepSeek 或 Qwen
  • 本地模型和云端模型混用的。开发期用 Ollama，生产期切云端，靠 YAML 一行改
  • 企业内需要审计 / 改写请求的。Clipal 可以在中间做 header 注入、prompt 改写、敏感词过滤

不太适合的场景也很明确：如果你要给整个团队部署带 UI 的 API 网关、要做账单分摊、要接 SSO，那还是去看 LiteLLM 或 one-api。Clipal 没想做那件事。

小工具，但把一件事做到了位

本地 LLM 代理这个东西，说白了不是什么技术难题。难的是在协议兼容性、热重载、故障转移、配置体验之间找平衡点——做简单了不好用，做复杂了失去了 "本地小工具" 的意义。Clipal 这次上 npm，把最后一道部署摩擦也抹掉了。对开发者来说，工具的安装方式看起来是小事，但 npm i -g 和 "下载二进制手动放 PATH" 之间那道坎，往往就决定了一个项目是被随手试用还是被收藏夹吃灰。

顺便说一句，如果你不想在本地自建这一套路由层，又需要一个 Key 同时调 GPT、Claude、Gemini、DeepSeek，国内直连、兼容 OpenAI 格式，OpenAI Hub（openai-hub.com）也是个选择——它把聚合和分发放在了服务端，你这边只需要改一个 base_url。两种思路，看你更想把控制权放在本地还是云端。

参考来源