Free Claude Code：一个代理接通50个供应商与9大编程助手

一个本地代理，解决Coding Agent的三大痛点

经常使用Claude Code、Codex这类AI编程助手的开发者，多半被三个老问题反复折磨：长任务跑到一半报错、换个工具就得重新配环境、断网直接躺平。更棘手的是，某些Coding Agent只能连接厂商计费账号，稍不留神就触发风控甚至封号。

一个名为Free Claude Code（简称FCC）的MIT开源项目，用本地代理的思路来化解这些痛点。它将50个Provider（供应商）、约13亿Token的月度免费额度、9个Coding Agent全部整合到同一个本地代理中，做到一次部署、九大Agent全部代理接入。

本地代理（Local Proxy）是一种经典的中间件架构模式，它在客户端与远程服务之间插入一个本地运行的中间层，统一处理请求的路由、认证、缓存和故障恢复。这种模式在微服务架构中被称为Sidecar Proxy，Envoy和Nginx等项目广泛采用了类似思路。FCC将这一模式应用到AI编程助手领域，意味着所有从Coding Agent发出的API请求都先经过本地代理，再由代理决定转发给哪个后端Provider，从而实现统一管理和智能路由。

FCC采用MIT许可证独立开源，与Anthropic、OpenAI等厂商没有官方关联。它本质上是一个中间层——你的Coding Agent通过它统一调度后端的各种模型资源。

FCC到底解决了哪三个坑

坑一：Token烧钱快

在大语言模型的计费体系中，Token是最基本的计量单位。一个Token大约对应英文中的3/4个单词，中文中大约1-2个汉字。Coding Agent在工作时会消耗大量Token：每次对话需要发送完整的系统提示词（System Prompt）、工具定义（Tool Schema）、历史上下文以及用户当前的代码片段。一个复杂的代码重构任务，单次对话可能消耗数万乃至数十万Token。

单一供应商的主流模型配额用完后，要么充值要么换号。更麻烦的是，不同Coding Agent各自绑定自己的模型目录，想挑一个更优的组合根本没办法。FCC通过50个Provider目录，让所有Agent共享同一份模型清单，将分散在不同平台的免费额度统一调度，配额利用率大幅提升，能显著延长可用时间。

坑二：服务断连翻车

高负载时段的限速、网关抖动、上游服务挂掉，都可能让Coding Agent直接卡死，手动重启后上下文丢失、节奏全断。FCC内置**自动Failover（故障转移）**机制：当前Provider失败后自动切换到下一个可用模型，无需手动干预，所有客户端共享同一套兜底目录。

Failover是分布式系统中保证高可用性的核心机制。在传统的Web服务中，负载均衡器通过健康检查探测后端节点状态，一旦检测到故障就自动将流量切换到备用节点。FCC将这一机制引入LLM API调用场景：当某个Provider返回429（限速）、503（服务不可用）或超时错误时，代理会立即将请求重新路由到预设的备用Provider列表中的下一个可用节点。这个过程对上层的Coding Agent完全透明——Agent只看到一个始终可用的本地API端点，无需感知底层Provider的切换，从而避免了上下文丢失和任务中断的问题。

坑三：账号绑定与封号风险

某些Coding Agent只连厂商计费账号，直接用API Key跑容易触发风控。FCC通过本地代理隔离加多渠道兜底的方式降低这一风险，项目也强调采用「风控友好」策略，跟随上游条款调整，违规即移除。

三步上手：安装、启动、配通道

第一步：安装FCC

FCC基于Python 3.14 + UV构建，提供Windows、macOS、Linux三端桌面端。macOS或Linux用户在终端用curl拉取install.sh脚本管道执行；Windows用户则用PowerShell 5.1以上版本，通过irm拉取安装脚本执行。安装前建议先打开脚本文件检查内容，做到透明可查。

装好后桌面会出现Free Claude Code启动器，命令面板里也会多出以FCC开头的一系列命令——这就是9个Coding Agent的统一入口。安装过程中会询问是否一并安装RTK终端压缩器（可选的Token节省工具）。

RTK终端压缩器是一种应用在Coding Agent输出管道中的过滤器。当Coding Agent执行终端命令（如ls -la、git log、npm install等）并将输出结果回传给LLM作为上下文时，这些原始输出往往包含大量重复、冗余或对推理无关紧要的信息。例如，一次npm install可能输出数百行依赖解析日志，但模型真正需要知道的只是安装是否成功以及有无报错。RTK通过规则匹配和模式识别，将这些冗长输出压缩到原始体积的10%以下，从而让更多的Context Window留给真正重要的代码内容和对话历史。

第二步：启动FCC代理

三种方式都指向同一个本地代理：Windows或macOS双击图标启动，Linux跑fcc-server命令。启动后会自动打开Admin UI管理面板，默认地址为http://127.0.0.1:8082。查看版本号只需运行fcc-server --version，无需启动完整服务。

第三步：配一条可用的Token通道

以NVIDIA NIM为例（每月提供可观的免费额度），操作流程如下：在NVIDIA开发者后台创建API Key → 在浏览器打开Admin UI → 把Key贴进NVIDIA NIM API Key字段 → Model字段保持默认（NEMOTRON系列）→ 点Validate校验再点Apply应用。

如果想给本地代理加一层保护，可在Admin UI打开Proxy Authentication开关，调用时必须带Bearer Token，即使端口被扫到也无法滥用。Proxy Authentication是一项重要的安全措施。FCC默认监听在127.0.0.1（本地回环地址），理论上外部网络无法直接访问。但在某些场景下——例如开发者在同一局域网内共享代理、使用端口转发工具、或在云开发环境（如GitHub Codespaces、Gitpod）中运行时——本地端口可能被意外暴露。开启Proxy Auth后，每次API请求都需要在HTTP Header中携带Bearer Token进行身份验证，即使端口被扫描到，未授权的调用也会被拒绝。这是零信任安全模型在本地工具中的一种轻量级实践。

一份模型目录，覆盖9个Coding Agent

FCC的核心价值在于：后台统一管理模型配置，自动同步到所有客户端。全部Agent的启动命令以FCC开头，一行命令即可运行：

• Claude Code：fcc-claude
• Codex：fcc-codex
• Hermes：fcc-hermes
• 其余还包括Pi、OpenCode、Cline、DeepSeek Harness、Grok Build、Muse Code等，共9个Agent，一条命令对应一个。

切换Agent时无需单独配置环境变量，代理已在后台完成对接。如果某模型不在出厂目录里，可用Provider ID / Exact Model ID的格式在Admin UI手动填入。

值得强调的是，Agent的关键能力并没有被削弱：流式响应、Tool Calling（工具调用）、Interleaved Thinking（思考链）、图像理解都按上游兼容模型原样保留。Tool Calling是现代LLM Agent的核心能力之一，它允许模型在生成文本的过程中请求调用外部工具，如文件读写、终端命令执行、代码搜索等。OpenAI和Anthropic分别定义了各自的Function Calling/Tool Use协议，模型会返回结构化的JSON来指定调用哪个工具以及传入什么参数。Interleaved Thinking则是Anthropic Claude引入的Extended Thinking特性，模型在生成最终回答前会先输出内部推理过程，帮助完成复杂的多步编程任务。FCC作为代理层需要完整透传这些协议细节，包括流式SSE（Server-Sent Events）中的thinking块和tool_use块，任何字段的丢失或格式变更都可能导致Agent功能异常。

进阶的Tiered Routing功能甚至能给OPUS、SONNET、HAIKU分别指定不同Provider，比如OPUS走NVIDIA NIM、SONNET用OpenRouter免费档、HAIKU跑本地LM Studio上的Qwen3 Coder。这种分层调度的设计逻辑源自Anthropic Claude模型家族的层级划分：OPUS具备最强推理能力，适合复杂架构设计；SONNET是性能与成本的平衡点，适合日常编码；HAIKU轻量快速，适合简单补全和格式化。不同层级的任务对模型能力的要求差异很大，用OPUS来做代码格式化是浪费，用HAIKU来做架构重构则力不从心。Tiered Routing允许用户为每个层级分别指定最优的Provider和模型组合，实现成本与性能的精细化控制。

国内可用模型与本地兜底方案

对国内开发者而言，FCC最实用的价值在于「海外通道限速或封号时，国内模型加本地GGUF模型直接顶上」。

国内主流SaaS模型基本都已支持：通义千问、DeepSeek、智谱GLM、Kimi Code、硅基流动（SiliconFlow）、MiniMax M系列、阿里Coding计划等。本地LLM方面，Ollama、Ollama Cloud、LM Studio、llama.cpp均可接入，任意GGUF格式模型皆可运行。

GGUF（GPT-Generated Unified Format）是由llama.cpp项目定义的模型文件格式，它是当前本地部署开源大语言模型的事实标准。GGUF格式支持多种量化精度（如Q4_K_M、Q5_K_S、Q8_0等），开发者可以根据本地硬件的显存和内存容量选择合适的量化版本。例如，一个7B参数的模型在Q4量化下仅需约4GB显存即可运行。Ollama、LM Studio和llama.cpp都原生支持GGUF格式，它们在本地启动一个兼容OpenAI API格式的HTTP服务，FCC可以像对接云端Provider一样对接这些本地服务。这意味着即使在完全离线的环境下，开发者仍可通过本地GGUF模型驱动Coding Agent完成编码任务，尽管推理速度和模型能力会有所下降。

一个常见的国内兜底组合是：主用「通义千问Qwen3-Plus」，备用1为「DeepSeek Chat」，备用2为本地7B的「Qwen3 Coder GGUF」（完全离线可用）。将它们设为Failover Models列表后，Coding Agent在国内网络环境下能稳定运行，断网状态也能继续工作。

需要注意的是，Coding Agent通常需要支持工具调用（Tool Capable）的模型，本地模型也得有足够的Context容纳System Prompt加工具定义。FCC在选模型时会优先推荐带工具调用的版本，可在Admin UI搜索时进行筛选。

稳定性三件套与客户端矩阵

FCC通过三个机制保障使用体验：

• 自动Failover：Provider失败后自动切换，所有客户端共享兜底目录
• RTK终端压缩：可选过滤器，能把常见命令输出压缩到原始体积的10%以下，长时间运行Agent更省Token
• 本地五项优化：配额探针、前置检测、自动标题、建议回写、路径精简，完全不消耗Provider配额

客户端接入覆盖面也很广：终端用户直接跑命令；VSCode用户在settings.json中添加环境变量，把ANTHROPIC_BASE_URL指向本地代理；Codex扩展和App修改config.toml；JetBrains走ACP配置；甚至海外即时通讯Bot（如Telegram）也能通过Admin UI的Messaging通道接入，用/stats、/stop、/clear等命令在手机上同步模型目录、远程执行任务。

语音、卸载与合规要点

FCC还提供可选的语音转写功能，重新运行安装脚本时加上对应参数即可：--voice-nim（NVIDIA NIM转写）、--voice-local（本地Whisper）、--voice-all（两者都装）。本地Whisper支持CPU或CUDA加速。Whisper是OpenAI开源的自动语音识别（ASR）模型，支持多语言转写和翻译，本地部署时可以选择不同规模的模型版本（tiny、base、small、medium、large），在CUDA GPU加速下能实现接近实时的转写速度，即使在CPU模式下也能以可接受的延迟完成转录。

卸载过程很干净：停掉所有FCC进程后运行卸载脚本，会清除.fcc目录、桌面启动器和FCC命令，但保留UV、Python、Claude Code、Codex等Agent本体。也就是说卸载FCC不会影响已安装的Coding Agent，这个设计相当贴心。

合规方面有三条值得关注：其一，MIT许可证加风控友好策略；其二，生产环境建议开启Proxy Auth；其三，Provider与Fallback列表随时可调，完全由用户自己掌控。

总结：谁适合用FCC

一句话概括：FCC就是一个本地代理，把50个Provider、9个Coding Agent、语音转写、RTK压缩、自动Failover串成一条稳定的工作流。

它主要适合三类开发者：需要在多个Coding Agent之间灵活切换的人、对单一供应商Token配额没有安全感的人、以及想本地跑GGUF模型又要搭配Coding Agent使用的人。

上手路径也很清晰：先装FCC加NVIDIA NIM走通Quick Start，熟悉后在配置里填入国内模型做主用、海外模型做兜底，再在VSCode或Codex App中接入统一模型目录，最后按需添加语音功能。对于被厂商锁定和配额焦虑困扰的开发者来说，这样一个开源中间层无疑提供了更多自由度和掌控感。