Best Open-Weight Coding Models to Self-Host in 2026

The best open-weight coding models you can self-host in 2026 now land roughly 60–72% on SWE-bench Verified — close enough to be genuinely useful, far enough from the 80–95% frontier cloud coders that you should choose your hardware and model with eyes open. The decision that matters is not “which open model is best” but “which open model fits the box I can actually buy.”

That box question got harder this year. The DRAM and GDDR7 shortage pushed workstation GPU prices up and erased the big-memory Mac configurations: the Mac Studio M3 Ultra now maxes out at 96GB, and the “large-memory Mac for local AI” is the M5 Max 128GB laptop rather than a 256GB or 512GB Studio. Meanwhile the models themselves ballooned — GLM-5.2 ships 744 billion parameters under an MIT license, and no single desk-side machine comes close to running it.

This guide does the arithmetic so you do not have to: how much VRAM each model needs at 4-bit, why memory bandwidth — not capacity — sets your token speed, and a single matrix that pairs every 2026 open coder with the hardware tier that runs it. We will be precise about what fits a single 96GB card, honest about what only runs in the cloud, and clear about the policy reason almost every leading open coder now comes from a Chinese lab. Every number traces to a primary source; verify the volatile ones before you spend.

Start with the honest framing, because most roundups bury it. The best coding model you can download and run yourself is no longer a toy — but it is not the best coding model, full stop. On SWE-bench Verified, the standard agentic-coding benchmark, the strongest self-hostable open-weight models land in the low 70s, while the closed frontier sits in the high 80s to mid 90s. The chart below puts the two groups side by side.

Two things are true at once. First, the trend line is steep: Devstral Small 2, a 24B model that runs on a single consumer GPU, scores 68.0% SWE-bench Verified (vendor-reported) — higher than much larger models managed eighteen months ago. Second, the absolute frontier has not stood still. Closed coders verify in the high 80s and above, so the gap between “best thing on my desk” and “best thing behind an API” is roughly 17 to 27 percentage points depending on which models you line up. For a developer, that gap is the difference between a model that closes most well-scoped tickets and one that closes the gnarly ones too.

The interpretation we draw: open-weight self-hosting in 2026 is a cost, privacy, and control decision far more than a raw-capability one. If your workload is bounded — internal tooling, code review, test generation, refactors on a known codebase — a single-card open model is now a credible primary. If you are pushing the hardest autonomous agentic coding, the honest move is to keep the frontier API in the loop and route only the cheap, high-volume, or sensitive-data work to a local model. For the largest open release of the quarter, see our DeepSeek V4 migration guide; if you are still deciding whether to self-host at all, our self-hosting deployment decision guide walks the full build-versus-rent tree.

The single most common mistake in 2026 model comparisons is treating SWE-bench Verified and SWE-bench Pro as the same scale. They are not. SWE-bench Verified is the widely-cited human-validated subset; SWE-bench Pro, from Scale AI, uses a harder, scaled problem set, so a 62% on Pro is not “worse” than a 71% on Verified — they are different exams. A handful of models report only one or the other, which makes naive cross-comparison actively misleading. The table below keeps them in separate columns on purpose.

* vendor-reported · † OpenHands scaffold · ‡ ~71.3% via OpenHands, technical report

The rule that governs self-hosting is blunt: every parameter has to live in memory, all the time. At 4-bit, model weights cost roughly half a byte per parameter plus overhead — so a 30B model needs about 15GB, an 80B model about 40–46GB, and a 123B dense model about 62GB. On top of the weights you need room for the KV cache, which grows with context length. For a 70B-class dense model, a 128K-token context at FP16 can demand around 40GB of KV cache on its own. That second number is the one most buyers forget.

This is also where the popular “32B is the ceiling for consumer self-hosting” claim needs splitting in two. For a dense model carrying a full 128K FP16 context, the comfortable single-96GB-card ceiling really does land near a 32B-class coder, because the dense KV cache eats tens of gigabytes on top of the weights. A 123B dense model like Devstral 2 loads its weights in ~62GB and leaves ~34GB — enough for a constrained context with a quantized KV cache, but not a relaxed full-length session. That headroom math is exactly why Mistral recommends a minimum of four H100-class GPUs for production serving, even though the model technically fits one 96GB card for single-user use.

The exception that breaks the 32B rule is architecture. Qwen3-Coder-Next is an 80B Mixture-of-Experts model with only 3B active parameters and a linear-attention design, so its KV cache is dramatically smaller than a dense transformer of the same context length. At Q4_K_M it needs only ~46GB for weights and leaves ~50GB of headroom — enough for a very long context on a single 96GB card. Never apply dense-model KV-cache math to an efficient-attention MoE, and never confuse active parameters with VRAM: a 744B/40B MoE still has to keep all 744B weights resident. For the full quantization, KV-cache, and context arithmetic, see our companion VRAM, quantization, and KV-cache guide, and for how that scales with context, our look at Qwen’s long-context approach.

Once a model fits, the next question is how fast it generates tokens — and that is governed almost entirely by memory bandwidth, not raw compute. Token generation (the decode phase) is memory-bound: for each new token the accelerator must read the active weights out of memory, so a useful first-principles ceiling is tokens per second ≈ memory bandwidth ÷ weights read per token. For a dense model, the weights read per token equal the full quantized model size. Real-world decode lands a bit under that ceiling once attention, the router, and framework overhead are included.

Hold the model fixed and vary only the hardware, and the effect is stark. The table below runs Devstral 2 (123B dense, ~62GB at Q4) across four memory tiers. The capacity is similar; the bandwidth is not — and the token speed tracks the bandwidth, almost linearly.

The counter-intuitive result this exposes: a 128GB DGX Spark, which has more memory than a 96GB Mac Studio or RTX PRO 6000, generates tokens the slowest of the group, because its 273 GB/s bandwidth is the lowest. At equal capacity, the 614 GB/s M5 Max is roughly 2.25× faster than the same-size DGX Spark. The DGX Spark’s value is capacity — it lets a 123B-class model load at all on a small, ~140W-typical box — not interactive speed. For dense-70B-at-Q4 decode specifically, bandwidth math puts the DGX Spark in the low single digits (one independent report measured roughly 2.7 tok/s); the higher tens-of-tokens figures you may see elsewhere are batch throughput or smaller/MoE/NVFP4 configurations, not single-user dense decode. Treat every token-per-second number here as a stack-dependent estimate.

Here is the core deliverable: every realistic 2026 hardware tier paired with the open coder that best fits it at 4-bit, with the VRAM used, the benchmark score, and a bandwidth-derived speed estimate. Prices reflect the mid-2026 shortage — note the RTX PRO 6000’s gap between its ~$8,565 launch MSRP and its current street pricing. For a broader walk through the consumer-to-workstation price brackets, pair this with our local-AI hardware price-brackets guide.

* vendor-reported · ‡ ~71.3% via OpenHands · ≈ ~64% approximate, variant unconfirmed · all SWE scores are Verified unless marked “(Pro)” · token speeds are bandwidth-derived single-user estimates.

Strip out the cloud-only giants and four models do the real work for self-hosters. Each is the best answer for a specific hardware budget — from a single consumer GPU up to a 96GB workstation card.

For a deeper hands-on walkthrough of the Mistral family and its agent tooling, see our Devstral 2 and Mistral Vibe CLI guide. Above this tier, the cloud-scale open models — DeepSeek V4-Pro (1.6T/49B, 80.6% Verified), Nemotron 3 Ultra (550B/55B), and Kimi K2.7-Code (1T/32B) — are open-weight in name but require GPU clusters in practice. Download them to fine-tune or to host on rented infrastructure; do not expect them on a single box.

Look back at the matrix and a pattern jumps out: Qwen, DeepSeek, GLM, Kimi — the open coding leaderboard is overwhelmingly Chinese. That is not an accident of talent alone; it is a structural consequence of US policy. The Bureau of Industry and Security controls closed model weights trained above a 10^26-compute threshold (ECCN 4E091) and requires export licenses for them — but published, open-weight model weights are explicitly not controlled. The most capable closed models are gateable; increasingly capable open ones are not.

There is a hardware twist that makes these models even harder to constrain. GLM-5.2 was trained entirely on Huawei Ascend NPUs with no NVIDIA dependency, and DeepSeek V4 was likewise trained on non-NVIDIA silicon. That architectural independence is a deliberate hedge: a model that needs no controlled US chips to train, and ships under an MIT or Apache license, is structurally resilient to the export regime. For teams, the practical takeaway is less geopolitical than operational — your open-weight failover stack will likely lean on Chinese models, so plan governance, licensing review, and a second source accordingly. Our open-weight second-source playbook covers how to structure that resilience without single-vendor risk.

The decision collapses to one question: what box can you buy, and how fast does it need to feel? Match your budget to the tier below, then benchmark the recommended model on your own repositories before you commit — a 70% benchmark score on someone else’s task set is not the same as a model that closes your tickets.

The pragmatic architecture for most teams is a hybrid: a single-card open model for the high-volume, privacy-sensitive, or cost-capped work, with a frontier API reserved for the hardest tickets and the agentic runs where the 17–27 point gap actually bites. Getting that routing right — which workloads stay local, which escalate, and how to measure the trade — is exactly what our AI transformation engagements scope and benchmark, and where our custom development team wires the local model into your stack.