How to Run Claude Code Locally and Save Thousands of Dollars

You opened your terminal, sent a prompt to Claude Code, and nothing happened. The status page says it is down. Or maybe another refactor just burned through a large share of your usage limit.

Claude Code is a powerful coding agent, but it depends on Anthropic's servers for uptime, privacy boundaries, and pricing. That raises a practical question: can you run the same agent locally without cloud access, logins, or subscriptions?

On a single DGX Spark, we pointed Claude Code at a 284-billion-parameter DeepSeek V4 model running entirely locally. To test it, we gave the agent a bug to fix and compared the result against three other coding agents across two other inference engines.

What is Claude Code, and why run it locally?

Claude Code is Anthropic's terminal-based coding agent. It reads your repo, edits files, runs commands, and iterates through a full agent loop. By default, it connects to Anthropic's cloud.

There are three main reasons to run it against a local model:

• Uptime: A local model is served by your own hardware, rather than a third-party service.
• Privacy: Your code and data stay on the machine. For many teams, that is the difference between "allowed" and "not allowed."
• Cost: There is no per-seat subscription or usage meter. You pay for hardware once.

The tradeoff is that you are using a model you can run locally instead of a frontier cloud model. The point of this article is to measure how much that tradeoff matters. On a real bug-fix task, the answer was less than expected.

How to Change What Model Claude Code Uses

Claude Code uses the Anthropic Messages API (/v1/messages), but it does not care who answers the API, as long as the server speaks the same protocol.

Two local servers can expose an Anthropic-compatible endpoint: DS4 (the engine used here for the frontier model) and Ollama. Point ANTHROPIC_BASE_URL at either your DS4 or Ollama localhost, and Claude Code will use your local model.

export ANTHROPIC_BASE_URL=http://localhost:8080   # your local server
export ANTHROPIC_AUTH_TOKEN=dummy                 # local servers ignore it

A 284B Frontier Model on a Single NVIDIA DGX Spark

DeepSeek V4 Flash is a 284-billion-parameter model. In full precision, that is about 568 GB of weights, which is normally data-center territory. So how does it run on a single NVIDIA DGX Spark?

Selective Q2 GGUF quantization (2-bit for most weights, 8-bit for the critical ones) compresses the model to 81 GiB, which fits in the 128 GB of unified memory on an NVIDIA DGX Spark. We served it with DS4, a native CUDA inference engine built for this type of workload.

The measured results on NVIDIA DGX Spark:

• 81 GiB of weights, loaded in 10.5 seconds.
• ~15 tokens/sec generation, single stream.
• A 128K-token context window uses about a 3 GB context buffer; the weights are the main memory requirement.
• After load: ~1 GB of headroom. It fits, but it nearly fills the DGX Spark. This is why we ran one model at a time.

Testing Local Claude Code on a Bug-fix Loop

To test the setup, we built a small Python todo app with a planted bug: the --due flag is accepted on the command line but never saved. A 13-test suite covers it. With the bug, 2 tests fail.

We gave Claude Code, driven by DeepSeek V4 locally, one instruction: "The --due flag is being ignored — find the bug, fix it, and run the tests to prove it's fixed."

It read the project, found the bug, applied the fix:

if due:
    todo["due"] = due

Then it ran the suite: 13/13 passing. It also reasoned about not breaking a related test, completing the task in under three minutes, entirely local.

A 284B frontier model fixing a real bug on a desktop system is powerful, but it was not the most useful finding.

Claude Code vs OpenCode vs Qwen Code

We ran the same bug-fix task through three coding agents — Claude Code, OpenCode, and Qwen Code — against four local models. Every model was warm-loaded and run one at a time. We dropped minion because it never decided the task was finished and ran to timeout every time. That may be acceptable for interactive use, but it is not useful for unattended runs.

Same task, same 13 tests, every cell.

Four findings stand out:

• 11 of 12 runs fixed the bug correctly (13/13). Across a 284B frontier model and three 35–80B coders, the local model was not the bottleneck.
• The one failure was plumbing, not coding quality. Ornith-35B's chat template requires the system message first, which Claude Code's Anthropic endpoint, translated by Ollama, violates and returns HTTP 400. The same model passes through the OpenAI path with OpenCode and Qwen Code. New models can introduce endpoint and template friction, which is worth testing before production use.
• The model largely determines wall time. DeepSeek-V4 284B took ~170–230 seconds in every row because it runs at ~15 tok/s. The smaller and mid-sized coders finished in 20–60 seconds. For everyday agentic coding, a fast smaller coder can outperform a frontier 284B model. Use the 284B model when deeper reasoning matters more than speed.
• The harness still matters. On qwen3-coder-80B, OpenCode finished in 20 seconds, while Claude Code took 60 seconds.

Match the Model to Your Agent Topology: Depth vs. Breadth

Once you run agents locally, the main question is not only which model is best. It is how you plan to use it.

• Depth — If your workload requires solving one difficult problem, the strongest frontier model, such as DeepSeek V4 284B, can deliver the best result if you can accept slower generation speed. Batching is irrelevant when there is only one request.
• Middle — A daily driver should be fast for single-stream work and batchable when workloads grow. qwen3-coder-80B is a capable MoE option for this role.
• Breadth (fan-out) — Workflows that launch many sub-agents at once, such as eight parallel reviewers, shift the bottleneck from per-request latency to aggregate throughput. In that case, only an engine that batches efficiently can keep up.

On our NVIDIA DGX Spark, Gemma-26B on vLLM reached ~300 tok/s across 10 concurrent agents, while Ollama stayed flat at ~65 tok/s regardless of load. Fan-out also favors smaller models because parallel agents create multiple KV-cache contexts competing for the same 128 GB memory pool.

Choose by topology, not just inference speed benchmarks. A single deep agent and a swarm of sub-agents need different setups.

Considerations for Running Frontier Models on NVIDIA DGX Spark

• The ideal architecture: NVIDIA DGX Spark's ideal setup would likely be a hybrid architecture: a frontier "lead" agent delegating to many smaller, faster workers. That would require two engines resident at once, DS4 and vLLM. On a single 128 GB Spark, that topology does not fit; it is better suited to a two-Spark setup.
• Newer small MoE coders: We tested two recent MoE coding models that fit on the Spark: Ornith-1.0-35B (self-scaffolding) and Qwen3.6-35B-A3B.
  • Both were fast, completing the task in 24–43 seconds alongside the 80B model, and both fixed the bug correctly through the OpenAI path.
  • A smaller, newer MoE coder can be a practical option. The main caveat is the Ornith × Claude Code template error noted above: a new model may need its chat template adjusted before it works through every harness.

Taming Agent Permissions and Knowing When to Stop

Two practical details matter when running local coding agents:

• Permissions: By default, these agents ask before editing files or running shell commands. That is a useful safeguard, but it can be tedious during benchmarks. For unattended benchmark runs in a throwaway repo, we skipped permissions. Only do this in a sandbox you do not care about. In real work, leave prompts enabled until you trust the loop.
  • --dangerously-skip-permissions (Claude Code)
  • --approval-mode yolo (Qwen Code)
• Knowing when to stop: This is the minion failure mode. A weaker harness may keep reading files and "improving" after the job is done, which burns time. On a slow local model, it can burn a lot of time. A good harness recognizes when the tests are green and stops. When choosing a local coding agent, this matters more than a small improvement in tokens per second.

FAQ for Running Claude Code Locally

Do I need a GPU? How much RAM?

You need enough memory to hold the model. The 284B DeepSeek V4 needs the DGX Spark's 128 GB unified memory. An 80B coder like qwen3-coder needs far less. Unified-memory architectures, such as GB10, are useful because the model is not capped by a separate VRAM pool.

Is running Claude Code on a local AI agent really free?

There is no per-token or subscription cost. You pay for the hardware once, then run and iterate as much as you need.

Which local model should I pick to run Claude Code locally?

For everyday coding speed, use a coding-tuned 80B Qwen3-Coder model with Ollama. For maximum reasoning headroom at a slower token speed, use the 284B DeepSeek V4 model with DS4.

The Takeaway

Running Claude Code locally is a practical option for teams that need more control over uptime, data privacy, and long-term inference costs. By pointing Claude Code to an Anthropic-compatible local endpoint, you can run the same agent workflow against a 284B DeepSeek V4 model on a single DGX Spark and complete a real bug-fix task.

Local model capability is no longer the only deciding factor. Once the model is strong enough to complete the task, the agent harness becomes a major part of the outcome: how quickly it works, how reliably it handles tool calls, whether it stops when the job is done, and how well it fits the model endpoint.

For teams evaluating local coding agents, the best setup is the combination of model, inference engine, agent harness, and hardware that matches the workflow. Whether that means an NVIDIA DGX Spark or an Exxact multi-GPU solution depends on the required model size, token speed, concurrency, and precision.