Since Ollama v0.14.0 shipped a native Anthropic Messages API endpoint in January 2026, this needs no proxy. Two environment variables and one ollama pull, and Claude Code talks to your own machine. LM Studio added the same endpoint shortly after.
That is the good news. The constraint that decides whether this works for you is not the setup and not the model quality. It is tool calling.
Setup
Pull a model, then point Claude Code at localhost:
ollama pull glm-4.7-flashunset ANTHROPIC_API_KEY
export ANTHROPIC_BASE_URL="http://localhost:11434"
export ANTHROPIC_AUTH_TOKEN="ollama"Unsetting ANTHROPIC_API_KEY matters. Leave it set and you may find requests still going to Anthropic while you believe you are running locally.
On a machine with a GPU, force maximum offload:
export OLLAMA_NUM_GPU_LAYERS=99For anything beyond a test, put these in ~/.claude/settings.json under an env key instead of exporting them, so they survive a reboot. The OpenCode Go post covers that pattern in full.
The requirement that disqualifies most models
Claude Code is an agent, not a chat window. It reads files, runs commands and edits code, and all of that happens through tool calls.
A model without tool-calling support can generate text but cannot read your files. It will look like it is working and produce plausible code about a codebase it has never seen. This is the single most common reason a local setup feels broken rather than slow.
The second requirement is context. Claude Code needs a large context window, 64K tokens as a practical minimum, because the harness sends the system prompt, the tool catalogue and your conversation on every request. A model with an 8K window cannot hold the fixed overhead, let alone your code.
So the model shortlist is short, and it is chosen on tool calling and context first, coding ability second.
Models worth starting with
| Model | Why |
|---|---|
glm-4.7-flash | Lowest hardware requirement, most consistent tool calling, fastest path to working |
qwen2.5-coder | Stronger reasoning on complex refactoring |
qwen3.6:27b | The 2026 default; 77.2% on SWE-Bench Verified |
Start with the flash model even if your hardware can handle more. Getting a working loop first tells you whether the workflow suits you, and swapping models afterwards is one ollama pull.
The hardware you actually need
This is where local setups meet reality.
A 32B model unquantized needs roughly 64GB of VRAM. Quantized to 4-bit it needs about 22GB. That puts a 24GB card, such as a 4090 or 5090, at the entry point for the 30B-to-34B class, which is the tier where local coding becomes genuinely useful rather than merely possible.
Below that tier things still run. A 13B model on 12GB works. It will also lose the thread on multi-file changes in a way the 30B class does not, and multi-file coherence is most of what a coding agent is for.
The honest framing: this is free in the sense that a car is free once you have bought it.
When local is the right call
Offline or air-gapped work. No connection, no third-party service, no data leaving the machine. For regulated environments this is the whole argument and it needs no other justification.
Privacy constraints. Client code that contractually cannot go to a third-party API.
Unmetered experimentation. No quota windows, no per-token cost. If you want an agent grinding on something for six hours, local is the only option with a fixed cost.
Learning. Watching an agent loop run against a model you control teaches more than any amount of reading.
When it is not
If your goal is cheaper tokens rather than local execution, a hosted Anthropic-compatible endpoint gives you far better models for roughly $10 to $20 a month and no hardware. We mapped those options in how to run Claude Code on a cheaper model, and for most people that is the better trade.
If you are hitting quota rather than cost limits, the fix is usually context discipline rather than a different backend. Most of the drain comes from things that happen while you are idle, which we covered in what actually burns your Claude Code quota.
And if your work is hard multi-file refactoring, a local 30B model is a real step down from a frontier model. Local inference latency and VRAM limits can also mask quality regressions that only surface once you are relying on the output, which is a subtler risk than the obvious one of slower responses.
Use local for what it is genuinely good at: privacy, offline capability, and unlimited grinding on well-scoped tasks. Not as a free replacement for a frontier model on your hardest work.
FAQ
Can Claude Code run with Ollama?
Yes, and since Ollama v0.14.0 in January 2026 it needs no proxy, because Ollama exposes a native Anthropic Messages API endpoint. Unset ANTHROPIC_API_KEY, set ANTHROPIC_BASE_URL to http://localhost:11434 and ANTHROPIC_AUTH_TOKEN to ollama, then pull a model. LM Studio offers the same endpoint.
Which local models work with Claude Code?
Only models with tool-calling support and a context window of at least 64K tokens. glm-4.7-flash is the easiest start with the lowest hardware requirement and reliable tool calling. qwen2.5-coder handles complex refactoring better, and qwen3.6:27b scores 77.2% on SWE-Bench Verified. Models lacking tool calling can produce text but cannot read your files.
How much VRAM do I need to run Claude Code locally?
Around 22GB for a 32B model quantized to 4-bit, or roughly 64GB unquantized. In practice a 24GB card such as an RTX 4090 or 5090 is the entry point for the 30B-to-34B class, which is where local coding becomes genuinely useful. Smaller models run on 12GB but lose coherence across multi-file changes.
Is running Claude Code locally free?
The inference is free once you own the hardware, with no quota windows and no per-token cost. The hardware is not: the useful tier needs a 24GB GPU. If lower cost rather than local execution is the goal, a hosted Anthropic-compatible subscription at $10 to $20 per month gives better models with no upfront spend.
Why does my local model produce code without reading my files?
Almost certainly because it lacks tool-calling support. Claude Code reads files, runs commands and edits code through tool calls, so a model that cannot call tools will generate plausible-looking code about a codebase it never opened. Check tool-calling support before blaming the model's coding ability.
