free-claude-code 是一个给 Claude Code 使用的 Anthropic-compatible proxy。
它的思路不是破解 Claude Code，也不是提供官方免费的 Claude 服务，而是在本地启动一个兼容 Anthropic API 形状的代理服务，把 Claude Code 发出的请求转发到其他模型后端。README 中提到的后端包括 NVIDIA NIM、OpenRouter、DeepSeek、LM Studio、llama.cpp 和 Ollama。
简单说，它想解决的是：你喜欢 Claude Code 的终端体验，但希望把模型请求接到别的 provider 或本地模型上。
它解决什么问题
Claude Code 的交互体验很适合开发任务。
它可以在终端里阅读代码、修改文件、执行命令、根据项目上下文推进任务。问题是，很多用户并不一定想始终使用同一个模型后端：
- 想试试 OpenRouter 上的不同模型
- 想用 DeepSeek 这类模型降低成本
- 想把请求接到本地 Ollama
- 想用 LM Studio 或 llama.cpp 跑本地模型
- 想在开发环境里统一走一个代理入口
- 想比较不同模型在 Claude Code 工作流里的表现
free-claude-code 的定位，就是在 Claude Code 和这些模型服务之间加一层兼容代理。
这样 Claude Code 仍然按 Anthropic 风格发请求，代理负责把请求适配到不同后端。
工作方式
可以把它理解成三层：
- 前端是 Claude Code
- 中间是
free-claude-code代理 - 后端是 OpenRouter、DeepSeek、本地模型或其他模型服务
Claude Code 以为自己在访问一个 Anthropic-compatible API。
代理收到请求后，根据配置选择目标 provider，转换必要字段，再把响应返回给 Claude Code。
这类结构的好处是，你不用改 Claude Code 本身，也不用让每个模型服务都原生支持 Claude Code。只要代理能把接口对齐，就能把更多模型接进同一个工作流。
支持哪些后端
README 中列出的方向包括：
- NVIDIA NIM
- OpenRouter
- DeepSeek
- LM Studio
- llama.cpp
- Ollama
这些后端代表了几类不同使用方式。
OpenRouter 更像模型聚合入口，可以测试不同商业和开源模型。
DeepSeek 适合关注中文能力、代码能力和成本的人。
LM Studio、llama.cpp、Ollama 则偏本地模型路线。它们适合在自己的机器或内网环境里运行模型，减少外部 API 依赖，也方便做离线实验。
NVIDIA NIM 则更偏企业和 GPU 推理部署场景。
为什么是 Anthropic-compatible proxy
Claude Code 本来围绕 Anthropic 的接口和模型习惯设计。
如果你想让它接入其他模型，最直接的问题就是接口不一致：
- 请求字段不同
- 模型名称不同
- streaming 格式不同
- tool use 表达不同
- 错误返回格式不同
- token 和上下文限制不同
代理层的价值就在这里。
它把 Claude Code 这边看到的接口维持在接近 Anthropic 的形状，再在后端做适配。对用户来说，配置一次代理后，就可以在相同 Claude Code 工作流里测试不同模型。
适合什么场景
free-claude-code 适合这些场景：
- 想用 Claude Code 的终端工作流
- 想测试非 Anthropic 模型在 Claude Code 里的表现
- 想降低模型调用成本
- 想把 Claude Code 接到 OpenRouter
- 想接入 DeepSeek 等兼容模型服务
- 想用 Ollama、LM Studio、llama.cpp 跑本地模型
- 想为团队统一配置一个模型代理入口
如果你只是正常使用官方 Claude Code，并且对模型提供方、成本和本地部署没有特殊需求，那不一定需要这类代理。
但如果你经常比较模型，或者希望让 Claude Code 接入本地和第三方模型，这类工具会很有用。
和直接用 OpenRouter 或 Ollama 有什么区别
直接用 OpenRouter、Ollama 或 LM Studio，通常只是和模型聊天，或者通过 API 调用模型。
free-claude-code 的重点不是替代这些服务，而是把它们接到 Claude Code 这个开发工作流里。
区别在于：
- 你仍然使用 Claude Code 的终端体验
- AI 可以围绕代码仓库执行任务
- 模型后端可以换成其他 provider
- 本地模型也有机会进入 Claude Code 工作流
- 配置集中在代理层，而不是每个工具单独改
所以它更像桥接器，而不是新的聊天客户端。
本地模型要注意什么
把 Claude Code 接到本地模型很有吸引力，但也要注意现实限制。
第一，模型能力差距。
Claude Code 的任务通常不只是聊天，还包括理解代码、规划修改、编辑文件、处理命令输出。本地小模型不一定能稳定完成这些任务。
第二，上下文窗口。
代码任务很吃上下文。模型上下文太小，会导致它读不全文件、漏掉约束，或者在多轮任务里丢失背景。
第三，tool use 兼容性。
Claude Code 工作流依赖工具调用和结构化行为。后端模型即使能聊天，也未必擅长遵循工具调用协议。
第四，速度和硬件。
本地模型的速度取决于机器配置、量化方式和模型大小。代码任务如果响应太慢，体验会明显下降。
所以，本地模型更适合实验、低风险任务和特定场景。真正复杂的代码任务，仍然要根据模型能力谨慎选择。
使用边界
这类项目很容易被标题误解，所以边界要说清楚。
第一，它不是官方 Claude Code 免费额度。
它只是把 Claude Code 的请求转发到其他模型后端。你使用 OpenRouter、DeepSeek、NVIDIA NIM 或其他 API 时，仍然需要遵守对应服务的价格、额度和使用条款。
第二，它不是绕过授权的工具。
使用任何代理工具时，都应该遵守 Claude Code、模型服务商和项目本身的许可协议。不要把它理解成规避官方限制的方式。
第三，代理会处理你的请求内容。
代码、命令输出、项目上下文可能会经过代理和后端服务。部署时要考虑日志、密钥、网络和隐私边界。涉及公司代码或敏感项目时，最好使用受控环境。
第四，不同模型表现差异会很大。
同样的 Claude Code 操作，换一个模型后可能出现完全不同的行为。不要默认所有模型都能替代 Claude。
和 LiteLLM 这类代理有什么关系
从思路上看，free-claude-code 属于“兼容接口代理”这一类工具。
这类工具的共同目标是减少上层应用和底层模型服务之间的耦合。上层应用只需要面对一个相对统一的接口，底层 provider 可以按配置切换。
不同项目的侧重点不同。有的更偏通用模型网关，有的更偏 OpenAI-compatible API，有的专门为 Claude Code 这类工具做适配。
free-claude-code 值得关注的地方，是它把目标场景直接放在 Claude Code 上，而不是做一个泛泛的聊天代理。
适合怎样的用户
它更适合有一定折腾能力的用户：
- 熟悉 Claude Code
- 知道 API key 和模型 provider 怎么配置
- 能理解代理服务的启动和环境变量
- 能排查网络、端口、模型名称和 streaming 问题
- 愿意比较不同模型在代码任务里的表现
如果你只想开箱即用，官方配置通常更省心。
如果你愿意搭代理、换模型、调参数，并且想让 Claude Code 进入更多模型环境，这个项目就值得研究。
参考
最后一句
free-claude-code 的价值，不在于“免费”这个词，而在于它把 Claude Code 和更多模型后端之间接了一座桥。
当你想保留 Claude Code 的开发体验，同时测试 OpenRouter、DeepSeek、本地模型或企业推理服务时，这类 Anthropic-compatible proxy 就有了用武之地。