Running Claude Code Locally: A Fully Offline AI Coding Solution for Apple Silicon

AI coding assistants are transforming the way developers work — but for many teams in sensitive industries, one obstacle remains unavoidable: code simply cannot be uploaded to the cloud. The open-source project claude-code-local offers a direct solution: running Claude Code entirely on local hardware, 100% offline, purpose-built for privacy-critical workflows such as NDA-governed projects, legal work, and healthcare.

The project has already earned around 2,509 stars and 491 forks on GitHub, developed in Python, with a solid and growing community following.

The Core Idea: An MLX-Native Anthropic API Server

The key innovation here is a MLX-native, Anthropic API-compatible local server. In plain terms, it emulates the interface specification of Anthropic's official API on your local machine, redirecting the Claude Code client — which normally connects to the cloud — to send requests to a locally running model instead.

MLX is Apple's machine learning framework built specifically for its own chips, deeply optimized for the unified memory architecture of Apple Silicon (M-series). Choosing MLX over a generic inference solution means the project can more fully exploit the performance headroom of Apple chips, making large model inference on a Mac faster and more memory-efficient. This is the technical foundation that makes it possible to run models with tens of billions of parameters on consumer hardware.

For developers, this "API-compatible" design has a clear advantage: there's no need to change your existing Claude Code workflow. You're simply swapping the backend from cloud to local, with minimal migration cost.

MLX was open-sourced by Apple's machine learning research team in late 2023. Its standout design feature is full exploitation of the unified memory architecture — on Apple Silicon, the CPU and GPU share the same physical memory pool, eliminating the constant data copying between system RAM and GPU VRAM that traditional PC setups require. This allows MLX to treat the Mac's entire memory (e.g., 128GB on an M4 Max) as "VRAM" for large language model inference — an advantage that Nvidia GPU solutions simply cannot replicate on consumer devices. Compared to similar local inference frameworks like llama.cpp or Ollama, MLX uses a Python-first API and is optimized at a low level for Metal (Apple's GPU compute interface), typically achieving higher tokens/second throughput on M-series chips. This explains why claude-code-local chose MLX as its core engine rather than a more generic inference backend.

Supported Local Models and Performance

The project claims support for several popular open-source large language models, with specific inference speed benchmarks:

• Qwen 3.5 122B: ~65 tokens/second
• Llama 3.3 70B
• Gemma 4 31B

A generation speed of 65 tok/s for a 122B (122-billion parameter) model is genuinely impressive, demonstrating that running large models locally on properly configured Apple Silicon hardware has moved beyond mere proof-of-concept into practical usability. The tiered model selection also lets users balance speed against capability based on their hardware — Gemma 4 31B suits machines with limited memory, while Qwen 3.5 122B targets power users who demand stronger coding performance.

It's worth noting that these performance figures come from the project's own documentation. Real-world results will vary depending on hardware specifications (especially memory capacity) and task type — readers should validate against their own environment.

Understanding how parameter counts translate to hardware requirements is essential for evaluating feasibility. Large language models are typically stored in 16-bit floating point (FP16) or 4-bit quantized (Q4) format. A 122B parameter model in FP16 requires roughly 244GB of memory, while 4-bit quantization compresses this to approximately 61–80GB — still requiring a Mac Studio Ultra or a top-spec MacBook Pro M4 Max with 128GB of unified memory to load fully. Llama 3.3 70B requires around 35–45GB quantized, and Gemma 4 31B approximately 16–20GB, making the latter runnable on MacBook Pro configurations with 24GB or 32GB of memory. In practice, model selection is constrained by hardware, and achieving 65 tok/s on the 122B model presupposes a high-end Apple Silicon device.

Who It's Built For: Privacy-Sensitive Professional Workflows

The project's positioning is unambiguous — Private, offline, airgap-ready. It directly targets workflows governed by NDAs, legal requirements, and medical regulations.

What these scenarios share is a common risk: data leaving the local environment can constitute a compliance violation or legal liability. Case files handled by law firms, patient data managed by healthcare providers, and proprietary code covered by confidentiality agreements — none of these can tolerate the possibility of being transmitted to a third-party cloud service. Traditional cloud-based AI coding tools are effectively off the table for these industries.

"Airgap-ready" — support for physically isolated network deployment — is a particularly noteworthy claim. It means this solution can theoretically be deployed in completely air-gapped environments with no internet connectivity at all, which is the standard deployment requirement for highly sensitive institutions such as government agencies, financial systems, and defense organizations. Bringing AI coding capability into these closed environments is something no cloud-based solution can ever achieve.

"Airgap" is a cybersecurity term referring to a computer or network that is physically isolated from the public internet and all other external networks, with no wired or wireless connections. It is the most extreme safeguard against data leakage and external attack, commonly used in nuclear plant control systems, military command networks, financial clearing nodes, and classified government facilities. Because airgapped devices cannot access any online service, traditional AI tools that depend on cloud APIs are entirely unusable in these environments. Claude-code-local's claim of airgap support means that as long as model weights are downloaded to the device beforehand, the entire inference process requires zero network requests and can run continuously on a physically disconnected machine — offering unique value for institutions with the strictest compliance requirements.

Significance and Limitations

Claude-code-local represents a warming trend: local large language models are graduating from "toy" to "productivity tool." As open-source model capabilities continue to close the gap with proprietary offerings, and as Apple Silicon inference performance keeps improving, keeping a powerful AI assistant entirely in your own hands is no longer the exclusive domain of tech enthusiasts.

That said, it's important to be realistic about the limitations. Running locally means users need sufficiently powerful hardware — the memory requirements for 122B-scale models are substantial and will put the solution out of reach for many everyday users. Additionally, whether local open-source models can fully replace cloud-hosted flagship Claude models in terms of code comprehension and generation quality remains something that needs long-term validation in real projects.

For teams who have never been able to use cloud AI coding tools due to compliance requirements, this project opens a path that previously barely existed. Its value isn't in how fast it runs — it's in making "offline" and "AI-assisted coding" compatible for the very first time, two things that once seemed fundamentally at odds.

This article is based on information from the project's GitHub page. For specific features, performance benchmarks, and deployment requirements, please refer to the project's official documentation.