把 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 普及、本地模型再迭代幾輪，這類專案會越來越難被忽視。
評論
暫無評論
成為第一個評論的人