You can run Claude Code against free local models by setting two environment variables and launching with a model flag. Since Ollama v0.14.0 (announced January 16, 2026), Ollama speaks Anthropic's Messages API natively, so Claude Code connects to your own machine believing it is talking to Anthropic. No proxy, no translation layer, no API bill.
That is the setup. The more useful thing I can give you is the boundary. I spent two weeks in March running my daily work through this configuration on my actual machine, a MacBook Pro with an M3 Pro and 18GB of unified memory, deliberately modest hardware, and the interesting result was not "local is good" or "local is bad." It was finding the line where local stops being good, because that line sits in a different place than most tutorials suggest. My position after those two weeks: local models are a genuine complement to Claude Code and a poor replacement for it, and knowing which task belongs on which side is worth more than the twenty dollars a month.
The Setup: Two Variables and a Flag
Install Ollama (a standard installer on macOS, a one-liner on Linux), pull a model, and point Claude Code at localhost:
# pull a starter model
ollama pull qwen2.5-coder:3b
# redirect Claude Code to Ollama
export ANTHROPIC_BASE_URL=http://localhost:11434
export ANTHROPIC_AUTH_TOKEN=ollama
# launch with your local model
claude --model qwen2.5-coder:3b
The variable names matter: it is ANTHROPIC_AUTH_TOKEN for the Ollama flow, and the value is arbitrary since Ollama never checks it. Setting it to ollama means my shell history makes it obvious when a session was local. Ollama's own recommendations for coding agents are gpt-oss:20b and qwen3-coder locally, and it insists on one hard requirement I can confirm from experience: run a model with at least 32K tokens of context.
If you want tier mapping instead of a launch flag, Claude Code also respects ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL, and ANTHROPIC_DEFAULT_HAIKU_MODEL, so you can map each Claude tier to a different local model and let the normal model switcher do the routing.
I keep the whole thing behind shell aliases, because mode-switching friction is what kills hybrid workflows:
alias claude-local='export ANTHROPIC_BASE_URL=http://localhost:11434 ANTHROPIC_AUTH_TOKEN=ollama && claude --model qwen2.5-coder:7b'
alias claude-pro='unset ANTHROPIC_BASE_URL ANTHROPIC_AUTH_TOKEN && claude'
What "Free" Costs: Hardware Honesty
Most tutorials on this topic show you a workstation GPU and forget to mention it. So here is what my hardware actually is: a MacBook Pro, Apple M3 Pro, 18GB of unified memory. No NVIDIA card, no 24GB of VRAM. That constraint shaped everything, and it probably matches your machine better than the 4090 setups do.
On 18GB of unified memory, the realistic menu looks like this:
- 3B coder models (
qwen2.5-coder:3b, ~2GB): instant responses, always safe to run alongside a browser and an IDE. - 7B-14B coder models (~5-9GB): the sweet spot on this class of machine. Noticeably better multi-step behavior, still leaves room to work.
- ~20B models (
gpt-oss:20b, ~13GB): loadable, but tight. Close your Docker containers first, and expect slower generation. - 32B and up: not on this machine. They either fail to load or swap so aggressively that responses take minutes.
The 32K context floor is not a suggestion. Claude Code's agentic loop keeps file contents, tool results, and instructions in play simultaneously, and I watched a small model with a short context refactor the first half of a service class beautifully and then forget the second half existed. Check what your model actually exposes with ollama show <model> and raise num_ctx in a Modelfile if needed; a model that supports 32K but runs at a smaller default gives you the failure mode anyway. One more Mac-specific trap: when memory pressure gets high, inference silently slows rather than erroring, so if responses suddenly crawl, check Activity Monitor before blaming the model.
Where the Boundary Actually Sits
Two weeks of real work, one Laravel codebase as the testbed, rotating between a 3B coder model, a 7B coder model, and the largest model my RAM tolerated. The pattern that emerged was consistent enough that I now treat it as a rule.
Local models held up on single-file, well-specified tasks. Boilerplate CRUD endpoints, unit-test skeletons, TypeScript interfaces from JSON samples, commit messages, config migrations, docblocks. The small models were not writing worse code than the big ones on these tasks in any way that mattered, and they responded faster than any cloud API can, because there is no network in the loop.
They fell apart on multi-file awareness. The recurring failure: I ask for a refactor touching four files, the model handles the first two, loses track of its own changes by the third, and by the fourth is referencing functions it believes it wrote but never did. Bigger local models pushed this cliff further out but never removed it on hardware I own.
Tool-calling reliability is the underrated gap. Claude Code's power is tool use: reading, editing, running commands, searching. Anthropic's models are heavily trained for that loop. Local models support the tool-call format, but supporting the format and using tools judiciously are different things; small models periodically edited files that did not exist or called tools with malformed arguments, and every such mistake costs a correction round.
Security work stayed on real Claude, no exceptions. I do security consulting through xCyberSecurity, and a hallucinated "this code is secure" from a 3B model is not a cost saving, it is a liability.
The net split I landed on: roughly the routine half of my daily tasks ran fine locally, and the architectural, cross-file, and judgment-heavy half needed the real model. That is why the framing "replace your subscription" is wrong and the framing that survives contact with real work is intelligent routing: cheap local compute for the tasks that do not need brilliance, paid frontier compute for the ones that do. The same routing logic applies when the cheap tier is a free cloud model instead of your own RAM, which I covered in running Claude Code on free OpenRouter models, and in the NVIDIA/OpenRouter/Ollama proxy comparison.
Which Models to Pull in 2026
The local model landscape moves fast, so treat any list as a starting point and re-check at ollama.com/search:
qwen3-coder- Ollama's own current recommendation for local coding agents; the successor line to the Qwen 2.5 coder models I tested.gpt-oss:20b- the other model Ollama names for this workflow; the strongest option that fits (tightly) in 18GB.qwen2.5-coder:3b/:7b- still my recommendation for the first hour, because a two-minute download that proves the pipeline beats a forty-minute download that might not fit.- Gemma models - a different capability profile worth testing on your own tasks; I wrote up my results in Gemma on Ollama with Claude Code.
Ollama also offers cloud-hosted models (glm-4.7:cloud and similar) through the same interface. They solve the hardware ceiling, but they are metered, which puts you back in subscription territory; know that trade before you lean on them.
What Actually Improved, and What Did Not
The honest ledger from my trial. Anthropic-bound usage dropped, since scaffolding and boilerplate stopped burning metered tokens. Iteration speed on quick tasks rose, no round-trip, no rate limits, no peak-hour queues; for offline work (flights, cafés with hostile Wi-Fi) the local setup is simply the only option that works at all, which I explored further in local AI coding without rate limits.
The unexpected benefit was behavioral: the setup forced me to ask "what tier of intelligence does this task need?" before starting it, and that question made me better at decomposing work regardless of which model ran it.
What did not improve: anything involving cross-file reasoning, error recovery, or matching my codebase's existing conventions. Frontier Claude reads a project and writes code that belongs to it; local models wrote generically correct code that felt imported from somewhere else. And local means the maintenance is yours: tracking model releases, re-testing your workflow after updates, and living without the reliability work Anthropic does on its own serving stack.
I went back to paid Claude Code as my daily driver after the trial, with the local lane kept configured for the tasks that earned it. That outcome is the recommendation.
Try It Tonight, With One Real Task
Install Ollama, pull qwen2.5-coder:3b, export the two variables, and hand it one genuine task from your current project, not hello-world, but a utility function or a test file you actually need. Twenty minutes and you will know more about where your boundary sits than any post can tell you, because the boundary depends on your hardware, your codebase, and your tolerance for correction rounds.
If you are learning agentic development and want a structured path through this stack, local models included, rather than assembling it from scattered blog posts, that is exactly what I built AI School for: hands-on courses that start from a working setup and go to production workflows.
