R本地 AI 编程 CLI 路由笔记

Weave Router、CC Switch、LiteLLM、OpenRouter：本地 AI 编程 CLI 路由怎么选

面向 Claude Code、Codex、Cursor、Gemini CLI、opencode 这类本地 AI 编程工具时，关键问题不是“谁支持更多模型”，而是谁站在本地工作流的哪一层：配置控制、请求路由、企业网关，还是模型市场。

技术博客草稿 约 12 分钟阅读 面向本地 CLI 与订阅账户用户 HTML 单文件
Weave Router

更像本地智能路由数据面：请求进来后自动判断该走哪个模型，尤其贴近 Claude Code / Codex 这类 agent CLI。

CC Switch

更像本地控制台：管理多个 CLI、多个 provider、MCP、Skills、Prompts，并提供 GUI 和托盘切换。

LiteLLM

更像通用 LLM Gateway：适合团队统一 key、预算、限流、fallback、审计与生产网关。

OpenRouter

更像模型市场和统一购买入口：一个 API 访问大量模型，适合快速补齐 DeepSeek、Kimi、Qwen 等模型池。

四层架构图：先别把它们放在同一格里比较

把本地 AI 编程环境拆成四层后，差异会清楚很多。Claude Code、Codex、Cursor 等是请求发起方；CC Switch 管配置和切换；Weave 负责请求级智能路由；OpenRouter 是大量模型的托管市场；LiteLLM 则可以横跨控制、网关和治理，但它的默认语境更偏团队基础设施。

CLI 发起请求：保留本地工具体验 中间层决定：切换配置或自动路由 下游执行：官方 API、订阅 passthrough 或模型市场

Weave 的优势：不是“又一个 OpenRouter”，而是本地 agent CLI 的自动路由层

Weave Router 的官方定位是一个 drop-in proxy。它能接 Anthropic Messages、OpenAI Chat Completions、Gemini 原生接口，也能通过 OpenRouter 或 OpenAI-compatible endpoint 接入开源和国产模型。它的特别之处是路由决策：用本地轻量 embedder 与 cluster scorer 判断请求适合哪类模型，而不是只按固定模型名转发。

核心判断

如果目标是“让 Claude Code 或 Codex 的每一轮请求自动选模型”，Weave 比 LiteLLM 和 OpenRouter 更贴近问题本身；如果目标是“统一管理很多 CLI 配置”，CC Switch 反而更像日常桌面入口。

Weave 和 CC Switch：确实更像竞品，但竞争点不同

Weave：数据面，负责“这一轮请求走哪儿”

Weave 更关注请求本身：内容是什么、复杂度如何、是否需要强模型、是否可以交给更便宜的模型、是否要保持长会话一致性。它适合拿来验证“自动模型路由”是否真的能改善成本与稳定性。

自动路由 localhost:8080 OTLP Codex / Claude Code

CC Switch：控制面，负责“本机工具连接谁”

CC Switch 更关注本机配置管理：多个 CLI、多个 provider、多个 key、MCP、Skills、Prompts、Sessions、使用量统计和托盘切换。它适合长期作为桌面上的 AI 编程控制台。

GUI 管理 provider presets MCP / Skills Usage dashboard

四者能力对比：定位比功能列表更重要

维度 Weave Router CC Switch LiteLLM OpenRouter
核心定位 本地 / 自托管智能模型路由器 AI 编程 CLI 桌面管理器 通用 LLM Gateway / Proxy 托管模型市场与统一 API
最佳用户 想体验请求级自动路由的 coding agent 用户 同时管理 Claude Code、Codex、Gemini CLI 等多工具用户 团队、企业、平台工程和后端服务 需要一个 key 调用大量模型的开发者
路由方式 本地 embedder + cluster scorer，按请求自动选模型 手动/热切换 provider，配合本地 proxy 和 failover 规则、负载均衡、fallback、预算、限流、自定义策略 provider routing、价格/延迟/吞吐排序、Auto/Pareto 类路由
本地 CLI 适配 明确支持 Claude Code、Codex、opencode，Cursor 手动配置 覆盖 Claude Code、Claude Desktop、Codex、Gemini CLI、OpenCode 等 可接，但通常需要自己管理配置 可作为 base URL，但不是本地配置管理器
订阅账户体验 官方文档提到 Claude/Codex plan credentials passthrough 支持官方登录 preset 和多 provider 切换 主要围绕 API key、虚拟 key、团队密钥治理 主要使用 OpenRouter key 和余额
自托管能力 可以本地 / 自托管，默认端口常见为 8080 本地桌面应用 + SQLite + 本地 proxy 成熟，适合服务端生产部署 SaaS 为主，不是自托管项目
观测与治理 OTLP trace、dashboard、路由决策审计 用量面板、请求日志、配置备份 日志、预算、限流、guardrails、团队管理 用量、模型排行、provider 状态与计费

订阅账户边界：passthrough 不是“跨供应商额度池”

很多个人开发者的模型使用方式并不是纯 API 计费，而是混合了 Claude Code、ChatGPT/Codex、Cursor、Gemini 等订阅计划。这是最容易误解的地方：Weave 或 CC Switch 可以帮助本地 CLI 接入、切换或转发原有认证，但不能把 Claude 订阅额度变成 Gemini、DeepSeek、Qwen 的 API 额度，也不能把 Cursor 订阅自动变成 OpenRouter 余额。

可以期待

Claude Code 继续使用 Anthropic plan credentials；Codex 继续使用 OpenAI plan credentials；本地工具请求经过路由器或配置管理器。

需要额外 key

如果要路由到 OpenRouter、Gemini、DeepSeek、Kimi、Qwen、GLM 等模型池，通常仍需配置对应 provider key 或 OpenRouter key。

不要误判

订阅账户不是通用 API 钱包。路由器能改变请求路径，但不能绕过供应商的计费、授权和服务条款。

实践建议

把官方订阅当主力，把 OpenRouter key 当补充模型池；先 shadow test 或小范围项目级接入，再决定是否长期放进日常工作流。

如何体验 Weave 路由本地 CLI：先走最小可逆路径

如果目标是体验本地 CLI 路由，不建议一上来就自托管全套 Postgres + dashboard。先用项目级 Codex 配置接入 hosted router，确认本地 CLI 能走通，再考虑 `--local`。

路径 A：项目级 Codex 接入 影响最小
cd path\to\your-project
npx @workweave/router --codex --scope project

$env:CODEX_HOME = Join-Path (Get-Location) ".codex"
codex
验证与回滚 可逆
npx @workweave/router status --codex --scope project
Get-Content .\.codex\config.toml

npx @workweave/router off --codex --scope project
npx @workweave/router --uninstall --codex --scope project
路径 B：自托管 localhost:8080 完整体验
git clone https://github.com/workweave/router
cd router
echo "OPENROUTER_API_KEY=sk-or-v1-..." >> .env.local
make full-setup
本地 router 接入 Codex router + CLI
cd path\to\your-project
npx @workweave/router --codex --local --scope project

$env:CODEX_HOME = Join-Path (Get-Location) ".codex"
codex

选型矩阵：按真实目标选

目标：体验“自动选模型”

优先试 Weave Router。 它的核心卖点就是本地 / 自托管路由层，而不是简单 provider 切换。

建议：先接 Codex 项目级配置，再加 OpenRouter key 观察是否真的发生跨模型路由。

目标：管理很多本地 CLI

优先试 CC Switch。 它更像桌面控制台，适合多工具、多 key、多配置、多 MCP 的日常管理。

建议：把官方登录、第三方 API、Weave Router 都作为 provider 管起来，但避免多个工具同时改同一份配置。

目标：补齐开源模型池

优先加 OpenRouter。 它最快解决“一个 key 访问很多模型”的问题。

建议：让 Weave 或 LiteLLM 把 OpenRouter 当下游，而不是在本机重复维护每个模型供应商。

目标：团队统一治理

优先看 LiteLLM。 它更适合作为团队级网关，处理虚拟 key、预算、限流、fallback、审计、guardrails。

建议：先定义业务路由规则，再决定是否把 Weave 放在个人开发者侧。

目标：以订阅账户为主

把 passthrough 当基础，把 API key 当补充。 订阅账户保留官方路径，OpenRouter 或 provider key 用于扩展模型池。

建议：不要期待订阅额度自动跨供应商流动。

目标：先不破坏现状

用 project scope。 不改全局配置，只在一个工作区试验；验证通过再扩大范围。

建议：记录原始配置、路由开关、卸载命令和一次真实任务日志。

落地风险清单：别只看“支持”两个字

风险 为什么重要 建议动作
路由错误 简单请求可以省钱，复杂代码修改被路由到弱模型可能造成返工。 先用真实任务做小样本比较，保留手动指定强模型的逃生路径。
prompt cache 失效 长会话 agent 随意跨模型可能损失缓存命中和上下文一致性。 关注 session pinning、长会话策略和 provider cache 行为。
密钥存储 BYOK 不等于无需配置。自托管时要确认 key 是否加密落库。 设置外部加密 key，修改默认 dashboard 密码，限制内网访问。
配置接管冲突 Weave 和 CC Switch 都可能修改 Claude/Codex 配置。 同一个 CLI 同一份配置先只让一个工具接管；另一个作为 provider 或手动路径。
成本错觉 省钱比例依赖请求分布、模型池、缓存、重试和失败率。 用 trace、请求日志和账单对齐，不只看单次 token 单价。

资料来源与后续阅读