Search "Claude Code alternatives" and you get a dozen lists recommending the same five tools: Aider, Cline, Continue, OpenCode, Void. They are good tools. They are also, almost without exception, answering the wrong question.
Every one of those lists ends the same way — "all of them support local models through Ollama, so your code never leaves your machine" — and then stops. It never says which model. It never says whether that model can actually finish the work you were paying Claude to do. The tool is free and takes five minutes; the thing that decides whether self-hosting works is the model, and the thing that decides which model you can run is how much memory you own.
This is that missing half: what each memory tier actually buys you, measured rather than asserted.
The agent layer is not the hard part
Get this out of the way first, because the listicles are right about it. Every serious terminal or IDE coding agent speaks the OpenAI Chat Completions API, so pointing one at your own server is a configuration change, not a migration:
export OPENAI_BASE_URL=http://<your-server>:8000/v1
export OPENAI_API_KEY=local| Agent | Shape | Points at a local endpoint via |
|---|---|---|
| Crush | terminal | one JSON block in crush.json |
| Aider | terminal, git-aware | --openai-api-base |
| Cline | VS Code | provider dropdown → OpenAI Compatible |
| Continue | VS Code / JetBrains | config.json model entry |
| OpenCode | terminal, model-agnostic | provider config |
Pick whichever fits your hands. The one thing to verify before trusting any of them is tool calling — it's what separates an agent from a chat box, and it's the part most likely to be quietly missing or malformed in a local serving stack. Send one request that forces a tool call and confirm you get a clean finish_reason: tool_calls with well-formed JSON arguments before you judge anything else.
That's the whole tooling problem. Now the real one.
Why memory is the constraint that matters
A model's weights have to be somewhere the GPU can read them at speed. That gives you a hard floor: a model whose weights exceed your memory doesn't run slowly, it doesn't run at all (the VRAM math). Quantization moves the floor down — 4-bit roughly quarters a BF16 checkpoint — but it doesn't remove it.
So "can I self-host a coding agent?" decomposes into one question with three honest answers, by tier.
Tier 1 — 24 to 32 GB: a single consumer GPU
This is an RTX 4090, a 5090, or a 24 GB Mac, and it's the tier every alternatives listicle silently assumes. It is genuinely useful.
What fits: dense models to roughly 30B at 4-bit, and small MoE models — which punch above their weight here because they activate only a fraction of their parameters per token. Qwen3-Coder 30B-A3B on a 5090 reaches 231 tok/s precisely because of that sparsity, with 64K context on a q8_0 KV cache. Qwen 3.6 27B is the other standout: dense, 18 GB of weights, Apache 2.0, and it lands within 4 points of Claude Opus 4.6 on SWE-bench Verified.
What it's good at: single-file edits, well-scoped functions, test writing, refactors you can describe precisely, autocomplete. Fast enough that the loop feels interactive.
Where it runs out: whole-repository reasoning. Context is the binding constraint — the KV cache competes with the weights for the same memory, so long sessions and large prompts force a choice (why context costs what it does). You'll find yourself chunking, summarizing, and re-prompting: the work the model was supposed to do for you.
Tier 2 — 128 GB: one unified-memory box
A GB10 workstation (NVIDIA's DGX Spark and its OEM variants) or a large unified-memory Mac. The trade is explicit and worth understanding before you buy: you give up bandwidth to gain capacity. We compared the two philosophies directly — a 5090 has ~1.8 TB/s against the GB10's ~273 GB/s, so for models that fit both, the 5090 wins by roughly 5–6×.
What fits: 70B dense at 4-bit (~35–45 tok/s), and 120B-class MoE at 4-bit (~40–55 tok/s) — models the 32 GB tier cannot load at any speed.
What changes: this is the tier where whole-repository context stops being a fight. You can hold a real model and a long KV cache simultaneously, which is the difference between an agent that reasons over your codebase and one that keeps asking you for the next file.
What it costs you: raw speed. If your workload is small models and fast iteration, this tier is a downgrade.
Tier 3 — 256 GB: two nodes
Two GB10s connected directly by a single 200 Gb/s cable, tensor-parallel. This is where "local" stops being a compromise, and we measured it end to end: DeepSeek-V4-Flash, 304B parameters at 1M context.
The measured numbers, on our own hardware:
| Decode, code generation | 73.3 tok/s (88.3 peak on structured output) |
| Prefill at 100K tokens | 2,644 tok/s — a large codebase read in ~30 seconds |
| Context | 1,048,576 tokens |
| GPU power, sustained | 83.1 W combined, both nodes |
| Vendor benchmark, Terminal Bench 2.1 | 82.7 versus Claude Opus 4.8's 85.0 |
A million tokens of context is a mid-sized repository in a single prompt. No chunking, no retrieval pipeline, no vector database — the entire RAG problem simply doesn't arise at this tier.
What it costs you: two machines minimum (155 GiB of weights doesn't fit in 128 GB), a distributed serving setup, and prose generation at ~33 tok/s. It's a depth machine, not a breadth machine.
"Good enough" is a thing you measure, not a thing you read
Every tier above is quoting benchmarks, including ours. Benchmarks are directional. The question that actually decides whether you can fire the API is whether the code runs.
So we ran it. Ten Python tasks at Tier 3, generated code extracted and executed against hidden assertions including edge cases the prompt never mentioned: 10 out of 10 on the first attempt, including a task that required finding and fixing two deliberately planted bugs in a binary search.
Then the same model, same session, on CUDA: of three kernels it volunteered, one was correct. The bitonic sort it explicitly recommended declared its working array as thread-private memory, so the inter-thread exchange the algorithm depends on silently never happened, and the output was corrupted rather than merely unsorted. It compiled without warnings. It would have passed code review. Its own built-in self-check printed Sorted correctly: No — and it recommended the approach anyway.
That is the shape of the limitation at every tier, and it generalizes past CUDA: sequential logic is reliable, concurrent memory semantics are not. The practical consequence is the same regardless of which tier you buy — execute what the model writes. The advantage of owning the hardware is that verification is free, private, and unmetered, so you can afford to verify everything.
The economics only tip one way
Coding agents are token furnaces. An autonomous run burns millions of tokens in an afternoon, much of it re-reading context it already read. Metered pricing scales linearly with exactly that behaviour.
Owned hardware doesn't. Past a certain sustained load the marginal cost of a token approaches the cost of electricity, and we now know that floor: 1.08 tokens per joule, or roughly 0.26 kWh per million generated tokens at Tier 3. Even doubling it to account for whole-system draw, a million tokens costs cents.
The crossover depends on your hardware cost and your volume, so run your own numbers. But note the shape: metered pricing punishes precisely the workload local hardware is best at, and the two other reasons people self-host don't show up on an invoice at all. Your source code never leaves the building — no data-processing agreement to negotiate, because there is no third party. And a model you validated in March behaves identically in November: no deprecation, no silent update, no rate limit.
Which tier are you?
| If your work is… | Buy | Realistic expectation |
|---|---|---|
| Autocomplete, single-file edits, fast iteration | 24–32 GB consumer GPU | Genuinely good, and cheap |
| Repo-aware agents, occasional long context | 128 GB unified memory | The tier where agents stop asking for files |
| Sustained agent fleets, whole-repo reasoning, regulated data | 2× 128 GB nodes | Frontier-adjacent, at wall-socket cost |
| Occasional use, latest frontier quality, no ops appetite | Keep paying the API | Honestly still the right answer for many |
That last row matters. If you use a coding agent an hour a week, none of this pays for itself — buy the subscription and get on with your life. Self-hosting wins on volume, privacy, and reproducibility, not on convenience.
Bottom line
- The agent is free and takes five minutes. Every serious tool speaks the OpenAI API. Verify tool calling and move on.
- Memory decides capability. 32 GB gets you a good assistant; 128 GB gets you repo-aware work; 256 GB gets you frontier-adjacent.
- Small MoE models over-perform at the low tier — sparsity is why a 30B beats its weight class on a single card.
- Execute what it writes, at every tier. Sequential logic is reliable; concurrent code is not.
- The economics tip on volume, and the privacy and reproducibility arguments never show up on an invoice.
The honest summary is that "can I self-host Claude Code?" was always the wrong question — the agent was never the hard part. The right question is what you can afford to put behind it, and for the first time the answer at the top tier is something genuinely close to what you're renting.