Can a local LLM replace Claude Code? The benchmark everyone quotes is the wrong one.

Every "7 local models that replace Claude Code" list opens the same way: a table of SWE-bench scores, a triumphant "we're within 5 points of the frontier," and a shopping list of GPUs. I've read a dozen of them. They're not wrong, exactly. They're measuring the thing that's easy to measure instead of the thing that decides whether you can actually close your Claude Code tab.

Here's the uncomfortable version, after three weekends of pointing Claude Code and Codex at local models instead of the cloud:

A local LLM writing a correct function is a solved problem. A local LLM being a reliable agent — emitting a clean tool call, ten times in a row, across a multi-file edit, without drifting from the schema — is not. And the second one is the entire job.

So let's throw out the leaderboard-first framing and ask the question that actually maps to your day.

Why this is even a real question in 2026

Two things changed, and neither is "the models got smarter on Twitter."

1. MoE made frontier-ish models fit on hardware you own. A mixture-of-experts model has a huge total parameter count but only activates a sliver per token. Qwen's 35B-A3B activates ~3B parameters at inference. That means VRAM is set by the file size you load, while speed is set by the tiny active slice — so a model that used to need a server now runs on a 24GB card, and in quantized form, on a laptop.

2. The agents learned to speak local. This is the part the 2025 posts missed. In January 2026, Ollama shipped native support for the Anthropic Messages API, and LM Studio and llama.cpp followed. That's the unlock. You no longer need a proxy shim to make Claude Code talk to a model on localhost — you point one environment variable at it and it just works. The plumbing stopped being the hard part.

Which is exactly why the conversation has to move past "can it code."

The number everyone quotes, and why it lies to you

SWE-bench Verified is the stat in every headline. The reported 2026 figures look genuinely close to the frontier:

⚠️ Treat every one of those numbers as vendor-reported. Different articles quote the same model at wildly different scores because they quietly swap SWE-bench Verified for SWE-bench Pro or Terminal-Bench and never say so. Before you buy a GPU on the strength of a percentage, check the official SWE-bench leaderboard and the model card yourself.

But here's the thing: SWE-bench measures "given a bug, can you produce a correct patch." That is a writing task. It says almost nothing about the four things that actually break when the model is driving your editor:

1. Tool-call validity. Can it emit a well-formed edit_file / run_command call that the harness can parse — reliably, not usually?
2. Long-horizon consistency. Does call #11 in a session still remember the plan from call #2?
3. Context under load. Does quality hold up at 40K tokens of real repo, or collapse long before the advertised window?
4. Instruction-following. When you say "don't touch the tests," does it not touch the tests?

None of those four are on the leaderboard. All four are why your local setup feels different from the demo.

The wall nobody puts in the table: tool calling

This is the finding that reorganized how I pick a local model. Tool calling is a separate trained skill from writing fluent code. A model can produce a beautiful function and still fail completely at the one thing an agent needs — emitting a valid tool call on the first try, every try.

What the current evidence converges on:

• Reliability falls off a cliff below ~4B parameters. Sub-7B models emit malformed tool calls no matter which agent wraps them. The harness can't save a model that can't format the call.
• Native tool-use training beats bolted-on grammar constraints. Models trained with a tool template behave; models that need constrained decoding stapled on top drift.
• The model matters more than the harness. Swapping Claude Code for OpenCode for Codex doesn't fix a model that garbles JSON. It either emits clean calls or it doesn't.
• Multi-step chains are where it dies. A single tool call is fine. Five in a row, each depending on the last, is where smaller local models start hallucinating tool calls — inventing a function that doesn't exist, or re-calling one with drifted arguments — and the agent spirals into a retry loop.

The practical cut: for agentic work you want a 14B–32B model from a family with native tool training. In late 2026 that overwhelmingly means Qwen (3.6 27B / 35B are the reliable tool-callers people keep landing on), with GLM-4.x and Devstral Small 2 as the credible alternates. Everything under ~7B is a chat model cosplaying as an agent.

The setup is genuinely 60 seconds

Since the agents speak local now, this is anticlimactic — which is the point.

Claude Code → local model (via Ollama):

# 1. pull a capable coder ollama pull qwen3-coder:30b # 2. point Claude Code at localhost and hand it a throwaway token export ANTHROPIC_BASE_URL="http://localhost:11434" export ANTHROPIC_AUTH_TOKEN="local-dummy" # 3. run it claude 

Codex CLI → local model: Codex talks to any OpenAI-compatible endpoint. With Ollama, the --oss flag points it at the local server (:11434); LM Studio serves on :1234/v1. You can pin providers and models in config.toml.

Two gotchas that cost me an evening each:

• Set the context window explicitly — at least 32K, ideally 64K+. The default is often tiny, and a coding agent starves instantly. But also: quality degrades well before the advertised limit, and the KV cache eats the VRAM you wanted for weights. Budget for it.
• To go back to the cloud, unset ANTHROPIC_BASE_URL (or pull the entries from settings.json). Obvious until you forget and wonder why "Claude" got dumber.

Where it actually breaks (the honest part)

Run this setup for a week on real work and the pattern is consistent. Hands-on reports — and my own — land around the same place: a good local coder gives you roughly 70% of cloud Claude for routine, single-file tasks, and the gap widens fast as the task gets more agentic.

The failure modes, in order of how often they bit me:

• Schema drift → retry loops. The model emits a slightly malformed edit, the harness rejects it, it tries again, drifts differently. On a hard step this can eat a dozen round-trips.
• Multi-file reasoning falls apart. "Rename this across the module and update the imports" is where a cloud model is boring and reliable and a local 30B gets lost by file three.
• Latency you feel. A chain a cloud model finishes in seconds can take minutes locally — not because tokens/sec is bad, but because every retry is another full generation.
• Context cliff. It's sharp and it's early. The model gets subtly worse at ~half the stated window, and "subtly worse at following the plan" is exactly the thing you can't afford in an agent.

None of this makes local useless. It makes local a different tool, not a cheaper clone.

The framework that actually made the call for me

Stop asking "which model is best." Ask "which job is this." The clean split:

Reach for local when the work is:

• Private or offline — code that legally or politically can't leave your machine.
• High-volume and cheap-per-task — the thousand little classify/summarize/boilerplate sub-calls in an agent swarm that don't need a frontier brain.
• Narrow and single-file — a function, a test, a regex, a migration.
• A fallback to protect credits — route the easy 80% local, escalate the hard 20%.

Keep cloud Claude/Codex for:

• Multi-file, long-horizon changes where consistency over many steps is the whole value.
• Large-context work where you need the full window to actually work.
• "I need it right the first time, fast" — anything where retry loops cost more than API tokens.

The one-liner I've settled on: local is becoming the default, and the frontier model is the escalation path. That's the opposite of how most teams run it today, and it's where the money is.

So does it actually save money?

This is the real reason people try, so let's do the math honestly instead of waving at "free."

Local isn't free — it's prepaid. You're trading a metered API bill for fixed hardware + electricity + your time babysitting retries. A rough break-even:

• A used 24GB GPU that runs Qwen 3.6 27B comfortably is a few hundred dollars, one time.
• Electricity under sustained load is real but small — call it single-digit dollars a month for an individual.
• Against that: a single heavy Claude Code user can burn hundreds a month, and small teams running agent swarms post eye-watering bills (the "$4,660 in one month" screenshots are a genre now).

So the honest conclusion: for an individual doing casual coding, local rarely pays back versus just using the cloud carefully — the hardware and fiddling cost more than you'll save. Where it flips hard is high-volume, repetitive, or privacy-bound workloads, especially agent swarms where you can route the cheap 80% to a local model and only spend frontier tokens on the 20% that needs them. That routing — not "replace Claude Code" — is the actual 2026 win.

The real answer

Can a local LLM replace Claude Code? For being your agent on hard, multi-step, large-context work — not yet, and the thing holding it back isn't the SWE-bench score, it's tool-calling reliability over long sessions. For being the cheap, private, always-available workhorse for the 80% of tasks that don't need a frontier model — absolutely, today, on a single 24GB GPU, and it's getting better monthly.

The mistake is treating it as a binary. The people getting value aren't "replacing" anything. They're running two models and knowing which job goes where.

If you found this useful, follow me — I write about AI agents, local models, and the unglamorous engineering around them, and I'm testing more of these setups as the models ship.

Your turn: what's the actual line for you — the specific task where you reach for the cloud and refuse to trust a local model? I'm collecting the real break points, not the benchmark ones. 👇

Numbers in this post are vendor-reported and move monthly. Verify coding scores on the official SWE-bench leaderboard and tool-calling on the Berkeley Function-Calling Leaderboard before you spend money on hardware.