Claude Code Router 深度拆解：一个本地网关如何统一 9 大 AI 编码 Agent，终结「多客户端配置地狱」

一款开源的本地模型网关与控制平面，让 Claude Code、Codex、Grok CLI、Kimi CLI 等 9 款主流编码 Agent 共享同一套 Provider 配置、路由规则和凭据池，支持条件路由、故障转移、Fusion 扩展和全链路可观测性。

0. 写在前面：多 Agent 时代的「配置地狱」

2026 年的 AI 编程生态，早已不是「一个 Copilot 打天下」的时代。Claude Code、Codex、Grok CLI、Kimi CLI、Kilo Code、OpenCode、Pi、ZCode……每款 Agent 都有自己的配置文件、API Key 管理、模型选择逻辑。切换一个模型需要改 N 个地方，某个 Provider 挂了要逐个客户端排查，Token 消耗分散在各个平台，想看汇总数据还得手动算。

更要命的是：不同 Agent 的能力边界不同。Claude Code 擅长长上下文推理，Codex 在代码补全上响应快，Grok CLI 有 xAI 生态加持。开发者常常需要在多个 Agent 之间切换，但每次切换都要重新配置 Provider、API Key、默认模型，配置重复、状态割裂、可观测性为零。

Claude Code Router（CCR）就是为解决这个问题而生的。它不是另一个 Agent，而是所有 Agent 的统一控制平面：一个本地网关，接收所有兼容客户端的请求，背后统一管理 Provider、模型、凭据、路由规则、扩展工具，并提供全链路的可观测性。

1. 核心定位：AI Agent 的「Kong 网关」

1.1 架构隐喻：从「API Gateway」到「Agent Gateway」

如果把 AI 编程生态比作微服务架构，那每个 AI Agent 就是一个「客户端服务」，每个 LLM Provider（Anthropic、OpenAI、DeepSeek、Kimi 等）就是一个「上游服务」。传统的 API Gateway（Kong、Nginx、Envoy）解决了以下问题：

• 统一入口：所有客户端请求走同一个 Gateway
• 路由与负载均衡：根据条件把请求分发到不同的上游
• 认证与限流：统一管理 API Key、配额、速率限制
• 可观测性：统一的日志、监控、追踪

CCR 就是 AI Agent 版的 Kong，但针对 LLM 场景做了深度定制：

• 协议适配：原生支持 OpenAI Chat/Responses、Anthropic Messages、Gemini Generate Content/Interactions 等多种协议
• 模型发现与映射：自动探测 Provider 支持的模型，支持模型别名、前缀匹配
• Token 级别的成本估算：根据模型定价计算请求成本
• Fusion 扩展：为不支持 Vision 的模型注入视觉能力，为不支持 Web Search 的模型注入搜索能力

1.2 设计哲学：Local-First，用户掌控一切

CCR 的设计哲学是 Local-First：

• 所有配置存储在本地（SQLite），不上传到任何云端
• 所有请求日志存储在本地，用户完全掌控数据
• 所有凭据（API Key）存储在本地，CCR 不会代理到任何第三方服务器

这意味着：

• 隐私安全：代码上下文、API Key 都不会离开本地机器
• 完全可控：用户可以随时查看、修改、删除所有配置和日志
• 离线可用：只要本地 Provider 可达，CCR 就能工作（不需要登录 CCR 的云服务）

1.3 支持的 Agent 生态

CCR 目前支持 9 款主流 AI 编码 Agent：

核心机制：CCR 提供一个本地 HTTP 端点（默认 http://127.0.0.1:3456），所有 Agent 配置为指向这个端点，而不是各自的 Provider 地址。CCR 接收请求后，根据配置的路由规则，将请求转发到实际的 Provider，并记录完整的请求/响应日志。

2. 核心能力：从「配置管理」到「智能路由」

2.1 Provider 管理：统一配置、自动发现、健康检查

CCR 的 Provider 管理模块解决了「同一个 API Key 配置 N 次」的痛点。

2.1.1 内置 Provider 预设

CCR 内置了主流 Provider 的预设配置，包括：

• Anthropic：Claude 系列模型，支持 Messages API
• OpenAI：GPT 系列、o 系列推理模型，支持 Chat/Responses API
• Google Gemini：Gemini 系列，支持 Generate Content/Interactions API
• OpenRouter：聚合 290+ 模型的第三方网关
• DeepSeek：国产大模型，性价比高
• SiliconFlow：国产 GPU 云服务商
• Moonshot / Kimi：月之暗面出品，1M 上下文
• Mistral：欧洲开源模型厂商
• Z.AI：字节跳动出品
• 阿里云百炼：阿里云大模型平台

用户只需选择一个预设，填入 API Key，CCR 会自动：

1. 探测协议：自动识别 OpenAI / Anthropic / Gemini 协议
2. 发现模型：调用 Provider 的模型列表接口，自动填充模型目录
3. 测试连通性：发送一个简单的请求，验证 API Key 是否有效

2.1.2 自定义 Provider

对于不在预设列表中的 Provider（如自部署的 vLLM、Ollama），CCR 支持自定义配置：

• Endpoint URL：Provider 的 API 地址
• Protocol：选择 OpenAI / Anthropic / Gemini / Custom
• API Key：认证凭证
• Model Mapping：手动配置支持的模型列表
• Headers：自定义请求头（如 X-Custom-Header: value）

2.1.3 凭据池（Credential Pool）

一个 Provider 可以配置多个 API Key，形成凭据池。CCR 支持：

• 轮询（Round-Robin）：依次使用池中的 Key
• 随机（Random）：随机选择一个 Key
• 加权（Weighted）：根据 Key 的权重分配请求
• 故障剔除：某个 Key 返回 429/401 时，自动切换到其他 Key

典型场景：

• 分散配额：一个 Provider 有多个账号，每个账号有独立的速率限制，用凭据池分散请求
• Key 轮换：定期更换 API Key，避免单个 Key 泄露影响全局
• 多租户：不同的 Key 对应不同的项目/团队，CCR 根据请求来源选择 Key

2.2 Agent Profiles：为每个 Agent 定制模型策略

CCR 的 Profiles 模块解决了「不同 Agent 用不同模型」的需求。

2.2.1 Profile 的组成

一个 Profile 包含：

• Profile Name：如 claude-code-default、codex-fast
• Target Agent：指定这个 Profile 适用的 Agent（Claude Code、Codex 等）
• Default Model：默认使用的模型
• Model Override：根据条件覆盖默认模型（如「请求体包含 code 字段时使用 gpt-5」）
• Scope：Profile 的作用范围（全局、某个项目、某个文件）
• Environment Settings：环境变量、启动参数

2.2.2 典型配置示例

场景 1：Claude Code 默认用 Opus 5，但简单任务降级到 Sonnet

{
  "name": "claude-code-adaptive",
  "agent": "claude-code",
  "defaultModel": "claude-opus-5",
  "modelOverride": [
    {
      "condition": {
        "bodyContains": "quick fix"
      },
      "model": "claude-sonnet-4-6"
    }
  ]
}

场景 2：Codex 用 GPT-5，但复杂推理切换到 o 系列

{
  "name": "codex-reasoning",
  "agent": "codex",
  "defaultModel": "gpt-5-turbo",
  "modelOverride": [
    {
      "condition": {
        "bodyContains": "analyze",
        "tokensThreshold": 10000
      },
      "model": "o3-mini"
    }
  ]
}

场景 3：Grok CLI 优先用 Grok 3，降级到 DeepSeek

{
  "name": "grok-fallback",
  "agent": "grok-cli",
  "defaultModel": "grok-3",
  "fallbackModels": ["deepseek-r1", "gpt-4o"]
}

2.2.3 多实例工作流

CCR 支持多实例 Agent App：不同的 Claude Code 实例使用不同的 Profile。典型场景：

• 实例 A：用 Opus 5 处理复杂架构设计
• 实例 B：用 Sonnet 做日常编码
• 实例 C：用 DeepSeek 做「快速原型验证」（成本敏感）

2.3 路由引擎：条件匹配、重试、故障转移

CCR 的路由引擎是其核心能力，支持精细化的请求控制。

2.3.1 条件路由

CCR 支持基于请求头和请求体的条件路由：

routing:
  rules:
    - name: "long-context-to-claude"
      condition:
        headerMatch:
          X-Request-Type: "analysis"
        bodyContains: "read the entire codebase"
      target:
        provider: anthropic
        model: claude-opus-5
    
    - name: "quick-fix-to-deepseek"
      condition:
        bodyContains: "fix this bug"
        tokensLimit: 5000
      target:
        provider: deepseek
        model: deepseek-chat
    
    - name: "default"
      target:
        provider: openai
        model: gpt-5-turbo

2.3.2 请求重写

CCR 支持在转发请求前修改请求体，典型场景：

• 注入 System Prompt：为所有请求添加「你是资深工程师」的 System Prompt
• 修改 Temperature：根据任务类型调整随机性
• 添加 Tool Definition：为不支持 Tool 的模型注入 MCP Tool 定义

rewrite:
  - condition:
      provider: openai
    transformations:
      - type: add-system-prompt
        content: "你是资深工程师，回答要简洁"
      - type: set-temperature
        value: 0.3

2.3.3 重试与故障转移

CCR 内置了健壮的重试机制：

• 重试策略：
  • 固定间隔：每次重试间隔固定时间（如 1s）
  • 指数退避：间隔时间指数增长（1s, 2s, 4s, ...）
  • 抖动：加入随机抖动，避免重试风暴
• 重试条件：
  • 状态码匹配：429（速率限制）、502/503（服务不可用）
  • 错误信息匹配：响应体包含 rate limit exceeded
• 最大重试次数：防止无限重试

故障转移：当某个 Provider 连续失败 N 次后，CCR 自动切换到备选 Provider/模型：

fallback:
  - provider: anthropic
    model: claude-opus-5
    maxFailures: 3
    fallback:
      - provider: openai
        model: gpt-5-turbo
      - provider: deepseek
        model: deepseek-r1

2.3.4 有序降级链

CCR 支持多级降级：

fallbackChain:
  - claude-opus-5
  - claude-sonnet-4-6
  - gpt-5-turbo
  - deepseek-chat
  - gpt-4o-mini

当 Opus 5 不可用时，自动降级到 Sonnet；Sonnet 不可用时，降级到 GPT-5……直到找到一个可用的模型。

3. Fusion 扩展：为模型「注入」缺失的能力

3.1 Fusion 的核心思想

不同 Provider 的模型能力不同：

• Claude Opus 5：强大的长上下文推理，但原生不支持 Web Search
• GPT-5 Turbo：支持 Vision，但在代码理解上稍弱
• DeepSeek R1：推理能力强，但多模态支持有限

CCR 的 Fusion 机制允许为模型「注入」缺失的能力：

• Fusion Vision：为不支持 Vision 的模型注入视觉能力
• Fusion Web Search：为不支持 Web Search 的模型注入搜索能力
• Fusion MCP Tool：为不支持 Tool 的模型注入 MCP 工具

3.2 Fusion Vision：让「文本模型」看懂图片

3.2.1 工作原理

Fusion Vision 的核心是视觉代理：

1. 用户发送一个包含图片的请求（如「分析这个架构图」）
2. CCR 检测到请求包含图片，但目标模型不支持 Vision
3. CCR 调用一个支持 Vision 的模型（如 claude-sonnet-4-6）提取图片内容
4. CCR 将提取的文本描述注入到原始请求中
5. CCR 将增强后的请求转发到目标模型

3.2.2 配置示例

fusionVision:
  enabled: true
  visionProvider: anthropic
  visionModel: claude-sonnet-4-6
  fallbackProvider: openai
  fallbackModel: gpt-4o

3.2.3 典型场景

• DeepSeek R1 + Vision：用 DeepSeek R1 做推理，但需要分析 UI 截图时，自动调用 Claude 提取图片内容
• 代码审查：用 Opus 5 审查代码，但遇到架构图时，自动注入视觉理解

3.3 Fusion Web Search：为模型接入实时信息

3.3.1 工作原理

Fusion Web Search 的核心是搜索代理：

1. 用户发送一个包含「查询实时信息」意图的请求（如「最新的 React 20 特性是什么」）
2. CCR 检测到请求需要 Web Search，但目标模型不支持
3. CCR 调用搜索 API（如 Tavily、Exa）获取搜索结果
4. CCR 将搜索结果注入到请求的 System Prompt 中
5. CCR 将增强后的请求转发到目标模型

3.3.2 配置示例

fusionWebSearch:
  enabled: true
  provider: tavily
  apiKey: ${TAVILY_API_KEY}
  maxResults: 5
  triggerKeywords:
    - "latest"
    - "recent"
    - "2026"
    - "what's new"

3.3.3 典型场景

• DeepSeek R1 + 实时信息：用 DeepSeek R1 做深度推理，但需要最新技术动态时，自动注入搜索结果
• 代码迁移：用 Claude 分析代码，但遇到新版本 API 时，自动搜索官方文档

3.4 Fusion MCP Tool：扩展模型的工具能力

3.4.1 工作原理

Fusion MCP Tool 允许为模型注入MCP（Model Context Protocol）工具：

1. 用户配置一个 MCP Server（如 filesystem、postgres）
2. CCR 在转发请求前，将 MCP Tool 定义注入到请求的 tools 字段
3. 模型返回 Tool Call 时，CCR 执行 Tool Call 并将结果返回给模型

3.4.2 配置示例

fusionMCPTool:
  servers:
    - name: filesystem
      command: mcp-server-filesystem
      args: ["--root", "/home/user/projects"]
    - name: postgres
      command: mcp-server-postgres
      env:
        DATABASE_URL: postgres://user:pass@localhost/db

3.4.3 典型场景

• 数据库操作：为 Claude Code 注入 postgres 工具，让它能直接查询数据库
• 文件系统操作：为 Codex 注入 filesystem 工具，让它能读写本地文件

4. 可观测性：全链路的请求追踪

4.1 为什么需要 Agent 级别的可观测性？

传统的 LLM 可观测性工具（如 LangSmith、Arize）关注的是单个请求的追踪，但在多 Agent 场景下，开发者更需要：

• 跨 Agent 的统一视图：所有 Agent 的请求日志集中在一个地方
• 成本归因：哪个 Agent 消耗了多少 Token，花了多少钱
• 性能对比：不同 Agent 的平均延迟、成功率对比
• 错误排查：某个 Agent 为什么失败，是 Provider 问题还是配置问题

4.2 CCR 的日志系统

CCR 的日志系统提供全链路的请求追踪：

4.2.1 日志字段

每条日志包含：

• 时间戳：请求发起和完成的时间
• Agent 信息：请求来源的 Agent（Claude Code、Codex 等）
• Provider 信息：实际处理请求的 Provider（Anthropic、OpenAI 等）
• 模型信息：实际使用的模型
• 请求详情：
  • 请求头（脱敏后的 API Key）
  • 请求体（System Prompt、User Message、Tool Definition）
• 响应详情：
  • 状态码（200、429、500 等）
  • 响应体（Assistant Message、Tool Call）
  • Token 使用量（Input、Output、Cache）
• 性能指标：
  • 延迟（从请求发起到收到响应的时间）
  • 首字节延迟（Streaming 场景）
• 成本估算：根据模型定价计算的美元成本

4.2.2 日志查询

CCR 支持多维度的日志查询：

• 按 Agent 过滤：只看 Claude Code 的请求
• 按 Provider 过滤：只看 Anthropic 的请求
• 按模型过滤：只看 claude-opus-5 的请求
• 按状态码过滤：只看失败的请求（4xx、5xx）
• 按时间范围过滤：最近 1 小时、24 小时、7 天
• 按关键词搜索：请求体或响应体包含特定文本

4.3 Dashboard 概览

CCR 提供一个可定制的 Dashboard，展示：

4.3.1 系统状态

• 总请求数：选定时间范围内的总请求数
• 成功率：成功请求的百分比
• 平均延迟：请求的平均响应时间
• 错误数：失败请求的数量

4.3.2 Token 与成本

• 总 Token 数：Input + Output + Cache Token
• Token 分布：Input / Output / Cache 的比例
• 估算成本：根据模型定价计算的美元成本
• 成本趋势：按时间维度的成本曲线

4.3.3 模型分布

• Token 分布：不同模型消耗的 Token 比例
• 请求分布：不同模型的请求次数比例
• 成本分布：不同模型的成本比例

4.3.4 账户余额

• 余额监控：Provider 账户的余额、订阅配额
• 配额预警：当余额低于阈值时发出警告

4.4 分享卡片

CCR 提供一键生成分享卡片的功能，适合社交媒体分享或团队汇报：

• AI Usage Wrapped：类似 Spotify Wrapped，展示你的 AI 使用年度总结
• CCR Route Map：展示你的 Agent → Provider 路由拓扑
• Model Leaderboard：你使用最多的模型排行榜
• AI Fuel Cockpit：展示账户配额的仪表盘
• Token Calendar Poster：类似 GitHub Contribution Calendar 的 Token 使用日历
• Spend Receipt：选定时间范围的账单详情

5. 部署与实战

5.1 部署方式选择

CCR 提供三种部署方式：

5.2 Desktop App 快速启动

1. 下载对应平台的安装包：

   • macOS：.dmg 或 .zip
   • Windows：.exe
   • Linux：.AppImage

2. 安装并打开 Claude Code Router

3. 添加 Provider：

   • 打开 Providers → Add Provider
   • 选择一个预设（如 Anthropic）
   • 填入 API Key
   • 点击 Test 验证连通性

4. 创建 CCR Client Key：

   • 打开 API Keys
   • 点击 Create Key
   • 这个 Key 将用于 Agent 认证

5. 启动 Gateway：

   • 打开 Server
   • 点击 Start
   • Gateway 默认监听 http://127.0.0.1:3456

6. 配置 Agent：

   • 打开 Agent Config
   • 选择 Agent（如 Claude Code）
   • 选择默认模型
   • 点击 Apply Profile

7. 开始使用 Agent，CCR 会自动记录所有请求

5.3 CLI 部署（适合服务器）

# 安装
npm install -g @musistudio/claude-code-router

# 启动 Web UI
ccr ui

# 后台运行（无界面）
ccr serve --no-open

CLI 的管理界面在 http://127.0.0.1:3458，Gateway 在 http://127.0.0.1:3456。

5.4 Docker 部署（适合团队共享）

# 克隆仓库
git clone https://github.com/musistudio/claude-code-router.git
cd claude-code-router

# 启动
docker compose up -d --build

Docker 通过 Nginx 将管理界面和 Gateway 统一暴露在 http://127.0.0.1:3458。

注意事项：

• 持久化：将 /data 目录挂载到宿主机，避免容器重启后数据丢失
• 认证：Docker 部署暴露在公网时，务必配置认证（API Key、Basic Auth）
• 备份：定期备份 config.sqlite 文件

6. 高级场景

6.1 多模型协同：让 Agent 在不同任务间自动切换

场景：你用 Claude Code 做开发，但希望：

• 简单的代码补全用 Sonnet（快速、省钱）
• 复杂的架构设计用 Opus 5（深度推理）
• 需要实时信息时用带 Web Search 的模型

配置：

profiles:
  - name: "claude-code-smart"
    agent: claude-code
    defaultModel: claude-sonnet-4-6
    modelOverride:
      - condition:
          bodyContains: "architecture"
          tokensThreshold: 10000
        model: claude-opus-5
      - condition:
          bodyContains: "latest"
        model: gpt-5-turbo
        fusion:
          webSearch: true

6.2 成本控制：设定 Token 上限

场景：你给团队成员分配了 CCR Client Key，但希望限制每个人的 Token 消耗。

配置：

apiKeys:
  - name: "team-member-alice"
    key: sk-ccr-alice-xxx
    limits:
      maxTokensPerDay: 1000000
      maxRequestsPerDay: 500
    expiresAt: "2026-12-31"

当 Alice 的 Token 消耗超过 1M 时，CCR 会拒绝她的请求。

6.3 团队共享：一个 Gateway，多人使用

场景：你的团队有 5 个人，每人都用不同的 Agent，但希望共享同一套 Provider 配置和 API Key。

架构：

1. 在团队服务器上部署 CCR（Docker 模式）
2. 为每个成员创建一个 CCR Client Key
3. 成员在本地配置 Agent 指向团队服务器的 Gateway
4. 所有请求统一经过团队的 CCR，集中管理凭据和监控成本

优点：

• 统一采购：团队统一购买 Provider API Key，避免个人分散采购
• 集中监控：团队负责人可以看到每个人的 Token 消耗和成本
• 权限控制：可以为不同成员设置不同的配额

6.4 Agent Relay：在 IM 中使用 Agent

CCR 提供了 AgentClaw 模块，支持在 IM 中使用 AI Agent：

• 支持的 IM：微信 iLink、企业微信、Slack、Discord、Telegram、LINE、飞书、钉钉
• 工作原理：CCR 作为 IM Bot 接收消息，调用配置的 Agent 处理，返回结果

典型场景：

• 在 Slack 频道中 @Bot，让它帮你生成代码
• 在企业微信中发消息，让它帮你分析日志
• 在 Discord 中讨论技术问题时，让它帮你搜索答案

7. 与其他方案的对比

7.1 vs OpenRouter

选择建议：

• 选 CCR：如果你用 Claude Code、Codex 等 Agent，重视隐私，希望本地管理配置
• 选 OpenRouter：如果你需要快速尝试多种模型，不介意请求经过云端

7.2 vs OmniRoute

选择建议：

• 选 CCR：如果你主要用 Claude Code、Codex 等 Agent，需要 Fusion 扩展
• 选 OmniRoute：如果你关注 Token 成本优化，需要智能路由和压缩

7.3 vs 原生配置

8. 冷静的边界分析

8.1 CCR 不适合什么场景？

1. 单 Agent 用户：如果你只用一个 Agent（如只用 Claude Code），CCR 的价值有限（但凭据池和日志功能依然有用）

2. 纯云端需求：如果你希望配置和数据存储在云端（如多设备同步），CCR 的 Local-First 设计不适合你

3. 轻量级使用：如果你只是偶尔用 AI 辅助编程，配置 CCR 的成本可能高于直接用原生配置

4. 需要 Token 压缩：如果你主要关注降低 Token 成本，OmniRoute 的 RTK/Caveman 压缩更合适

8.2 CCR 的技术债

1. Electron 依赖：Desktop App 依赖 Electron，安装包较大（~150MB）

2. 本地存储：所有日志存储在本地 SQLite，长期运行后日志文件会很大（建议定期清理）

3. 协议适配复杂度：支持多种协议（OpenAI / Anthropic / Gemini）意味着适配层可能有 Bug，需要持续维护

4. Fusion 性能开销：Fusion Vision 和 Web Search 会增加额外的请求延迟

8.3 未来可能的方向

根据官方 Roadmap 和社区讨论，CCR 未来可能支持：

• 多租户增强：更细粒度的权限控制和配额管理
• 云端同步：可选的云端配置同步（端到端加密）
• 更多 Agent 集成：支持更多新兴 Agent
• 性能优化：Fusion 模块的缓存优化
• 插件生态：支持第三方插件扩展 CCR 能力

9. 总结：Agent Gateway 的时代来了

Claude Code Router 的出现，标志着 AI 编程生态从「单 Agent 时代」迈向「多 Agent 协作时代」。就像微服务架构需要 API Gateway 一样，多 Agent 架构也需要 Agent Gateway。

CCR 提供的核心价值：

1. 统一配置：一套 Provider 配置，支持所有 Agent
2. 智能路由：条件路由、故障转移、降级链
3. Fusion 扩展：为模型注入缺失的能力
4. 全链路可观测性：统一的日志、Dashboard、成本追踪
5. Local-First：隐私安全、完全可控

如果你是重度 AI 编程用户，同时使用多个 Agent，或者需要团队共享 Provider 配置，CCR 值得一试。开源免费，GitHub Star 11k+，社区活跃，是一个「用过了就回不去」的基础设施。

GitHub 地址：https://github.com/musistudio/claude-code-router

官方文档：https://ccrdesk.top/

附录：常见问题

Q1：CCR 会代理我的请求到第三方服务器吗？

A：不会。CCR 是本地网关，所有请求从你的机器直接发送到 Provider 的 API 端点。CCR 只在本地记录日志和管理配置，不会上传到任何第三方服务器。

Q2：CCR 支持哪些 Provider？

A：CCR 支持所有兼容 OpenAI / Anthropic / Gemini 协议的 Provider，包括：

• 海外：Anthropic、OpenAI、Google、OpenRouter、Mistral
• 国内：DeepSeek、Moonshot/Kimi、SiliconFlow、阿里云百炼、Z.AI

Q3：CCR 的日志会占用多少磁盘空间？

A：取决于请求频率。每天 1000 次请求，每次平均 10KB 日志，一个月约 300MB。建议定期清理旧日志，或配置日志保留策略。

Q4：CCR 支持多语言吗？

A：CCR 的 Web UI 支持中文和英文，Agent 的提示词语言取决于你的请求。

Q5：CCR 是开源的吗？

A：是的，CCR 在 GitHub 上开源，采用 MIT 协议。

Q6：CCR 和 OmniRoute 可以一起用吗？

A：可以。你可以将 CCR 的上游配置为 OmniRoute，从而同时享受 CCR 的 Agent 管理和 OmniRoute 的 Token 压缩。