Best Open-Source LLMs for Coding in 2026: How to Choose

Open weights have quietly become a complete coding stack. Here are the strongest candidates for each job, and what they're closest to among the closed models you may use.

By Blake Kinnan, Co-Founder & VP of Strategic Intelligence

In one week this August, Alibaba released its first downloadable Max-class open checkpoint at 2.4 trillion parameters, and DeepSeek released its own 1.6-trillion-parameter model under plain MIT. Moonshot had already put a 2.8-trillion-parameter multimodal model on Hugging Face in July. NVIDIA published not only weights but the entire training recipe and dataset behind a 550-billion-parameter model.

Over the last two years, open-weight models have gone from being good at autocomplete to being genuinely strong options for every role in a modern coding stack.

There's no single best open source LLM for coding, and the teams getting the most out of open weights have stopped looking for one. What follows is a shortlist for each job, the reasoning behind it, and where each sits relative to the closed models you're likely running today.

‍

Coding is not one job

"Coding" covers work that rewards completely different things - planning a migration across six services is not tracking down a race condition, which is not generating four hundred unit tests. A model excellent at one can be ordinary at another, and this is where most comparisons go wrong.

Four shapes matter. Three you already know if you use closed models, because that's how those stacks get built: a strong model plans, a strong model does the hard part, a cheaper fast model does the volume. The fourth is the one people discover the hard way.

You won't run any of these raw. Models get consumed through an agent harness - Claude Code, Codex CLI, OpenCode, or a model-agnostic one like Nous Research's Hermes Agent. The harness isn't a fifth role; it's the layer all four run inside, controlling the prompt, tool definitions, retry policy, and context budget. Change it and the same weights behave differently, which is why "we tried it and it was bad" so often turns out to be a harness problem. More on that in a separate piece.

Role 1 - The planner

Technically: agentic orchestration and long-horizon task decomposition

Turns an ambiguous goal into a coherent project. Works out which systems are affected, sequences the work, delegates it, and changes course when execution reveals a bad assumption.

Kimi K3 and Qwen3.8-2.4T-A95B are the two open models built for this shape. K3 is 2.8 trillion parameters with 104 billion active, multimodal, with a million-token context. Qwen's is Alibaba's first open Max-class checkpoint at 2.4 trillion parameters, 95 billion active, with configurable reasoning effort you can turn up for planning and down for execution.

Planning across a large repository is where context length stops being a spec-sheet number and becomes the job - you're holding the architecture, the migration notes, and the failing tests in the same window. Watch the naming here: Qwen3.8-2.4T-A95B is the downloadable checkpoint, text-only and always reasoning. Qwen3.8-Max is the managed product built on it, with vision and a million-token default. Same license file, different artifact.

If you use Claude Opus or a frontier GPT here: same logic - a bad plan costs more than slow implementation. The constraint isn't capability, it's hardware. Both need more than one eight-GPU node, so most teams will consume them as hosted endpoints.

Role 2 - The problem solver

Technically: multi-file reasoning, tool use, and self-verification

Takes the hard ticket. Reads code nobody on the team wrote, finds the subtle failure, makes the consequential edit, runs the tests, checks its own work.

DeepSeek V4 Pro brings frontier scale - 1.6 trillion total parameters, 49 billion active, a million-token context - under plain MIT, with no revenue threshold and nothing to track. DeepSeek V4 Flash is the same proposition in a footprint that fits a single eight-GPU box: 284 billion total, 13 billion active. GLM-5.2 sits between them at 753 billion, also MIT, with effort controls that let you spend more compute on the tickets that deserve it.

Inkling Small is the US-origin option: 276 billion total, 12 billion active, multimodal, Apache-2.0, one node. Thinking Machines built it as a customization base, so it's the starting point if you're fine-tuning on your own codebase - and the one to reach for when provenance has to survive review.

If you use Claude Opus for hard tickets: V4 Pro is the scale match. If you use Sonnet, V4 Flash, GLM-5.2, and Inkling Small are the closer analogues - and unlike Sonnet you can run them in your own data center.

Role 3 - The doer

Technically: high-throughput bounded task execution

Does the volume. Well-specified changes, test generation, routine refactors, documentation. The requirement isn't peak reasoning - it's reliability across hundreds of small tasks, fast enough that nobody waits.

Qwen3.8-27B is the most interesting release in this tier in a while: 27 billion dense parameters, natively vision-language, switchable thinking, 262,144 tokens of native context, Apache-2.0, running on a single GPU. Vision at this size matters more than it sounds - screenshots and design mockups are ordinary inputs to routine front-end work, and until recently going small meant giving that up.

gpt-oss-120b is the speed play: Apache-2.0, native MXFP4, built for low-latency completion. Gemma 4 31B is the other genuine single-GPU option, and Qwen3-Coder-Next at 80 billion is worth testing as a specialist rather than assuming its name settles anything.

If you use Claude Haiku or Gemini Flash here: same role, same economics - and this is where open weights make the most obvious financial sense, because high volume is where per-token pricing compounds.

Role 4 - The terminal operator

Technically: shell execution, tool chaining, and failure recovery

Distinct enough from general coding to deserve its own shortlist. What you're measuring isn't whether a model can run a command - it's whether it notices a command failed and does something different.

GLM-5.2 lands in the most practical size class here: large enough for genuine agentic reasoning, small enough to serve from one node. Kimi K3 and Qwen3.8-2.4T-A95B are both positioned for long-horizon agentic work if you have the hardware.

If you run Claude Sonnet inside an agent harness: that's the comparison - and remember both are systems, not models. Swap the scaffold and behavior changes more than swapping the weights does.

What you can actually run

The shortlists above assume you can serve them. Run this filter early - it eliminates faster than anything else. The arithmetic: roughly one byte per parameter at FP8, plus about 20% for key-value cache and runtime, rounded to the nearest real serving node.

The trillion-parameter models need more than one eight-GPU box, so most teams will use them as hosted endpoints - openness there buys auditability and portability rather than a cheaper deployment. The 276B-753B tier fits a single node, where serious self-hosting happens. Three models fit one GPU, which is the tier that matters if data residency or air-gapping is your reason for going open.

Weights-only memory is a floor, not a budget: at long context the key-value cache can exceed the weights.

What the license lets you build

Here's the part that sounds intimidating and mostly isn't. One note on terms: open weights means the parameters are downloadable - not that the training data, the recipe, or unrestricted commercial use come with them.

Most of the field is genuinely permissive. DeepSeek's V4 models and GLM-5.2 are MIT. Gemma 4, gpt-oss, Qwen3-Coder-Next, Qwen3.8-27B, and Inkling Small are Apache-2.0. No thresholds, nothing to track. Nemotron 3 Ultra goes further, published under OpenMDW-1.1 alongside the training recipe and dataset - the one to reach for when a regulator asks what actually went into the model.

Two models carry revenue-gated licenses, and this is where people get nervous unnecessarily.

Why the limits exist. Kimi K3 and Qwen's Max-class checkpoint both ship an MIT-style grant with two conditions attached, and both engage only when you make the model or its outputs available to third parties above a substantial revenue line. These aren't restrictions on developers - they're revenue claims aimed at whoever resells inference at scale. A lab that spends nine figures training a model and gives the weights away still wants a conversation with the hyperscaler building a business on top of it.

How to stay compliant. Two questions, and most readers stop at the first.

Do third parties reach the model? If you're self-hosting for your own engineers, you're inside the internal-use exemption in both licenses and nothing further applies - which covers most enterprise deployments.

If yes, does your revenue cross the line? Aggregate, including affiliates, over any rolling twelve months. Kimi K3 sets it at $20 million; Qwen's Max-class checkpoint at $50 million, but extends the definition to standalone AI coding products - the clause to read if that's what you're building. Above the line you need a separate agreement first. That's a business-development conversation, not a crisis. A separate attribution rider applies to very large consumer products.

Read the license file rather than a summary - the thresholds above are current as of publication, and the linked model card is the authoritative source. Record which checkpoint and version you deployed, and re-check when you ship a new product surface.

General information, not legal advice.

What you're permitted to use

For most companies this doesn't apply. The weights are public, the licenses permit commercial use, and no US authority prevents a private firm from self-hosting open weights of any origin.

Federal and defense buyers are elsewhere. Section 1532 of the FY2026 NDAA (Public Law 119-60) addresses covered AI in the performance of Department of Defense contracts, defined to reach DeepSeek, its owner High-Flyer, and entities High-Flyer substantially owns or funds.⁵ Read the operative text directly - secondhand reporting has been unreliable, and whether it reaches subcontractors isn't settled by the statutory language alone. If you're a subcontractor, ask your prime and your contracting officer.

Section 1260H is a different instrument: DoD added Alibaba and Baidu to its list of Chinese military companies in June 2026.⁶ That feeds the NDAA's covered-company framework, but a listing is not itself a procurement ban.

Why you have to test this yourself

In February 2026, OpenAI audited SWE-bench Verified and stopped reporting scores on it. Of the 138 problems it reviewed, a majority had defective tests, specified one thing and tested another, or showed evidence models had already seen the answers. The obvious replacement, LiveCodeBench, only scores problems published after a model's training cutoff - excellent design, but its leaderboard is still scoped to problems through May 2025, so none of the models here appear on it. Aider's polyglot benchmark, the only widely-used test of edit-format reliability, hasn't been updated since November 2025. And agentic benchmarks mostly measure a system, not a model.⁴

A benchmark tells you what to test. It shouldn't tell you what to buy.

In summary

1. Apply the hard filters - hardware, license, procurement. Most of the field disappears here, and none of it required a benchmark.
   ‍
2. Build a task set from your own repositories - twenty to thirty real tasks your team actually did. Not prompts; tasks with a definition of done.
   ‍
3. Aim at the known failure modes. Give the planner a multi-stage task where step three depends on something learned in step two, and watch for a convincing plan that loses coherence mid-execution. Give the problem solver bugs whose correct fix you already know, and watch what happens after the first failure - the expensive outcome isn't a wrong answer, it's an agent that retries a failing command six times and reports success. Test the doer on edit format explicitly, since a 3% rate of malformed diffs is invisible in a demo and expensive four hundred times a day.
   ‍
4. Score what you actually pay for - accepted-result rate, regression rate, human correction time, latency at real concurrency, cost per accepted change. Hold scaffold, effort, and precision constant, or you're benchmarking your harness. Then shadow-test the final two on live work for a week and keep a fallback configured, because what you learn in month two is never in the evaluation.

Hoonify serves Inkling Small, GLM-5.2, Qwen3.8-27B, and Gemma 4 31B if you'd rather start testing than start provisioning. See the catalog.

Two years ago the honest answer to "can we use open weights for real coding work" was "for some of it." That's no longer the answer. The question now is which model for which job, and what your hardware and contracts allow - which is a considerably better problem than the one we had.

Common questions

What is the best open-source LLM for coding in 2026?

It depends on the job, and most teams end up running two or three. Kimi K3 and Qwen3.8-2.4T-A95B lead the shortlist for planning and long-horizon work; the DeepSeek V4 models, GLM-5.2, and Inkling Small for hard debugging; Qwen3.8-27B and gpt-oss-120b for high-volume execution.

Can I run any of these on a single GPU?

Three. Qwen3.8-27B and Gemma 4 31B fit comfortably, and gpt-oss-120b ships natively at 4-bit. Everything larger needs a multi-GPU node. Those are weights-only figures - long context adds substantially more.

Can I build a commercial product on these models?

Most of them with no conditions at all. Kimi K3 and Qwen's Max-class checkpoint require a separate agreement above $20M and $50M in revenue respectively, and only if third parties reach the model. Internal use is exempt under both.

Is a smaller model ever the right answer?

Frequently. For bounded high-volume work, a 27B model returning in two seconds produces more accepted changes per day than a trillion-parameter model you're rate-limited on.

Research and attribution

Shortlists reflect our editorial judgment based on developers' published specifications, license terms, and stated design intent. Model specifications are lab-stated and linked inline to each developer's own model card. Hardware figures are our own estimates from published parameter counts, not measurements. Artificial Analysis's public research helped shape the questions behind this guide; this article does not reproduce its subscriber data, tables, or rankings.⁴

References

[1] OpenAI, Why we no longer evaluate SWE-bench Verified, February 23, 2026. https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified

[2] LiveCodeBench leaderboard and methodology. https://livecodebench.github.io/leaderboard.html

[3] Aider polyglot benchmark leaderboard. https://aider.chat/docs/leaderboards/

[4] Artificial Analysis, Capability Indices methodology. https://artificialanalysis.ai/methodology/capability-indices

[5] FY2026 NDAA, Public Law 119-60, §1532. https://www.govinfo.gov/content/pkg/PLAW-119publ60/pdf/PLAW-119publ60.pdf

[6] U.S. Department of Defense, Section 1260H list. https://business.defense.gov/CLEAR/1260H-List/

About the author

Blake Kinnan is Co-Founder and VP of Strategic Intelligence at Hoonify, where he tracks the AI infrastructure landscape - models, silicon, licensing, and deployment economics - to inform product and go-to-market decisions across the executive team.

‍

‍