9Router教程：免费接入Claude的AI令牌方案

什么是9Router？

9Router是一个开源的AI路由代理工具，核心卖点是「60+ AI提供商、零停机」——把OpenAI、Claude、Gemini、Ollama等不同来源的模型统一到一个端点下，再按需分配给客户端。据其GitHub页面介绍，它同时定位为「免费AI路由与令牌节省器」，内置了一批免费额度的提供商（free tier providers），这也是这条YouTube教程能够实现「免费使用Claude」的前提。

需要先说清楚：这套方案的本质不是破解Claude的付费墙，而是把多个免费额度来源（如KiRo AI、OpenCode、Gemini、OpenRouter等）聚合起来，伪装成一个统一的API端点，再喂给Claude桌面客户端的开发者模式。它依赖的是各家免费层的额度，而非无限量免费。

部署9Router：两条命令搞定

教程演示的安装方式来自GitHub的Quick Start部分，只需要两条命令：第一条拉取并安装9Router仓库，第二条启动服务。UP主在视频中重新完整跑了一遍安装流程，确认命令执行后终端会提示安装完成，随后启动服务会输出一个本地访问链接。

把该链接粘贴到浏览器，会进入9Router的登录页，默认密码为123456。登录后可以看到两个关键信息：Endpoint（端点地址）和API Key（密钥）。端点地址后面要填进Claude客户端，密钥则可以新建——教程中就专门为Claude AI创建了一个名为「free api key for claude ai」的新密钥。

连接免费提供商

进入Providers页面后，可以看到Claude Code、Anti-Gravity等分类，往下是免费层提供商列表。不同提供商的接入方式不一样：OpenCode自动就绪，Gemini、OpenRouter、Ollama走API Key，KiRo AI则走AWS Builder ID的OAuth流程。

视频中以KiRo AI为例演示了完整授权：点击Add Connection → 选择AWS Builder ID → 浏览器打开后选择「Continue with Google」→ 选定Google账号 → 复制页面上的验证码 → 回到9Router粘贴并确认 → 授权通过后状态变为active。点击Test Connection可以看到success提示，说明该提供商已可用。同样的流程可以套用到其余免费提供商上。

OAuth 与 API Key 两种接入方式的区别：API Key 是静态凭证，直接在 9Router 的配置表单里粘贴即可，适合 OpenRouter、Gemini 这类在控制台自助生成密钥的服务；OAuth 则是委托授权流程，9Router 不接触用户的账号密码，而是跳转到提供商的授权页面，由用户登录后颁发一个有时效的访问令牌（access token）和刷新令牌（refresh token）。KiRo AI 走 AWS Builder ID 的 OAuth，意味着 9Router 是以第三方应用身份获得访问权限，令牌过期后需要刷新，若提供商回收权限或调整授权范围，连接就会失效。这也解释了为什么 OAuth 类提供商的状态可能从 active 变为异常，需要重新授权。

免费层额度的常见形态：各家免费层通常以「每分钟请求数」「每日请求数」或「每月 token 总量」限流，部分服务还会在高峰期限速或降低模型等级。9Router 把这些配额聚合成一个池子，但池子里每个来源的限流是独立计算的，因此 Combo 中模型越多，理论上可用的总请求量越大，代价是不同来源的响应质量和延迟差异明显。

在Claude客户端中启用开发者模式

这是整套方案里最容易被卡住的一步。Claude桌面客户端默认不显示第三方推理入口，需要先进入Help → Troubleshooting，打开「Enable developer mode」，菜单里才会出现「Configure third-party inferences」。

进入配置后：Gateway选择gateway；Base URL填入9Router复制来的端点地址；API Key填入刚创建的密钥；Auth Scheme选择Bearer；然后取消勾选Model Discovery（稍后再开）。这样Claude客户端就会把请求转发到9Router，而不是直连官方API。

Base URL、API Key 与 Auth Scheme 三者的关系：这三项共同决定了客户端如何构造 HTTP 请求。Base URL 是请求的目标地址前缀，客户端会把原本发往官方 API 的路径拼在其后；API Key 用于身份识别，9Router 用它判断请求属于哪个用户、可调用哪些提供商；Auth Scheme 决定密钥以何种形式放进请求头——选 Bearer 时，客户端发送 Authorization: Bearer <你的密钥>，这与 OpenAI 兼容接口的通行做法一致。如果 Auth Scheme 选错（例如选了 x-api-key 而服务端只认 Bearer），请求会返回 401 未授权，这是配置阶段最常见的报错来源。

Model Discovery 的作用：开启后，客户端会向网关请求可用模型列表，并据此填充模型选择器；关闭时客户端只使用内置或手动指定的模型。教程中先关闭、建好 Combo 后再开启，是为了避免在 Combo 尚未就绪时拉到空列表或缓存了旧结果。

创建Combo：多模型聚合的关键

Combo是9Router的核心概念——把多个模型打包成一个虚拟模型，按策略调度。创建时有一个硬性要求：名称中必须包含「claude」关键词，否则该Combo不会出现在Claude客户端的模型选择器里。视频中UP主专门对比了自己早先创建的test combo，因为没有claude关键字，在Claude客户端里完全看不到。

添加模型时，可以把各免费提供商的模型全部勾选进来，包括Gemini 2.5、Gemini 3 Flash、Claude Sonnet 4.5、Big Pickle、DeepSeek^广告、GLM 5.3等。模型顺序可以用箭头调整，排在前面的优先使用。调度策略有两种：

• Fallback（按序回退）：线性使用，第一个模型不可用或失败才切到下一个；
• Round Robin（轮询）：第一个请求走Big Pickle，第二个走Gemini 2.5，第三个走下一个，依次轮转。

Fallback 与 Round Robin 的取舍：Fallback 追求结果可用性，请求总是从首选模型开始，只有失败才降级，因此输出风格相对稳定，适合对模型一致性有要求的任务；代价是首选模型一旦限流，每次请求都要先撞一次失败再回退，延迟叠加。Round Robin 把请求均匀分摊到多个来源，能最大化利用各家的独立配额、降低单一来源的限流压力，但同一会话中不同请求可能由不同模型回答，输出风格和上下文理解会出现波动，对多轮对话尤其明显。实践中常见做法是把质量最高、配额最少的模型放在 Fallback 链首，把配额充裕的模型放在轮询池中承担批量任务。

虚拟模型的意义：Combo 对外表现为一个模型 ID，客户端无需感知背后有哪些提供商。这种抽象让切换供应商、调整顺序都不必改动客户端配置，也是 9Router 作为「统一路由层」的核心价值所在。

启用Model Discovery并验证

Combo建好后，回到Claude设置重新打开Model Discovery开关，点击Test，出现绿色对勾说明模型发现测试通过。然后Apply Changes并重启Claude。重启后客户端会提示当前模式不可用——按视频的说法，这个警告不影响使用。此时模型选择器里应该能看到名称带claude的Combo。

实测环节：选中「cloud free combo」发送请求，首次请求需要等待一段时间（走的是免费层，冷启动较慢），之后响应恢复正常。视频中让模型生成一个井字棋HTML页面，最终产出了可运行的对战逻辑。

几点现实提醒

这套方案在视频里跑通了，但有几个点素材本身也间接暴露了：免费提供商的额度、稳定性和可用模型会随时变化，Combo里任何一个来源失效都可能导致回退链路变长；首次请求延迟明显；Claude客户端在非官方模式下会持续显示警告。另外，把第三方网关接入官方客户端是否符合各家服务条款，需要使用者自行判断。9Router的价值更多在于「统一路由层」这个思路——对需要频繁切换模型、又想节省令牌成本的开发者来说，这比单纯薅免费额度更值得研究。