The best open-source LLM for coding is the wrong first question to answer. The real decision underneath it is whether you should be running an open-weight model at all, self-hosted or through an inference provider, instead of just paying for a closed API like Claude or GPT. If that decision lands on open-weight for your situation, the Qwen-Coder family (Apache 2.0), DeepSeek's V4 line (MIT), and GLM-5.2 (MIT) are the strongest current picks as of August 2026, chosen by what you actually need (data control, cost at real volume, or zero ops burden), not by which one tops a leaderboard.
Type that query into a search bar and every result already assumes the decision is made. It hands you a leaderboard, a size chart, or a numbered list of names to pick from, as if the only open question left is which weight file to download. It isn't. The question underneath "best open source LLM for coding" is whether you should be running an open-weight model in the first place instead of paying for a closed API, and that decision comes first, because it changes whether the roundup below is even the section you need.
What Open-Source Coding Models Actually Get You, and What They Cost You
Open-weight, run either fully self-hosted or through a third-party inference provider, and closed-API access to something like Claude or GPT are not two flavors of the same thing. They trade different things for different things, and neither side of that trade is free.
What you get with open weights: the model's data-handling story is yours to write. Pin an exact checkpoint and it stays pinned; nobody swaps the weights under you overnight the way a closed vendor can with a dated model name. Run it fully air-gapped if that's a real requirement, not a nice-to-have. Audit the exact thing running in production for as long as you want. And once you're past the fixed cost of infrastructure, the marginal cost of one more token approaches zero, which matters once volume gets real.
What it costs you: somebody has to run it. Self-hosting hands you the job a closed vendor used to do for you: provisioning capacity, keeping an inference server healthy, being the on-call when it falls over. Routing through a third-party inference provider removes most of that ops burden, but your requests now leave your network for that provider's infrastructure, just a different vendor than the model's own maker, not the zero-dependency setup people sometimes assume open weights buy them. And on genuinely hard, ambiguous, multi-step agentic work, today's strongest open-weight models are closing the gap on the frontier closed models but haven't erased it, as this is written.
Neither column wins outright. A team with a hard residency requirement and steady volume gets real value from open weights that a spiky side project doesn't. A team that wants to never think about infrastructure again gets real value from a closed API that a cost-sensitive, high-volume pipeline pays a real premium for. Sort that out before picking a model name, not after.
The Best Open-Source Coding Models of 2026 (August Snapshot)
This is a roundup, not a leaderboard. Each entry below is graded on what it's actually good for and its real constraint, not on a benchmark number, because a benchmark score doesn't tell you whether a model fits your infrastructure, your license requirements, or your agent's tool-calling shape.
Qwen-Coder family (Alibaba). Qwen2.5-Coder ships in six sizes from 0.5B up to 32B, and Qwen3-Coder adds a 30B-A3B mixture-of-experts model plus a 480B-A35B flagship, both built for agentic coding: long-horizon planning, tool use, iterating on a diff across turns. Most sizes ship under the Apache 2.0 license, confirmed on the model cards. Alibaba's own tooling documentation for Qwen3-Coder describes it working with Qwen Code, Cline, and Claude Code-compatible harnesses. What it's good for: the widest size range here, laptop to datacenter, one permissive license. Its real constraint: the sizes that actually fit a single consumer GPU (14B, 32B) trail the flagship, and the closed frontier, on the hardest multi-step tasks; the 480B-A35B flagship needs real infrastructure or a hosted endpoint.
DeepSeek V4 (DeepSeek). There has been no new standalone "DeepSeek-Coder" release since DeepSeek-Coder-V2-Instruct-0724; DeepSeek's more recent coding-capable work sits inside its general-purpose V4 family, Flash and Pro, both under the MIT license, with release notes describing "substantially enhanced agentic capabilities." The older DeepSeek-Coder-V2 checkpoint is still downloadable and still a reasonable local pick if you want a smaller, coding-specific model rather than the general-purpose line. What it's good for: Flash's per-token rate is dramatically low, cheap enough to matter at real volume through any path (worked in full against Claude in DeepSeek vs Claude Code, not restated here); Pro costs meaningfully more, priced closer to the mid-tier closed APIs than to Flash. Its real constraint: a general reasoning model with strong code skill, not one purpose-built for coding the way Qwen-Coder or GLM are branded, and third-party hosting outside DeepSeek's own infrastructure is thinner than Qwen's.
GLM-5.2 (Zhipu / Z.ai). A 753-billion-parameter model under the MIT license, a 1M-token context window that matches DeepSeek V4's rather than exceeding it, and an explicit flexible-reasoning-effort control built for long-horizon agentic work. What it's good for: dialing reasoning effort up or down per task under a fully permissive license, useful when a codebase mixes trivial edits with genuinely hard multi-step changes. Its real constraint is scale itself: at 753B parameters, this is realistically a hosted-endpoint model for almost every team, not a self-host candidate, so its cost math below runs through the provider path.
If you're weighing Qwen specifically against Claude rather than against the other open-weight options here, Qwen vs Claude Code runs that head-to-head in full and reaches a control-versus-convenience verdict rather than a cost one; this roundup doesn't re-argue it.
Three current open-weight coding models, sorted by what they're for, not by benchmark rank.
What Self-Hosted, Provider-Hosted, and Closed API Actually Cost
Verified as of August 4, 2026 against each vendor's own pricing page. Both API rates and GPU rental rates move often, so re-run this math against current numbers before committing a budget to it.
Here's a usage pattern to anchor the arithmetic: a small team running 2,000 coding tasks a month through an agent, averaging 12,000 input tokens (file context plus instructions) and 2,500 output tokens per task. That's 24 million input tokens and 5 million output tokens a month, realistic for a handful of engineers leaning on an agentic coding tool through most of the workday.
Path one: a closed API. Anthropic's published rates, checked directly against its pricing page: Claude Haiku 4.5 at $1 / $5 per million input/output tokens, Claude Sonnet 5 at $2 / $10 through August 31, 2026 (rising to $3 / $15 after), and Claude Opus 5 at $5 / $25. At the stated workload, that's 24 * input_rate + 5 * output_rate: $49 a month on Haiku, $98 a month on Sonnet at intro pricing (rising to $147 once the standard rate takes effect on September 1, 2026), $245 on Opus.
Path two: an open-weight model through a third-party inference provider, no infrastructure of your own. DeepInfra's published per-token rate for Qwen3-Coder-480B-A35B-Instruct-Turbo, the flagship Qwen-Coder release, is $0.30 / $1.00 per million input/output tokens; the same page lists DeepSeek V4 Flash at $0.09 / $0.18. Run the stated workload through the Qwen figure: $7.20 for input, $5.00 for output, $12.20 a month. Through DeepSeek V4 Flash's hosted rate: about $3.06 a month. Either way, this path is cheaper than every closed-API tier above, sometimes by an order of magnitude, without you provisioning a single GPU.
Path three: renting your own GPU and self-hosting. This gets you closer to full data locality than path two, since a rented cloud GPU puts you in control of the weights, the serving stack, and the logs, which satisfies a lot of contractual residency language. The hardware still belongs to a provider, though, so a rented instance is someone else's machine even if nothing you send it gets logged elsewhere; only your own hardware, inside your own network, clears a genuinely air-gapped requirement. A single A100 80GB SXM, checked against RunPod's own pricing page, runs $1.49 an hour on secure cloud, enough to serve a single-GPU-sized coding model like Qwen2.5-Coder-32B or Qwen3-Coder-30B-A3B at usable throughput for a small team. Rented continuously (730 hours a month, since a team expects the thing to answer at 9 a.m. without a warm-up), that's $1,087.70 a month, a fixed cost that doesn't move whether your team runs 200 tasks that month or 20,000.
| Path | Basis | Monthly, 2,000 tasks |
|---|---|---|
| DeepSeek V4 Flash, hosted | $0.09 / $0.18 per M tokens | ~$3.06 |
| Qwen3-Coder-480B-Turbo, hosted | $0.30 / $1.00 per M tokens | ~$12.20 |
| Claude Haiku 4.5, API | $1 / $5 per M tokens | ~$49.00 |
| Claude Sonnet 5, API | $2/$10 intro, $3/$15 after | ~$98.00 intro, ~$147.00 from Sep 1 |
| Claude Opus 5, API | $5 / $25 per M tokens | ~$245.00 |
| A100 80GB SXM, rented, self-hosted | $1.49/hr, 730 hrs fixed | ~$1,087.70 |
That ordering is the honest, slightly uncomfortable finding here: at this volume, self-hosting your own rented GPU is the most expensive path on the list, more expensive than even the priciest closed-API tier, because you're paying for a dedicated card whether it's busy or not. The crossover where a fixed-cost GPU starts beating a variable per-token rate depends on how many tokens you push through it: against Claude Sonnet 5's intro-rate per-task cost of roughly $0.049 at this token profile, the $1,087.70 fixed cost breaks even around 22,000 tasks a month, on the order of 700 tasks a day. Once the standard $3 / $15 rate takes effect on September 1, 2026, that same workload costs $147 a month on Sonnet, or $0.0735 per task, which drops the breakeven to roughly 14,800 tasks a month, on the order of 490 a day. Against Claude Haiku 4.5, the breakeven point moves past 44,000 tasks a month. Against the hosted Qwen3-Coder rate, it moves past 175,000 tasks a month, a volume almost no team outside a large, automated pipeline actually runs. Renting the GPU only during working hours instead of continuously (say 220 hours a month instead of 730) cuts the fixed cost to roughly $327.80 and lowers every one of those breakeven points proportionally, but the shape of the finding doesn't change: a rented GPU rarely beats a per-token inference provider on cost unless usage is both heavy and steady, and the premium you pay for it buys locality, not savings, since your prompts never leave a server you control. The hardware underneath is still someone else's, though, so it stops short of a true air-gap.
None of this counts the ops time self-hosting adds on top of the GPU bill itself, tuning throughput, watching for a card falling over mid-task, keeping an inference server patched (a choice vLLM vs Ollama covers directly, laptop prototype versus production serving). If you've already decided self-hosting is worth that trade for your situation, running an open-source coding model locally covers the actual setup, and best local LLM for coding covers the hardware and quantization sizing this article intentionally doesn't re-derive.
How Autonoma Fits Regardless of Which Path You Pick
Every path in this article ends the same way: a model, wherever it runs, produces a diff. Self-hosted Qwen-Coder on your own GPU, GLM-5.2 through a provider, Claude through Anthropic's API, the diff that comes out doesn't announce whether it's correct. It compiles or it doesn't, it reads plausibly either way, and none of the decisions this article walks through (residency, cost at volume, ops burden) touch the separate question of whether the application that diff produces actually behaves correctly once it's running.
That's the layer Autonoma operates at, and it's built to be agnostic to everything above: it derives behavioral end-to-end tests directly from your codebase and runs them against the running application on every pull request, regardless of which model wrote the diff or where that model's weights happen to live. Switching from a closed API to a self-hosted model, or from one open-weight family to another next quarter, doesn't change what Autonoma checks or how it checks it, because the verification question was never about the model in the first place.
Which Path Fits Your Situation
Data-residency-constrained or genuinely air-gapped. This is the one situation where the cost math above doesn't get the final word. If your compliance requirement is that prompts and code never leave a network boundary you control, path two is disqualified along with path one, since a third-party inference provider is still a third party. That leaves true self-hosting, on your own hardware or a rented GPU inside your own controlled network, as not a preference but the only option left on the table, regardless of what it costs relative to the alternatives.
Cost at real volume, no hard residency requirement. Route to a third-party inference provider hosting an open-weight model first. The worked math above shows that path beating every closed-API tier at a modest team's volume, usually by a wide margin, without asking anyone to provision a GPU. Escalate to renting and self-hosting your own dedicated card only once your volume clears the breakeven point for your specific rates, which for most teams is a genuinely high bar, not a default.
Wants zero ops burden, full stop. If avoiding any new operational surface area matters more than the per-token savings, a closed API is still the honest answer for a lot of teams, and there's no shame in it. If cost matters too but ops burden still has to stay at zero, the inference-provider path gets you both: no infrastructure to run, and a lower bill than the closed API, at the cost of giving up whatever edge the frontier closed model currently holds on the hardest, most ambiguous multi-step changes.
Route by constraint first; the model name comes after, not before. Three constraints, three different honest answers, and none of them is "whichever model wins the benchmark."
So Which Open-Source LLM Should You Actually Use?
Nothing in this article declares a single best open-source LLM for coding, on purpose. The honest answer is conditional on a constraint you already know about your own team: whether data residency takes the decision out of your hands entirely, whether your volume is high and steady enough that a fixed infrastructure cost actually pays for itself, or whether zero ops burden is the thing you're optimizing for above all else. Pick the constraint first. The model name, Qwen-Coder, DeepSeek V4, GLM-5.2, or staying on a closed API, follows from that, not the other way around. For the same framework applied more generally, beyond just coding-specific model names, open source vs closed source coding models walks through the underlying decision on its own. And if you'd rather start from the model side, open to closed options too rather than ruling them out up front, best LLM for coding covers that broader ranking-resistant comparison.
Whichever path you land on, the diff that comes out the other end still needs the same check: does the running application actually do what it's supposed to do. Autonoma runs that check as a codebase-derived test suite against a live preview environment on every pull request, which is the one part of this decision that doesn't change no matter which model, or which vendor, wrote the code underneath.
Frequently Asked Questions
There isn't a single answer, and this article deliberately doesn't force one. As of August 2026, Qwen2.5-Coder and Qwen3-Coder (Apache 2.0) offer the widest range of sizes under one permissive license, DeepSeek's V4 line (MIT) is the cheapest per token by a wide margin on its Flash tier, and GLM-5.2 (MIT) offers explicit flexible-reasoning-effort control under the same permissive terms, with a 1M-token context that matches DeepSeek V4 rather than exceeding it. Which one fits depends on your data-residency needs, your volume, and how much ops burden you're willing to take on, not on a benchmark ranking.
It depends on a constraint you already know: if data residency requires it, self-hosting is the only option regardless of cost. If cost at real volume is the driver and residency isn't a hard requirement, a third-party inference provider hosting an open-weight model usually beats a closed API on price without you provisioning any infrastructure, and beats fully self-hosting your own GPU unless your volume is genuinely high and steady. If zero ops burden matters most, staying on a closed API is still a defensible, common answer.
On everyday coding tasks, the gap has mostly closed: the models covered in this roundup handle typical bug fixes, refactors, and feature work close to parity with Claude or GPT. On genuinely hard, ambiguous, multi-step agentic work, today's strongest open-weight models are still trailing the frontier closed models, as of August 2026, though the gap keeps narrowing release over release. That's precisely why this article routes on constraints like data residency, cost at volume, and ops burden rather than on a benchmark ranking: for most real workloads, the constraint decides the answer before model quality would have anyway, and treating 'which model is smarter' as the deciding question skips past the decision that actually matters for your team.
Not automatically, and the math in this article's worked example says the opposite at modest volume: renting a single GPU to self-host was the most expensive of the paths compared, more expensive than any Claude tier, because the fixed rental cost doesn't care how many tasks you actually ran that month. Routing the same open-weight model through a third-party inference provider instead of renting your own hardware was consistently the cheapest path. Self-hosting your own GPU only pays off once volume is high and steady enough to amortize the fixed cost below the per-token alternative.
Most Qwen2.5-Coder and Qwen3-Coder sizes ship under Apache 2.0, confirmed on the model cards. The one exception is Qwen2.5-Coder-3B-Instruct, which ships under a separate qwen-research license rather than Apache 2.0, so that specific size isn't cleared for the same unrestricted commercial use as the rest of the family. DeepSeek's V4 family, which absorbed the coding-specific line, ships under the MIT license. Outside that single 3B exception, both families are fully permissive open-source licenses that allow commercial use without a separate agreement.
No, and that separability is the useful part of the decision. Every path in this article ends with a diff whose correctness isn't self-evident: self-hosted Qwen-Coder, GLM-5.2 through an inference provider, and Claude through Anthropic's API all produce code that compiles and reads plausibly either way. The residency, cost-at-volume, and ops-burden tradeoffs that decide the model question don't touch the separate question of whether the running application behaves correctly. Autonoma derives behavioral end-to-end tests from your codebase and runs them against the live application on every pull request, so moving from a closed API to a self-hosted model, or between open-weight families next quarter, changes neither what gets checked nor how.
For some setups, yes. Qwen's own documentation describes Qwen3-Coder working with Qwen Code, Cline, and Claude Code-compatible harnesses, and DeepSeek's API exposes an Anthropic-compatible endpoint alongside its native one, which lets some agent tooling point at it with a base-URL and key change. That compatibility is provided by the model vendor or a third-party shim rather than official support from the agent's own maker, so behavior isn't guaranteed to match exactly, and it's worth testing against your specific workflow before depending on it.
One that treats a self-hosted Qwen-Coder or DeepSeek deployment exactly like a closed API, because the verification question doesn't change with where the weights live. Choosing between Qwen2.5-Coder, DeepSeek V4, GLM-5.2, or a closed model settles data residency, cost, and ops burden, not whether the diff it produces actually behaves correctly in your running application. Autonoma is an AI-native QA layer that derives behavioral end-to-end tests directly from your codebase and runs them against your live application on every pull request, catching regressions whether the code came from a self-hosted open-weight model or a proprietary API.
