cc-router 多模型聚合网关
在本地聚合多家模型额度，为编程工具自动调度与故障切换。
- Star 数
- ★ 286
- 最近更新
- 1 天前
- License
- MIT
- 主语言
- Rust
- FA 评分
- 77/100 · 表现良好
30 秒速览
- 运行形态
- 可在哪里用
- 通用 · 跨平台Codex · Claude Code · OpenAI API · Claude APIChatGPT · Claude.ai（部分支持）
- 费用
- 软件免费，模型调用费用自付
- 上手难度
- 低 · 几分钟可跑通
- 开始前需要
- 典型场景
- 拥有两份或更多小额度 Coding Plan 的开发者，希望按顺序耗尽额度，并在某个订阅限流或失败时自动切换。
- 不适合
- 只使用单一厂商官方客户端、不愿承担订阅 Key 代理风控风险的用户
- 需要图片输入或 OpenAI 专有工具（file_search、web_search、computer_use）的 Codex 用户
- 源码审查
- 77/100 · 表现良好
这个 Agent 能做什么，适合哪些场景？
cc-router 是一个基于 Tauri 2、Rust、React 19、TypeScript 5 和 Tailwind 4 的本地桌面网关，默认监听 127.0.0.1:23456。它将 Token Plan、Coding Plan 和按量 API 额度组织成 fable、opus、sonnet、haiku 四个虚拟模型槽位，并按顺序、轮询或会话亲和策略选择真实模型。客户端可以通过 Anthropic Messages、OpenAI Responses 或 OpenAI Chat Completions 接入，网关再调用 Anthropic、OpenAI 或 Gemini 兼容的上游接口。产品提供请求日志、统一用量查看、消费小票导出、自动切换和故障转移，并支持简体中文、英语和日语界面。它适合希望在 Claude Code、Codex、OpenCode、OpenClaw 等工具间复用多家额度的用户，但协议翻译存在功能损失，订阅密钥经第三方代理的做法也可能违反部分服务商条款。
客户端把请求发送到本机的 /v1/messages、/v1/responses 或 /v1/chat/completions。cc-router 验证设置页生成的访问令牌，把客户端模型名或别名归一到 model-fable、model-opus、model-sonnet、model-haiku，再依据绑定的真实模型、额度、顺序或轮询规则及会话亲和状态选择订阅。Anthropic Messages 上游可走近乎原样透传；OpenAI Responses、Chat Completions 与 Gemini generateContent 或 /v1beta/interactions 上游则经过协议翻译，包括 thinking/reasoning 和工具调用映射。失败或限流时，网关可以切换到其他已绑定订阅，并在本地界面记录入口协议、路由结果和 token 用量。它还能生成自签 CA 与服务器证书以服务只接受 HTTPS 的客户端，并可选择开放 /ui/ 网页管理界面。
- 拥有两份或更多小额度 Coding Plan 的开发者，希望按顺序耗尽额度，并在某个订阅限流或失败时自动切换。
- 同时使用 Claude Code 与 Codex CLI 的个人开发者，希望让 Anthropic Messages 和 OpenAI Responses 客户端共享同一套虚拟模型与用量统计。
- 重视 prompt cache 的多会话或子代理用户，希望通过会话亲和让同一会话固定使用同一订阅，同时在不同会话间均衡分配。
- 使用 Open WebUI、Cherry Studio、Cline 或 LobeChat 的用户，需要用 OpenAI Chat Completions 接口访问统一配置的多家模型。
- 持有 DeepSeek、GLM、Kimi、MiniMax、OpenAI、Anthropic、Gemini 或其他兼容端点凭证的团队，希望通过本地 GUI 管理路由，而不是反复修改各客户端配置。
- 需要审计个人模型消耗的用户，希望集中查看请求日志，并导出超市小票样式的 token 消费凭证。
如何安装或部署这个 Agent？
普通用户从 GitHub Releases 下载对应安装包：macOS 提供 Apple Silicon 和 Intel DMG，Windows 提供 x64 EXE、x64 MSI 与 arm64 EXE，Linux 提供 x64/arm64 AppImage 和 DEB；Linux 推荐 AppImage，因为其支持应用内自动更新。安装并首次启动后，在 onboarding 中选择厂商和接入点，填写 API Key 或使用受支持的 OAuth 登录，抓取模型列表，然后把订阅绑定到四个虚拟模型。源码开发需要 Node.js 20 以上、pnpm、Rust 1.88 以上；macOS 还需要 Xcode CLT。开发命令为 pnpm install 和 pnpm tauri dev，打包命令为 pnpm tauri build，产物位于 src-tauri/target/release/bundle/。Windows 开发必须使用 MSVC toolchain，并安装包含“使用 C++ 的桌面开发”工作负载的 Visual Studio Build Tools。
如何使用这个 Agent？
先在桌面应用中添加至少一个订阅，为 model-fable、model-opus、model-sonnet、model-haiku 绑定真实模型并选择顺序、轮询或会话亲和。Claude Code 使用 http://127.0.0.1:23456 作为 ANTHROPIC_BASE_URL，并把应用设置页显示的 token 写入 ANTHROPIC_AUTH_TOKEN；模型可设为 model-fable、model-opus、model-sonnet 或 model-haiku。Codex 将 provider 的 base_url 配为 http://127.0.0.1:23456/v1、wire_api 配为 responses、env_key 配为 OPENAI_API_KEY，再在 profile 中选择 model-sonnet 等虚拟模型，之后运行 codex -p cc-router。Chat Completions 客户端通常使用 http://127.0.0.1:23456/v1、应用 token 和任一虚拟模型或受支持别名。Claude Desktop 需要先在应用中生成本地 HTTPS 证书并按其集成方式配置。若启用网页界面，可访问 http://127.0.0.1:23456/ui/；改为监听 0.0.0.0 后局域网设备也能访问，但关闭登录鉴权会允许同网段设备修改配置。
这个 Agent 有哪些优点和局限？
- 一个本地服务同时提供 Anthropic Messages、OpenAI Responses 和 OpenAI Chat Completions 三种入口，可服务多类编程及聊天客户端。
- 支持顺序、轮询、会话亲和、自动切换和故障转移；会话亲和兼顾多订阅均衡与 prompt cache 命中。
- 既支持多家内置厂商预设，也允许添加 Anthropic、OpenAI或 Gemini 兼容的自定义端点。
- 提供桌面 GUI、可选网页管理界面、请求日志、统一 token 统计和小票式导出，不要求用户自行编写路由代码。
- 可生成本地自签 CA 和服务器证书，从而连接只允许 HTTPS 的客户端。
- OpenAI Responses 入口不支持图片输入，也不支持 file_search、web_search、computer_use 等 OpenAI 专有工具，parallel_tool_calls 会被忽略。
- 协议翻译无法保留所有语义；例如 OpenAI 或 Gemini 出口可能丢失 cache_control，因此存在原生 Anthropic 端点时应优先使用原生路径。
- Chat Completions 入口不支持旧版 functions/function_call；n>1、logprobs 和 JSON Schema 强制 response_format 也会被忽略。
- 将 per-seat Coding Plan 或 Token Plan 的订阅密钥接入第三方代理并混合调度可能触发限速、封号或取消订阅，部分厂商条款并未明确允许这种用法。
- 依赖本机持续运行和上游网络；局域网监听或关闭网页界面鉴权会扩大配置与凭证的暴露风险。
- Codex 的 ChatGPT Plus/Pro 和 Kiro OAuth 出口被项目明确标为有封号风险的灰色用法，不适合作为主力线路。
这个 Agent 与同类方案有什么区别？
与让 Claude Code、Codex 或 OpenCode 直接连接单一厂商相比，cc-router 增加了一层本地网关，可把多份额度放进统一虚拟模型并自动负载均衡或故障转移，代价是需要维护本地服务、订阅映射和访问令牌。原生 Anthropic 透传最能保留请求语义；选择 OpenAI 或 Gemini 兼容出口可扩大供应商范围，但需要协议翻译，并可能丢失 cache_control 等信息。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| cc-router 多模型聚合网关 当前 | 77 · 表现良好 | 桌面应用免费 + 模型费 | ★ 286 | 1 天前 | Rust | Codex · Claude Code · OpenAI API · Claude API |
| OmniRoute — 免费 AI 网关 | 60 · 存在缺口 | 命令行工具免费 + 模型费 | ★ 81k | 今天 | TypeScript | Codex · Claude Code · OpenAI API · Claude API |
| Waku 编程智能体桌面端 | 69 · 存在缺口 | 桌面应用免费 + 模型费 | ★ 1.6k | 24 天前 | Rust | Codex · Claude Code |
| My Free Code | 54 · 缺口较多 | 自托管服务免费 + 模型费 | ★ 628 | 6 天前 | Python | Claude Code · OpenAI API · Claude API |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
默认监听 127.0.0.1，Web UI 和局域网暴露需显式开启，客户端请求头转发默认关闭；架构图及入站、出站、协议转换、字段丢弃和 OAuth 路径说明非常具体，因此数据流透明度满分。README 也明确提示服务条款、封号、额度消耗和无认证 LAN 管理风险。扣分在于所给材料未展示凭据在本地的存储、加密、日志脱敏或删除机制，也未完整说明 shell 插件权限及 OAuth 令牌权限范围。配置写入会备份 Codex 原文件，但其他设置、证书、订阅和导出操作的确认及回滚流程不完整。发布流程使用冻结锁文件、签名和 macOS 公证，并含依赖安全覆盖项，但未提供 SBOM、审计结果或依赖更新政策，工作流依赖也使用可变主版本标签。MIT 文件给出版权主体，但发布者企业身份仍未知。
README 中协议、端点、模型别名、调度方式和平台包说明总体自洽，发布工作流也与所列平台基本吻合；但大量兼容性、自动切换和无中断表述仅为文档声明，未由给定测试或实现文件交叉证明。依赖及构建环境版本较明确，使用 frozen lockfile、平台专用 runner 和系统包安装步骤，但未提供锁文件、Rust 清单或后端依赖内容，无法完整判断依赖可获得性。工作流对缺失签名密钥给出明确错误，README 说明部分不支持字段会返回 400 或被忽略；普通运行时、上游失败和认证错误的信息质量未展示，因此未满分。
面向 Claude Code、Codex、桌面客户端及 OpenAI 兼容工具的受众和场景划分清楚，覆盖三种入站协议、多种出站协议、虚拟模型、调度策略及多语言界面。对 Responses 不支持图像和 OpenAI 专属工具、Chat Completions 忽略的参数、协议转换损失及 OAuth 灰色风险均有明确边界说明，故能力边界满分。模型别名、通配符、会话亲和键和端点选择写得具体，但宽泛通配别名以及部分静默忽略参数可能产生非显然路由，触发精度扣分。macOS、Windows、Linux及多架构安装包、配置示例和本地 HTTPS/LAN 场景覆盖充分。
文档从架构、快速开始、客户端接入、入站和出站协议到 FAQ 分层清晰，安装矩阵、配置片段和行为示例充分。已明确列出协议转换损失、不支持功能、静默忽略字段、服务条款及账户风险，已知限制处理完整。MIT 许可证正文与元数据一致。命名方面产品名和核心虚拟模型稳定，但大量通配别名会把未来或并不存在的型号名称归一化，降低可预测性。package.json 提供 5.0.0 且发布由标签触发，并提到 Releases，但材料中没有变更日志、兼容性迁移说明或版本政策。仅能看到版权昵称和欢迎 PR，缺少明确维护团队、支持渠道、安全报告路径或维护承诺。
GUI、生成配置、统一端点、请求日志、用量收据、模型映射和自动故障切换形成了可直接消费的输出，针对分散订阅和多客户端配置提供明显的整合价值，因此输出可用性和边际价值评分较高。成本收益方面，文档同时披露可能节省订阅成本以及封号、限流、异常额度消耗和协议语义损失，但节省金额、故障切换效果和兼容范围没有静态证据或量化依据，故不满分。
README 将部分声明指向具体配置、端点、提供商描述目录和发布产物，package.json、LICENSE 与发布工作流也能支持技术栈、版本、许可、平台构建及签名相关声明。扣分在于核心路由、凭据处理、故障切换和协议转换实现未包含在材料中，多项产品声明只能追溯到同一 README。不同文件可交叉印证产品名、版本、许可证、Tauri 技术栈和发行平台，但不能独立印证运行行为。文档较好地区分了已知限制、风险和推荐做法，不过“节省成本”“无中断”“几乎原样透传”等营销或行为结论没有明确标为未经验证的主张。
- OAuth 订阅账户路径被作者明确标为灰色地带，可能触发限流、封号或订阅取消；不应将主账号或关键业务依赖于该路径。
- 启用 0.0.0.0 监听并关闭 Web UI 登录后，同一网络中的任何设备都可能修改配置；仅应在受信网络中使用，并保留认证。
- 提供商 API 密钥、代理访问令牌、OAuth 令牌以及请求日志的存储、加密、脱敏和删除方式未在所给材料中得到证明。
- 协议转换会丢弃或静默忽略部分字段，宽泛模型通配别名也可能把意外名称路由到虚拟模型；接入前应核对实际模型、计费及功能语义。
- 下载链接使用 latest 和第三方中国镜像；虽然发布流程生成签名，但材料未说明用户如何验证镜像文件的签名或校验值。
最近版本
来自该项目 GitHub Releases 的最新发布记录，说明为上游原文摘录，未经本站改写或测试。
-
v6.5.0 v6.5.0 Timetable
发布说明摘录
v6.5.0 · Timetable --- 中文 这一版新增繁体中文界面，并让订阅的每个模型槽位可以按星期和时段换用不同模型；另外新增「自动检查更新」开关。注意：模型槽位留空的订阅升级后不再被调用，详见「其他」。 新功能 - 繁体中文界面：设置 → 通用 → 界面语言 里可以选「繁體中文」，用词按台湾习惯，港澳共用。 - 覆盖桌面界面、网页界面、终端界面、托盘菜单、厂商名称与说明，以及这份更新内容。 - 「跟随系统」时，繁体中文（台湾 / 香港 / 澳门）与粤语系统显示繁體中文，其余中文系统仍显示简体中文。 - 中日文字体按界面语言切换，繁中与日文不再按简中字形显示。 - 模型槽位按时段切换模型（#62，感谢 @WayneOffice 建议）：适合同一订阅白天、夜里分别对不同模型有优惠的情况。在订阅编辑页的「模型槽位」卡片里设置。 - 每个槽位有一个默认模型，外加最多 16 条有序的时段规则：选星期（每天 / 工作日 / 周末 / 自定义）、起止时间（精确到半点，可以跨零点）和模型，排在前面的规则优先。 - 每条时段可以单独设置思考强度，选「跟随槽位」时用默认模型后面设的思考强度。 - 默认模型可以选「不设置（时段外不可用）」：规则之外的时间，这个订阅不参与该槽位的调度，请求交给虚拟模型绑定的其他订阅。 …在 GitHub 查看 ↗ -
发布说明摘录
v6.4.0 --- 中文 这一版新增「自定义 (System One 决策模型)」入口，可以把局域网或第三方的 Jev / Clef 决策模型端点手动接进 model-jev；同时修复了长时间流式生成在 10 分钟处被切断的问题。升级后已有订阅的行为不变。 新功能 - 自定义 System One 决策模型入口：添加订阅时，在厂商下拉的「自定义」分组里选「自定义 (System One 决策模型)」，手动填写 Base URL、接口路径、API Key 与 Jev 模型，适合局域网里另一台机器上的 Ollama、自建网关或其他第三方托管。 - 订阅只能绑定到 model-jev，请求原样转发，不做协议转换。 - 鉴权方式可选 Authorization: Bearer 或 x-api-key；上游不校验 API Key 时填任意值即可。 - Jev 模型必填：自定义订阅没有示例模型可以回退，留空或只填空格都无法保存，编辑时也不能清空。内置 System One 订阅的 Jev 模型仍然可以留空。 - 终端界面的新建向导同样支持，选这个协议时表单里只有一行 Jev 模型。 …在 GitHub 查看 ↗ -
发布说明摘录
v6.3.1 --- 中文 这一版把 OpenAI 风格的模型别名改成 astra / sol / terra / luna 四档，与 fable / opus / sonnet / haiku 一一对应；设置页的网页界面卡片现在直接显示登录令牌。别名调整是不兼容变更：gpt-*-sol、gpt-*-terra、gpt-*-luna 各下移一档，gpt-5.5 这类纯版本号和 gpt-*-mini 不再识别，在 Codex 等客户端里用了这些名字的，升级后需要按下面的对照改一次。使用 model-* 或 claude-* 名字的不受影响。 新功能 - OpenAI 风格模型别名改为四档（不兼容变更）：客户端可以写的 gpt-* 别名改为 astra / sol / terra / luna，按名字里的档位段匹配，不看版本号，gpt-6-sol、gpt-6.1-sol、openai/gpt-6-sol 都算 sol 档。 - gpt-*-astra 对应 model-fable（新增）。 - gpt-*-sol 对应 model-opus（原来对应 model-fable）。 …在 GitHub 查看 ↗