claude-code-local用本地模型跑通 Claude Code

把 Claude Code 这样的编程代理留在本地跑，想想容易，真动手的没几个。claude-code-local 算是认真做了这件事的一个：在 Apple Silicon 上，用 MLX 搭起一个与 Anthropic API 兼容的本地服务，让 Claude Code 的请求根本不离开设备。

项目名字已经把定位说完了。它本质上是一个本地的 API 服务，Claude Code 照常发起请求，但流量不是进云端，而是落在本地模型上。仓库信息里列出的模型包括 Qwen 3.5 122B、Llama 3.3 70B 和 Gemma 4 31B，项目给出的参考速度是 65 tok/s（Qwen 3.5 122B）。

这个数字得带着条件看。本地推理速度跟芯片型号、内存容量、量化方式绑得很紧，65 tok/s 是项目方在特定环境下的参考值，换个配置结果可能差不少。更现实的问题是内存——122B 这种规模的模型对统一内存的要求很高，入门级 Mac 基本跑不动，能不能用主要看内存给不给力。

对真正有合规压力的人来说，数据能否留在设备上，比生成速度重要得多。

为什么有人愿意折腾这件事

把代码交给云端 AI 已经很普遍，但对一部分团队来说，这不是偏好问题，是红线问题。签了 NDA 的项目、医疗数据相关的处理、法务文档的分析——这些场景里，提示词经过哪台服务器本身就是合规风险。

claude-code-local 的价值就在这里：数据不出设备。项目描述里直接写了 offline 和 airgap-ready，意思是它不只是尽量少传数据，而是设计上允许你在断网环境里跑完整流程。这个特性对速度的牺牲，换来的是敏感场景下可以放心用 Claude Code。

接口兼容才是关键

在本地跑编程代理，真正的门槛不是能跑，而是怎么接。claude-code-local 把 Anthropic API 在本地重新实现了一遍，等于给 Claude Code 装了一个本地出口。这意味着不用改工作流、不用换工具，只是把后端从云端换成自己的机器。

当然代价也明显：本地模型的能力通常弱于云端大模型，速度受硬件上限约束，而且整套方案只支持 Apple Silicon。从仓库状态看，这个项目约 3.1k star、600 多个 fork，Python 实现、MLX 原生，还处于比较早期的阶段。

哪些人值得关注

• 在律所、医院或严格 NDA 环境里写代码的开发者，代码不能出内网
• 有大内存 Apple Silicon 机器、想摆脱云 API 依赖的 Claude Code 用户
• 对 MLX 推理与本地模型调度感兴趣的开发者，这个仓库是不错的参考实现

上手之前先想清楚

确认硬件是第一件事。Apple Silicon 是硬门槛，内存容量直接决定能跑多大模型，别拿低配机型硬扛 122B。

第二，以仓库 README 为准。模型清单和 Claude Code 的版本都在变，动手前先看当前文档，别照着旧教程走。

第三，接受体验落差。本地推理和云 API 比，体感延迟通常是另一个量级，对合规场景这是值得的交换；但如果只是想省钱，可能会失望。

claude-code-local 目前更像一个方向正确的早期方案，谈不上开箱即用。它最有价值的贡献，是证明了 Claude Code 这类工具完全可以脱离云端运行——而数据敏感场景确实需要这种可能。等更大内存的 Mac 普及、本地模型再迭代几轮，这类项目会越来越难被忽视。