Best Open Source LLM for Coding: Price Is Not Task Cost

Search “best open source LLM for coding” and the first page is nine listicles, six of them written by companies that host the models they rank. Most name the same families, DeepSeek, Kimi, GLM, Qwen, MiniMax, gpt-oss, Gemma. Three of the six quote no benchmark at all. None of them put a benchmark score, the harness it was measured in, and a dated price in the same table, and none does the arithmetic for a real coding workload. The one honest sentence they share, “run your own evals”, is true and useless to a leader who has to pick something this quarter.

This post does the parts they skip: the current open-weight field with licenses, the score each maker reports and the harness it used, and the price on the maker’s own page, all read on October 19, 2026. Then one ticket costed across those models, the three 2026 studies that measured cost per completed task instead of cost per token, and the two things that move the bill more than the model: the harness and the retry. It ends on how YAGNI routes across these models without asking you to pick one, and where a frontier model is still the right call.

Which open source LLMs are best for coding right now?

Eight models carry the field in October 2026. The scores below are the ones each maker reports on its own model card, with the benchmark named, because the makers have stopped agreeing on a benchmark: OpenAI stopped publishing SWE-bench Verified in February 2026 after finding broken tasks in the hard subset, and Kimi, GLM, and the newest DeepSeek cards now lead with Terminal-Bench 2.1 instead. Prices are per million tokens, input and output, from the maker’s own API pricing page as of October 2026; the same weights cost up to twice as much or half as much on another host, which is its own section below.

Model	License	Size (total / active)	Context	Maker-reported coding score	Maker’s price, in / out
DeepSeek V4-Pro	MIT	1.6T / 49B	1M	SWE-bench Verified 80.6, Terminal-Bench 2.0 67.9	$1.32 / $3.96, half that off-peak
DeepSeek V4.1-Flash	MIT	552B / 8B to 16B	1M	Terminal-Bench 2.1 90.6 (no SWE-bench Verified reported)	$0.30 / $1.20
Kimi K3	Custom (commercial use allowed, revenue thresholds)	2.8T / 104B	1M	Terminal-Bench 2.1 88.3 (no SWE-bench Verified reported)	$3.00 / $15.00
Kimi K2.6	Modified MIT	1T / 32B	256K	SWE-bench Verified 80.2, Terminal-Bench 2.0 66.7	$0.95 / $4.00
GLM-5.3	Custom (MIT-style, security review above $10B revenue)	753B	1M	Terminal-Bench 2.1 88.2 (no SWE-bench Verified reported)	$1.40 / $4.40; Flash variant $0.15 / $0.50
Qwen3.6-27B	Apache-2.0	27B dense	262K	SWE-bench Verified 77.2, Terminal-Bench 2.0 59.3	$0.32 / $3.20 on DeepInfra (no first-party API price)
MiniMax M3	Community license (attribution, revenue threshold)	428B / 23B	1M	SWE-bench Verified 80.5	$0.30 / $1.20 on Together
gpt-oss-120b	Apache-2.0	117B / 5B	128K	SWE-bench Verified 62.4	$0.15 / $0.60 on Together

Two things to read off that table before any ranking. The scores are not comparable with each other: a Terminal-Bench 2.1 number from one maker’s harness and a SWE-bench Verified number from another’s are different exams graded by different proctors. And the per-token prices span twenty to one inside the open-weight field alone, from gpt-oss-120b to Kimi K3, so “open-weight is cheap” is a claim about some of these models, not the category.

For a comparison that holds the exam constant, Vals.ai runs every model through the same minimal scaffold, mini-SWE-agent, on SWE-bench Verified and reports cost per test. In the run archived on September 1, 2026, Opus 5 resolved 97.0% at $1.29 a test, DeepSeek V4-Pro 96.4% at $0.10, GLM-5.3 95.4% at $0.34, Kimi K3 93.4% at $0.76, and GLM-5.3-Flash 92.0% at $0.02. Same harness, same tasks, and the open-weight models are inside two points of the frontier at a tenth of the cost or less. That benchmark is also close to saturated, which is why the makers moved on from it, so read it as “the easy 95% is a solved problem for everyone” rather than a ranking.

Is “open source” even the right word?

Mostly not, and the difference lands on your legal team. Open weights means you can download the model and run it. Open source in the sense an engineering org usually means also needs a license that lets you use it for anything, and the OSI definition wants the training data and recipe too, which none of these ship.

The licenses in the table above fall into three groups. DeepSeek V4 (MIT), Qwen3.6 (Apache-2.0), gpt-oss (Apache-2.0), and Meta’s Muse Glimmer-30B (Apache-2.0, SWE-bench Verified 76.0) are open source by any reasonable reading. Kimi K3, GLM-5.3, and MiniMax M3 are open-weight under custom licenses: commercial use is allowed, but each carries a revenue threshold above which you need a separate agreement, a security review, or an attribution line in your product. MiniMax M2.7, M3’s predecessor, is non-commercial without written permission, and still appears in “best open source” lists as if it were not.

If you host the model yourself, the license is your problem. Through a host’s API, it is the host’s problem and yours is the data-handling agreement, which is where “US-hosted” and “zero data retention” stop being marketing words. Either way, read the license file before the model card.

What does an open-weight model cost per ticket?

Here is the same ticket we costed in how an LLM router cuts coding cost: a change to a checkout service, seven steps from reading the ticket to writing the record, 1.71 million input tokens and 78 thousand output tokens before prompt caching. Costed at each maker’s list price from the table above, with everything on one model and no retries:

Model, everything on it	Input	Output	Ticket total
Opus 5.5 (Anthropic, $4 / $20, as of October 2026)	$6.84	$1.56	$8.40
GPT-5.6 Sol (OpenAI, $4 / $20, as of October 2026)	$6.84	$1.56	$8.40
Kimi K3 ($3 / $15)	$5.13	$1.17	$6.30
Sonnet 5.5 ($2 / $10)	$3.42	$0.78	$4.20
GLM-5.3 ($1.40 / $4.40)	$2.39	$0.34	$2.74
DeepSeek V4-Pro ($1.32 / $3.96, peak)	$2.26	$0.31	$2.57
MiniMax M3 ($0.30 / $1.20, Together)	$0.51	$0.09	$0.61
V4.1-Flash ($0.30 / $1.20)	$0.51	$0.09	$0.61

Two thirds off for the two strong open-weight models, and more than ninety percent off for the small ones. That is the number the listicles would print if they printed one, and it leads to the wrong conclusion, because it assumes every model finishes the ticket in one pass.

Now add one retry. The Build step on that ticket is 600 thousand input tokens and 40 thousand output. If the cheaper model’s first draft fails review and it builds again, GLM-5.3’s ticket goes from $2.74 to $3.76, and V4.1-Flash’s from $0.61 to $0.84. Still far under Opus. But the retry also costs a reviewer’s time reading a diff that was wrong, and a second review, and that hour does not appear on any pricing page. Two retries on a hard ticket and the open-weight model has spent more of your engineers’ attention than the frontier model that finished first, even though its token bill is a third the size.

Why is token price not task cost?

Because three studies published this year measured cost per completed task on real repositories, and they disagree, which is the finding.

Databricks ran coding agents against its own multi-million-line codebase in July 2026. GLM-5.2 cost $1.28 per task and was statistically tied with Opus 4.8 on quality; Opus 4.8 cost $1.94 at 87% completion; Sonnet 5 cost $2.09 at 81%, more than Opus despite a lower token price, because it used more tokens. The same model through the Pi harness instead of Claude Code or Codex cost less than half, because Pi sent about a third of the context per turn.

Faros ran 211 tasks across twelve repositories in June 2026 and found Claude Code with GLM-5.2 at $0.92 a task scored higher on its judge than Claude Code with Opus 4.8 at $1.76 and Codex with GPT-5.5 at $2.06.

Insight took one feature to a merged pull request across models and harnesses in July 2026 and got the opposite ordering. Opus 4.8 on Claude Code merged for $9.98. GLM-5.2 cost $14.95 and took 176 minutes. Kimi K2.7 cost $21.73. The cheapest run was GPT-5.4-mini at under $4. Same feature, same review gate, and the open-weight models cost more to a merge than the frontier model, because they took more turns to get there.

Put the three together and the lesson is not “open-weight wins” or “frontier wins”. The per-token price predicted almost nothing in any of them; the harness and the task did. On a large, well-structured codebase with a strong scaffold, the open-weight model finished as often as the frontier one at a third of the cost. On a single hard feature with a strict merge gate, the retries ate the saving. The number to manage is dollars per merged pull request, measured on your repositories, and no pricing page can give you that.

Does the harness matter more than the model?

About as much, on the published evidence, and it is the variable the listicles leave out entirely.

A September 2026 paper, Coding Agents Have Converged, measured how far the same model’s SWE-bench Verified score moves when only the scaffold changes: up to 29.8 points within one model, against an 8.8-point spread across the top thirty entries on the leaderboard, with no adjacent pair in that top thirty statistically separable. The makers’ own cards say the same thing more quietly. Qwen reports Qwen3-Coder-Next at 70.6 on SWE-Agent, 71.1 on mini-SWE-agent, and 71.3 on OpenHands, and its Terminal-Bench score ranging from 25.8 to 36.2 across four scaffolds. Insight’s one-line summary of its cost test was that the harness alone moved the cost by roughly 2.5 times at a fixed model and feature.

This reorders the decision. The model is the cheapest thing to change: it is a config line, and the open-weight field turns over every quarter. The harness and the review workflow around it are where the variance lives, and they are the parts you keep. The best coding agent is the one whose mistakes you can catch, trace, and afford, and that is a property of the workflow, not the weights. It is also why YAGNI sells a workflow, a rate card, and a record rather than a model.

When does a frontier model still win?

Three places, and an honest cost post names them.

The hardest tickets. Insight’s result is the general case for a long, multi-service change with a strict merge gate: a model that needs three attempts costs more than one that needs one, in tokens and in the reviewer’s hours. A migration touching three services is a frontier-model ticket from the first step, and forcing it onto a cheap model makes it dearer. When a team’s task mix is hard enough for the frontier premium to pay for itself, YAGNI says so on the call rather than pretend the floor is free.

Planning and review, where a person reads the output. The steps a person has to read, the plan and the review, are the steps where the quality gap shows up as a human’s time. Spend the frontier premium there and save on the steps a check reads, the searches, the test logs, the summaries, where a small model is as accurate and forty times cheaper.

Self-hosting below scale. Running the weights yourself only beats a hosted API at billions of tokens a month with high utilization. Below that, hosted open-weight is the practical path, and the price spread across hosts (V4-Pro’s output token runs from $1.98 off-peak at its maker to $3.96 at peak and $2.60 at DeepInfra; K3’s from $14.25 to $22.50 depending on host and region) means the host you pick moves the bill as much as the model does.

How does YAGNI use open-weight models?

YAGNI does not ask you to pick a model, because the answer changes every quarter and the right one differs by step. YAGNI publishes four lanes, Efficient, Standard, Advanced, and Peak, each with a per-million-token price on one rate card, locked for twelve months per contract while the models underneath rotate. As better open-weight models land, the lanes are upgraded and the rate does not move. The models are vetted US-hosted open-weight models, and the floor across the card is 60% or more under comparable frontier API rates. YAGNI does not publish which models serve which lane, and the rate card is shared on a call, not published; that floor is the only public number.

YAGNI’s router places each step of a run on the cheapest lane that holds quality, so the ticket above runs with its reads, searches, and test logs on Efficient and its plan and review on the stronger lanes, which is where the per-task studies say the money should go. A step whose check fails goes back on a stronger lane, and the record shows that it did. Three groups ride the same YAGNI router:

• Developers on YAGNI Code, the CLI and desktop coding agent, where every step of a session is sized before it runs.
• Developers who keep Claude Code or Codex. One command, yagni connect claude-code, and the same session runs on YAGNI’s lanes with the same workflow, skills, and MCP servers. The arithmetic for that is in how much Claude Code costs.
• The named Agents on a YAGNI Team. Bailey, the Product Manager, proposes the next ticket from the backlog in Jira or Linear with evidence; Reeve, the Staff Engineer, reads the ticket, the Slack thread, and the Team’s decision ledger before it plans; a person approves the plan; Wright, the Builder, builds it to a draft pull request in a sandbox; Proctor, the Reviewer, posts one review a person can read; Fletcher, in beta, boots the environment and walks the change in a browser; a person merges; and Harper, the Chronicler, posts what shipped to Slack with the receipts attached.

The part that answers the retry problem is not the lane, it is the grounding. The studies above found the retry, not the token price, decides the bill. A YAGNI Agent that reads the Team’s decisions and the connected tools before it plans takes fewer wrong turns, and a plan a person approves before a line is written catches the wrong turn at the cheapest step. Context engineering for coding agents is the long version. The short version is that a cheaper model grounded in your decisions beats an expensive one guessing on your repository.

And the number the studies say to manage, dollars per merged pull request, is the number YAGNI shows. Every run on a ticket’s case file shows what the workspace was charged for it, and YAGNI’s Usage page shows spend per developer and per Agent, broken out by the job that spent it. There are no seats; a developer with zero usage costs zero. The daily spend ceiling in Workspace settings is a person’s brake, and a merge is always a person’s click.

Pick the meter, then the harness, then the model

The listicles rank models because a model table is easy to write. The arithmetic above says the model is the last of three decisions, and the smallest. First, the meter: can you see what a ticket cost, end to end, on your own repositories? Without that number, “best open source LLM for coding” has no answer you can check, and YAGNI’s case file exists to give you one. Second, the harness and the review workflow, which move cost and quality as much as any model swap and are the parts you keep when the field turns over. Third, the model, chosen per step, with the frontier premium spent where a person reads the output and saved where a check does.

That is how a YAGNI Team runs, and how YAGNI Code runs for the developer at the terminal, on one rate card at 60% or more under comparable frontier API rates, with the cost of every ticket on its case file. If you want the ticket arithmetic run on your team’s repositories and task mix, book 30 minutes and bring last month’s bill. The managed version of the whole story, a Team that carries work from proposal to merged pull request under a person’s review, is Agent Teams for software development, and the offer is on the home page. The guide to what AI coding tools cost carries these per-task figures into a cost model for a whole engineering org.