在 AI 编码工具日益普及的今天，开发者面临的核心挑战不再是「能否使用 AI」，而是「如何低成本、高可用地持续使用 AI」。Claude Code、Cursor、Cline 等工具依赖 API 调用，但订阅费用高昂、速率限制频繁、免费额度不稳定等问题始终困扰着开发者。9router 作为一款开源的多提供商路由工具，正是为解决这些工程痛点而生。本文将从架构设计、故障转移策略、令牌压缩三个维度，深入剖析 9router 的核心技术实现。
一、整体架构：本地代理与智能路由
9router 的核心定位是一个本地运行的智能代理层，运行于开发者本地机器（默认端口 20128），充当 AI 编码工具与上游 LLM 提供商之间的「中间人」。这种架构设计带来了三个关键优势：首先，所有流量经过本地代理，开发者对数据有完全控制权，无需担心敏感代码泄露；其次，本地部署消除了网络延迟的二次叠加；第三，代理层可以在请求到达上游之前完成格式转换、令牌压缩、Quota 监控等预处理工作。
从技术栈来看，9router 基于 Node.js 20+ 与 Next.js 16 构建，前端使用 React 19 与 Tailwind CSS 4，数据存储采用 LowDB（基于 JSON 文件），流式响应通过 Server-Sent Events（SSE）实现。这种全栈 JavaScript 方案确保了开发与部署的便捷性，同时借助 Next.js 的服务端能力处理复杂的协议转换与负载均衡逻辑。
代理层的核心工作流程可以概括为「接收 - 转换 - 路由 - 转发」四步。当开发者配置 Claude Code 的 API 端点为 http://localhost:20128/v1 时，所有请求首先到达 9router 的 /v1/chat/completions 接口。代理层根据请求中的模型标识（如 cc/claude-opus-4-7）解析出目标提供商，然后进行两件关键操作：其一，如果启用了 RTK Token Saver，代理会先对请求中的 tool_result 内容进行压缩处理；其二，代理将请求从 OpenAI 格式转换为目标提供商所需的格式（支持 OpenAI ↔ Claude ↔ Gemini ↔ Cursor ↔ Kiro ↔ Vertex 等多种协议互转），最后转发至真实的上游 API。
二、三层故障转移：从订阅到免费的自动切换
9router 最核心的功能特性是「Smart 3-Tier Fallback」—— 智能三层故障转移机制。这一机制的设计灵感来源于生产系统中常见的高可用架构：通过预设多个「降级梯队」，当前一层服务不可用或配额耗尽时，自动切换至下一层，整个过程对上层应用透明无感知。
三层架构的具体划分为：第一层为 Subscription（订阅服务），包括 Claude Code Pro/Max、OpenAI Codex Plus/Pro、GitHub Copilot、Cursor IDE 等付费订阅，用户已为此支付月费，优先使用可以最大化订阅价值；第二层为 Cheap（廉价服务），典型代表如 GLM-5.1（$0.6/1M tokens）、MiniMax M2.7（$0.20/1M tokens）、Kimi K2.5（$9 / 月固定费用），这些服务按量计费，成本可控，作为订阅耗尽后的首选备份；第三层为 Free（免费服务），包括 Kiro AI（提供 Claude 4.5、GLM-5、MiniMax 的免费额度）、OpenCode Free（无需认证的直通代理）、Vertex AI（新 GCP 账号 $300 免费额度），这层作为最终的兜底方案，确保开发者永远不会被速率限制阻断工作流程。
实现层面，每个 Combo（模型组合）可以配置多达 5 个优先级梯队。9router 内置实时 Quota 追踪模块，持续监控每个提供商的剩余配额与重置时间（支持 5 小时周期、周周期、月周期等多种模式）。当第一梯队返回配额耗尽错误或 429 状态码时，路由引擎自动切换至第二梯队；若第二梯队同样不可用，则继续向下切换，直至找到可用服务。这种「自动降级」能力对于长时间编码会话尤为重要 —— 开发者启动一个复杂的代码审查任务后，无需值守监控，9router 会在后台悄然完成多次故障转移。
多账户支持进一步增强了系统的弹性。开发者可以在同一提供商下配置多个账号，9router 支持轮询（round-robin）或优先级两种负载均衡策略。当主账号配额耗尽时，系统自动启用备用账号，实现无缝衔接。这一设计对于需要高强度使用付费服务的团队尤为实用。
三、RTK 令牌压缩：无损压缩 20%-40%
AI 编码工具的一个显著特征是频繁调用工具（tools）——git diff、grep、ls、tree 等命令的输出会作为上下文发送回大模型。问题在于，这些工具输出往往占据 30%-50% 的输入令牌预算，而其信息密度极低：大量的文件路径、重复的日志行、无意义的空白字符充斥着上下文窗口。RTK（Real-Time Token compression Kit）正是为解决这一痛点而设计的令牌压缩模块。
RTK 的核心设计原则是「智能检测 + 无损压缩」。模块内置多种过滤器（filters），分别针对不同类型的工具输出优化：git-diff 过滤器识别并精简 Git 差异输出，git-status 过滤器压缩状态信息，grep 与 find 过滤器去除冗余的路径前缀，ls 与 tree 过滤器合并重复的目录结构标记，dedup-log 过滤器消除重复日志行，smart-truncate 过滤器在超长输出场景下进行语义保留的截断。
压缩的执行时机至关重要。RTK 运行在请求到达代理层之后、格式转换之前，这意味着压缩后的内容会直接进入目标提供商的上下文，避免了因格式差异导致的兼容性问题。RTK 的自动检测机制通过读取每个 tool_result 的前 1KB 内容，快速判断应使用哪种过滤器，无需开发者手动配置。
安全是 RTK 设计的另一重要考量。如果过滤器执行失败、抛出异常或压缩后内容反而增大，RTK 会静默回退，保留原始内容，确保请求不会因压缩模块的异常而失败。这种 Fail-Safe 机制使得 RTK 可以在生产环境中默认开启，无需担心引入新的故障点。
根据 9router 官方测试数据，RTK 可以在保持语义完整的前提下，将平均输入令牌数量减少 20%-40%。这意味着同样的订阅配额可以支撑更长时间的编码工作，或者在免费额度受限的场景下显著延长可用周期。结合 Caveman Mode（将模型回复压缩为简洁的技术风格，可额外节省高达 65% 的输出令牌），9router 构建了一套完整的令牌优化体系。
四、部署与集成：灵活的开发环境适配
9router 的部署灵活性是其工程实用性的重要体现。开发者可以选择在本地 localhost 运行（默认模式，无需公网暴露）、在 VPS / 云服务器上部署（通过 Nginx 反向代理实现 HTTPS 访问）、使用 Docker 容器化部署（一行命令启动）、或部署至 Cloudflare Workers（利用边缘网络实现全球加速）。环境变量配置简洁明了，JWT_SECRET 用于 Dashboard 认证，DATA_DIR 指定数据存储路径，REQUIRE_API_KEY 可在公网部署时强制启用 API Key 验证。
与主流 AI 编码工具的集成流程高度标准化。以 Claude Code 为例，只需修改配置文件中的 anthropic_api_base 为 http://localhost:20128/v1 并填入 9router 生成的 API Key，即可将所有流量路由至 9router。Cursor、Cline、Codex、OpenClaw 等工具均支持类似的 OpenAI 兼容端点配置，实现零学习成本的迁移。
结语
9router 的价值不在于重新发明了 LLM 调用方式，而在于将工程化思维引入 AI 编码工具的使用场景：通过多层故障转移确保服务永续、通过实时 Quota 追踪最大化订阅价值、通过 RTK 令牌压缩降低使用成本。这些策略并非新技术，但将它们整合为开箱即用的本地代理工具，并支持 40+ 提供商的灵活路由，这本身就是对开发者生产力的显著提升。对于每日与 AI 编码工具为伴的工程师而言，9router 提供了一套可控、可预测、低成本的调用框架，值得在实际项目中深入使用。
资料来源：9router GitHub 仓库（https://github.com/decolua/9router）