Best Local AI Models for Coding in 2026: Qwen3.6, Devstral Small 2, and GLM-4.7-Flash (Compared)

Qwen3.8-27B replaces Qwen3.6-27B as the first recommendation among the best local AI models for coding: its own card reports 61.7 versus 53.5 on SWE-bench Pro in a paired comparison. The upgrade improves the reported coding results without reducing the official FP8 weight download, which is 30.87 GB before context and runtime memory.

The short answer: choose the model your memory can sustain

Pick Qwen3.8-27B when you want a broad local coding default and can run a compatible artifact with enough memory left for your repository context. Keep Qwen3.6-27B as a comparison baseline if an existing deployment is stable, rather than treating it as the newest default. Pick Devstral Small 2 for a focused multi-file coding agent; its own card names a single RTX 4090 or a 32 GB Mac. Choose GLM-4.7-Flash for a mixture-of-experts agent experiment after checking the actual weight format. Reserve Qwen3-Coder-Next for a memory-rich machine or shared server. Qwen3.5-9B remains the smaller candidate for bounded edits, but its official BF16 release is not an 8 GB model. Compare it with JetBrains Mellum2.1 Thinking when a publisher-owned compact GGUF matters; its tradeoffs are covered alongside Qwen3.5 at #6.

Qwen3.8-27B succeeds Qwen3.6-27B with downloadable Apache 2.0 weights. Its own card puts the successor ahead on the paired coding results, including 73.0 versus 63.4 on Terminal Bench 2.1. That makes it the model to evaluate first when refreshing an existing Qwen coding setup, while the memory budget still depends on the exact artifact you deploy.

Model cards, licenses, official weight files, and the vendor pricing references below were verified on October 11, 2026. Benchmark figures are publisher-reported; no model was run for this comparison.

The recommendation uses official artifact fit, coding workflow, and the card's disclosed benchmark method. Qwen3.8 moves ahead of Qwen3.6 because the new card directly compares them. The remaining entries describe distinct deployment roles; scores from different agent scaffolds or benchmark versions do not establish one measured league table.

Three numbers that look similar describe different constraints:

1. Weight-file size is the complete download for a named precision. Qwen's official FP8 files for Qwen3.8-27B total 30.87 GB, while its BF16 files total 55.56 GB. FP8 and BF16 store weights at different numeric precisions.
2. Working memory also includes context, runtime buffers, and other applications. A file-byte total is a planning input, not a publisher-certified RAM minimum. Offloading, format conversion, or skipping the vision encoder can change where that memory is needed.
3. Context capacity is how much input and output a model can handle in one session. The supported maximum does not prove that your machine can allocate it alongside the weights.

Official weights and the hardware budget

The figures below sum the actual files for one complete publisher release, excluding duplicate alternate layouts. GB is decimal download size; GiB is the corresponding binary size. These are weight-only figures, not total inference memory or speed measurements.

GGUF is a local-runtime model file format; Q4_K_M is a particular quantization that stores much of the model at reduced precision. Qwen3-Coder-Next and Mellum2.1 have verified publisher-owned GGUF releases. The table compares deployable artifacts at different precisions, not model efficiency at equal precision. Do not assume that a similarly named community GGUF, MLX conversion, or Ollama package for another model has the same file size, compatibility, or evaluation results as its publisher's weights.

Think of the model file as a person entering an elevator. Fitting through the door proves only that the passenger can get inside. A coding agent also needs room for luggage: repository context, generated tokens, runtime buffers, and the tools around it. Filling the elevator to its stated limit is a poor way to plan a working day.

The illustration's smaller memory tiers depend on community quantizations. Use the official-file table for this comparison's hardware budget; the drawing is not evidence that the publisher's weights fit those machines.

If your goal is the complete editor, review, and cloud-agent experience rather than the underlying model, compare the current AI coding assistants. A local model is one component. It does not automatically provide repository indexing, permission controls, a patch review surface, sandboxing, or a safe command runner.

1. Qwen3.8-27B: best local AI model for coding overall

Qwen3.8-27B is the new default to evaluate because its own comparison improves on Qwen3.6 without increasing the official FP8 weight-file budget. It suits a developer who wants one model to inspect a TypeScript monorepo, explain a failing test, draft a patch, and reason through adjacent product logic. The wall is still memory and runtime compatibility. A better card result does not turn the official weights into a smaller desktop package.

Qwen's card describes 27B language-model parameters, a vision encoder for images and video, and an Apache 2.0 license. The native context is 262,144 tokens, extensible to 1,000,000 with the documented configuration changes. It supports thinking by default, per-request non-thinking mode, adjustable reasoning effort, and preserved reasoning across messages. Those controls matter when a coding agent revisits a plan after tests, logs, or additional files arrive.

The new card reports 61.7 on SWE-bench Pro, compared with 53.5 for Qwen3.6-27B: an 8.2-point gain. It also reports 73.0 versus 63.4 on Terminal Bench 2.1, 42.3 versus 36.2 on NL2Repo-Bench, 42.2 versus 13.3 on DeepSWE 1.1, and 90.3 versus 83.9 on LiveCodeBench v6. Its in-house QwenSWEBench reports 79.0 versus 49.3. These are the publisher's paired results, not measurements made on your repository.

The method is part of the result. For SWE-bench Pro, Qwen used the Claude Code harness with a 256K context, corrected problematic tasks, and re-evaluated the baselines. Do not compare the 73.0 Terminal Bench 2.1 score directly with a Terminal-Bench 2.0 score, or call the benchmark gain a speed gain. The card's coding advantage supports prioritizing a pilot; it does not quantify tokens per second on a GPU or Mac.

The official FP8 files total 30.87 GB, and the BF16 files total 55.56 GB. FP8 requires a compatible serving path; it is not a one-click Mac compatibility promise. If you choose a community conversion for a smaller machine, verify that artifact separately and keep the base model's benchmark results attributed to the base release.

Best for: Developers choosing a new broad local coding model with enough memory for the exact artifact

Standout: Card-reported 61.7 SWE-bench Pro versus its predecessor's 53.5, at the same official FP8 file size

Pricing: $0 model download; LM Studio's local Free tier is $0 where the selected artifact is supported

Free trial: Not applicable; downloadable weights under Apache 2.0

Set up Qwen3.8-27B without mistaking maximum context for a target

1. 1

   Check memory before downloading

   Record available VRAM or unified memory, not just total disk space. Compare it with the exact official format in the table, then leave space for context, the runtime, and the operating system. If the file budget already consumes the machine, choose a smaller verified artifact or model.

2. 2

   Choose the exact model and a compatible runtime

   Use the official Qwen3.8-27B card and files to identify the publisher and precision. The card links SGLang and vLLM deployment recipes. For a Mac or LM Studio setup, confirm support for the actual GGUF or MLX conversion you select rather than treating the model name as a compatibility guarantee.

3. 3

   Start below the maximum context

   Do not begin at 262,144 merely because the model supports it. Start with a context sized for one representative repository task, watch memory use, and increase only when the additional files improve the patch without destabilizing the run.

4. 4

   Expose the local server to one coding agent

   Point one compatible coding client at the local server. Keep the server bound to the local machine unless you have intentionally added network authentication and access controls. Keep tools local too if the purpose is to retain code on the device.

5. 5

   Pilot one bounded repository task

   Use one bug with a known failing test, a small multi-file change, and one explanation task. Review every proposed command and diff. Record accepted patches, correction time, peak memory, and whether the model lost earlier constraints.

2. Qwen3.6-27B: a predecessor baseline for existing deployments

Qwen3.6-27B remains a useful baseline when you already have a stable local coding setup, but Qwen3.8 now takes the default recommendation. Keeping the previous model during a migration lets you compare accepted patches and correction time on the same repository. There is no official FP8 file-size saving to justify choosing it for a new machine. Keep it because the existing workflow has value, not because the page used to rank it first.

Qwen's official model card describes 27B language-model parameters, an Apache 2.0 license, and a 262,144-token native context, extensible to 1,010,000 tokens. It names agentic coding, frontend workflows, repository reasoning, vision input, and preservation of reasoning context across historical messages. Those are useful coding-agent ingredients because a repository task rarely ends after one answer.

Its official FP8 files total 30.87 GB, the same as Qwen3.8's. Its BF16 files total 55.56 GB. A smaller runtime package can be a valid separate deployment, but it does not establish the memory required by these official files.

The original card reports 77.2 on SWE-bench Verified, 53.5 on SWE-bench Pro, 71.3 on SWE-bench Multilingual, 59.3 on Terminal-Bench 2.0, and 83.9 on LiveCodeBench v6. The SWE series used an internal agent scaffold with bash and file-edit tools plus a 200K context. The Terminal-Bench setup used 256K context, 32 CPUs, and 48 GB RAM. Preserve that attribution; the newer card's Qwen3.6 baseline of 63.4 on Terminal Bench 2.1 is a different benchmark version.

Qwen advises reducing context after an out-of-memory error, while recommending at least 128K for complex-task thinking capability. That is the model's named wall. The architecture supports a long window, but your artifact, runtime, and machine determine the useful window you can sustain.

Best for: Existing Qwen3.6 deployments and controlled comparison with the successor

Standout: Card-documented repository reasoning, thinking preservation, and vision input

Pricing: $0 model download; supported local runtime costs are separate

Free trial: Not applicable; downloadable Apache 2.0 weights

3. Devstral Small 2: best dedicated local coding agent

Devstral Small 2 is the focused pick for a developer who wants the model to explore a codebase, edit several files, and operate through software-engineering tools. Mistral describes the 24B model as an agentic software-engineering model. A team maintaining a large Python service can give it a contained issue, let the harness search and edit, then review a multi-file patch. Its wall is the gap between a named deployment target and the memory behavior of the exact file and runtime you choose.

The official Mistral model card identifies the exact release as Devstral-Small-2-24B-Instruct-2512: 24B parameters, FP8 weights, 256K context, vision input, and tool use for repository exploration and multi-file edits. It is Apache 2.0 licensed. Its scope is easy to explain: a software-engineering agent model built to inspect code and edit files through tools.

Mistral reports 68.0% on SWE-bench Verified, 55.7% on SWE-bench Multilingual, and 22.5% on Terminal Bench 2. These are the card's own results. They do not establish a direct ranking against Qwen3.8's SWE-bench Pro or Terminal Bench 2.1 figures, which use different benchmarks or methods.

Mistral's card says the model can run on a single RTX 4090 or a Mac with 32 GB RAM. The six indexed official FP8 shards total 25.79 GB, or 24.02 GiB, in the publisher's file listing. Do not read the machine recommendation as proof that every tensor plus a full context fits in a particular GPU. The card also links community GGUF conversions for local apps; those are different artifacts from Mistral's own FP8 release.

Best for: A dedicated multi-file coding agent with a verified local deployment format

Standout: Software-engineering-agent focus, 256K context, vision, and Apache 2.0 licensing

Pricing: $0 model download; LM Studio's supported local inference tier is $0

Free trial: Not applicable; downloadable model weights

4. GLM-4.7-Flash: best mixture-of-experts experiment

GLM-4.7-Flash is the mixture-of-experts experimenter's choice: a 30B model that activates 3B parameters per token. It suits a builder prepared to check the serving implementation and exact weight format before offering a shared agent endpoint. A mixture-of-experts model stores many parameter groups but uses only a subset for each token. The smaller active count describes computation, not the total weights the machine must store.

Z.ai's official model card lists 30B total parameters with 3B active, an MIT license, 59.2 on SWE-bench Verified, and 64.0 on LiveCodeBench v6. It recommends preserved thinking for multi-turn agentic tasks. These published results describe an agent candidate; they do not supply a local speed measurement.

The card does not state a context length in its descriptive text. Its official configuration sets 202,752 maximum positions. That is the configured length, not a separately benchmarked context claim, and it replaces the earlier runtime-specific 128K shorthand.

The official BF16 files total 62.44 GB, or 58.16 GiB. A community Q4 download can be smaller, but the 3B-active label does not turn the official release into a compact GPU package. A buyer who needs a smaller quantization must verify that file and its runtime separately.

The serving guidance is also part of the choice. The card says vLLM and SGLang support uses their main branches. That is the card's stated integration path, not proof that every current stable version is incompatible. Pin a working model and runtime combination before giving other developers a shared endpoint.

For a small internal platform team, the sensible use case is one local service behind a coding client. Run repository search, patch generation, tool-call parsing, and long-output checks before standardizing it. If the team cannot reproduce the environment after an update, a promising architecture has not become a dependable workflow.

Best for: Builders validating a mixture-of-experts coding-agent deployment

Standout: 30B total / 3B active parameters with card-reported coding scores and an MIT license

Pricing: $0 model download; hardware and the serving runtime remain separate

Free trial: Not applicable; downloadable weights

5. Qwen3-Coder-Next: best for a memory-rich local agent server

Qwen3-Coder-Next is the specialist for a memory-rich local server. Qwen designed it specifically for coding agents and local development, with long-horizon reasoning, complex tool use, and recovery from execution failures. It makes sense for a small platform team centralizing a controlled local endpoint. Its wall is physical: reduced active computation does not remove the large parameter store.

The Qwen model card describes 80B total parameters with 3B active per token, an Apache 2.0 license, 262,144 native context, and non-thinking mode only. It calls out coding-agent tasks, tool use, CLI/IDE integration, and recovery after execution failures.

The benchmark chart embedded in the card reports 70.6 on SWE-bench Verified, 62.8 on SWE-bench Multilingual, 44.3 on SWE-bench Pro, 36.2 on Terminal-Bench 2.0, and 66.2 on Aider. The chart labels the SWE results as using SWE-Agent and the terminal result as using Terminus-2 json. Those methods differ from Qwen3.8's new comparison, so the scores are evidence for this model's role rather than a controlled head-to-head result.

The official download gives a firmer hardware anchor than the previous runtime package. Qwen's Q4_K_M GGUF release totals 48.41 GB, or 45.09 GiB, across its complete set of four files. The Q8_0 version totals 84.81 GB, or 78.99 GiB. These are publisher-owned files, not interchangeable with an Ollama package size.

A 64 GB-class machine is a reasonable planning candidate for the Q4 files plus a reduced context, but that is an estimate from the file budget, not a vendor-certified minimum. Do not assume that the full native window or several simultaneous sessions fit. Shared capacity needs a measured context and concurrency budget.

Qwen's card gives useful failure guidance: reduce context to 32,768 if the server fails to start or hits an out-of-memory condition. A reliable shorter session that edits and tests the right files is worth more than a maximum-context setting that repeatedly crashes.

The non-thinking behavior can be an advantage or a limit. It avoids an explicit reasoning-output phase, but a buyer who needs preserved thinking should evaluate Qwen3.8 or Qwen3.6. Do not infer identical behavior from the shared Qwen name.

Best for: A memory-rich server serving controlled coding-agent workloads

Standout: Coding specialization, 80B total / 3B active parameters, and official Q4_K_M GGUF files

Pricing: $0 model download; runtime and hardware costs remain separate

Free trial: Not applicable; downloadable Apache 2.0 weights

6. Qwen3.5-9B: best smaller candidate for bounded tasks

Qwen3.5-9B is the smaller candidate for explanations, snippets, test generation, and tightly bounded edits. Its card includes thinking, tools, vision, and agent behavior. The wall is both scope and artifact size: the official BF16 files total 19.31 GB, so the model name alone does not make it an 8 GB recommendation. A low-memory developer needs to verify a separate smaller artifact before committing to this model.

The official Qwen3.5-9B card states 9B language-model parameters, a vision encoder, Apache 2.0 licensing, 262,144 native context, and an extension up to 1,010,000 tokens. Qwen reports 65.6 on LiveCodeBench v6, 66.1 on BFCL-V4, and 79.1 on TAU2-Bench. LiveCodeBench measures code generation, while BFCL and TAU2 probe tool and agent behavior; none is a SWE-bench repository result from Qwen's own evaluation. JetBrains' separate Qwen3.5 comparison below uses a different evaluation pipeline.

Its official BF16 release totals 19.31 GB, or 17.98 GiB. No publisher-owned smaller quantization was verified for this comparison. Community GGUF and MLX conversions are separate deployment choices, so any memory promise needs the actual conversion's file size and a runtime check.

The context headline needs the same restraint as the larger models. Qwen advises reducing context after an out-of-memory error and recommends at least 128K for complex-task thinking. That does not promise such a window on a compact machine. Pass only the files required for the task and prefer a sequence of reviewable edits over one long autonomous run.

A good use case is a developer learning an unfamiliar function: supply the function, its tests, and the relevant type definitions; ask for an explanation and a minimal patch; then run the tests yourself. A poor use case is treating the smaller parameter count as proof that an unattended agent can redesign a large monorepo. Its availability and bounded task fit decide the choice.

Best for: Snippets, explanations, tests, and bounded diffs with a verified smaller deployment

Standout: The smallest language-model parameter count in this selection, with thinking, tools, and vision

Pricing: $0 model download; compatible local runtime costs are separate

Free trial: Not applicable; downloadable Apache 2.0 weights

Mellum2.1: a compact challenger to Qwen3.5-9B

Mellum2.1 earns a pilot alongside Qwen3.5-9B when you want a compact, publisher-owned local artifact for a coding agent. Give it a bounded job such as finding a failing test's cause and proposing a patch. The decision turns on the artifact you can run and the corrections your repository needs.

Since October 8, 2026, JetBrains' Mellum2.1 release has added a coding-agent candidate with 12B total parameters and 2.5B active under Apache 2.0. Its Thinking model card specifies 131,072-token context.

JetBrains' model-card results show a tradeoff. Mellum2.1 scores 82.0 versus Qwen3.5-9B's 75.4 on LiveCodeBench v6, but 47.0 versus 50.0 on SWE-bench Verified. These percentages are self-reported by JetBrains. Its agent evaluations use the same Pi harness with shell and file tools, 114K context, and each model's default sampling. Qwen's own 65.6 LiveCodeBench result above belongs to a different evaluation; do not substitute it into JetBrains' pair. Code-generation strength does not establish a repository-agent win.

The launch post says GGUF builds are coming soon, but the current JetBrains collection already includes them. Its GGUF card documents llama.cpp, Ollama, and LM Studio support, with commands for the first two. The base card documents vLLM, including reasoning and tool-call parsers. Check your installed runtime against the chosen artifact before a team rollout.

The official Q4_K_M file is 8.07 GB / 7.52 GiB, versus 24.30 GB for the BF16 safetensors release. Qwen3.5-9B's 19.31 GB BF16 release is smaller than Mellum's BF16 release. Comparing Mellum Q4 with Qwen BF16 therefore shows available download choices, not an equal-precision memory advantage. Neither the active parameter count nor the Q4 size guarantees an 8 GB working setup, and the base model's scores are not verified Q4 scores.

JetBrains reports almost twice Qwen3.5-9B's token throughput under heavy load in its H200 comparison, plus a roughly 1.6× single-request gain from multi-token prediction (MTP). The vLLM MTP head remains listed as coming soon. Those server results do not establish desktop speed or a speedup from the currently downloadable GGUF.

Pick Mellum2.1 for an official compact-artifact pilot; keep Qwen3.5-9B in the comparison when repository completion matters. Before changing the default, run both on the same bounded tasks and count accepted patches and correction time.

Who should pick what?

The choice becomes simple once the exact artifact and workload are stated together.

On an 8 GB machine: even Mellum2.1's Q4_K_M weights occupy 7.52 GiB before context and runtime overhead, so the table still establishes no comfortable working fit. LM Studio's system requirements tell 8 GB Mac users to use smaller models and modest context. That is application guidance, not certification for any checkpoint here.

On a 16 GB-class machine: Mellum2.1's official Q4_K_M file is now a concrete candidate to evaluate with modest context. This is a planning judgment from the file size, not a tested RAM requirement. Verify runtime support and measure headroom; its full context is not a starting target. A community Qwen3.5 conversion remains a separate artifact to verify.

On a 24 GB-class GPU: do not assume the official Qwen3.8 FP8 weights fit fully in VRAM. Devstral Small 2 has a card-backed RTX 4090 target, but the exact conversion, text-only configuration, offload, and context still matter. Check an actual supported file and measure headroom before calling the machine suitable.

On a 32 GB Mac: Devstral Small 2 has the clearest explicit machine guidance in its card. That does not make every publisher FP8 checkpoint a native Mac package. Verify the chosen runtime format before loading it. Qwen3.8 is the newer broad model to evaluate when a compatible artifact leaves enough working memory.

On a 64 GB-class machine or local server: Qwen3-Coder-Next's official Q4_K_M files provide a concrete starting point at 45.09 GiB, with context and runtime overhead still to budget. GLM-4.7-Flash's BF16 files alone occupy 58.16 GiB as a stored artifact, so nominal machine capacity should not be mistaken for a working agent budget. Shared servers also need an access and concurrency plan.

On an existing Qwen3.6 deployment: keep the predecessor available during the Qwen3.8 pilot. The new card gives a clear reason to try the successor; only your representative tasks can establish whether the migration reduces corrections or improves accepted patches.

The flip rule is compact: if two artifacts leave headroom, choose the model whose documented behavior fits the job; if only one leaves headroom, start with that one. Benchmark rank cannot rescue a setup that spends the workday swapping, crashing, or running with too little context to understand the change.

The local-seat crossover: when hardware belongs in the budget

Local weights begin at $0, but local coding does not. The bill moves from a subscription to hardware, electricity, setup, updates, access control, and developer time. A machine you already own changes the decision. A machine bought only for local inference must earn its line item.

LM Studio's Free tier costs $0 and includes supported local inference. Its offline documentation says downloaded local models, local document processing, and the local server can operate offline. Keep inference and tools local for that code boundary; optional hosted models and connected features are separate choices. That privacy and offline boundary can justify local inference even when the subscription comparison does not. It can matter for unreleased source code, field work without stable connectivity, or a team that needs model availability independent of a provider outage.

The clean budget comparison uses public sticker lines, not a promise of total cost. NVIDIA launched the 32 GB RTX 5090 at a $1,999 starting price. That is a launch-price reference, not a current retail quote. GitHub's current individual plans list Copilot Free at $0, Pro at $10 per user per month, Pro+ at $39 per user per month, and Max at $100 per user per month. Organization pricing is $19 per user per month for Business and $39 for Enterprise. Usage-based charges can add to the seat bill.

• One $10 Pro seat takes 199.9 months, about 16.7 years, to equal a $1,999 GPU starting price.
• Ten Business seats cost $190 per month. The GPU sticker price equals 10.5 months of that line.
• Ten Enterprise seats cost $390 per month. The GPU sticker price equals 5.1 months of that line.

That consequence is more useful than a release spec. Do not buy a high-end GPU merely to eliminate one $10 cloud seat. Buy because the code boundary must remain local, offline access has operating value, the hardware already exists, or a team can share capacity without turning one machine into a queue.

Cloud seats also buy more than inference. A coding-assistant plan can include hosted models, editor integration, cloud agents, code review, identity, policy, and support. A local model download buys none of those controls by itself. If metered inference is a better comparison than a seat, the cheapest AI API analysis shows why token price is only one part of the application bill.

The Monday decision is therefore asymmetric. A solo developer with suitable existing hardware should evaluate a compatible Qwen3.8 artifact before paying for another service. A developer without a verified local fit should begin with the current cloud path or a separately verified smaller model file. A ten-person team with sensitive code should run a two-week shared-server pilot and measure concurrency, accepted patches, correction time, and operator hours before buying a fleet.

How these local coding models were picked

The six ranked entries plus Mellum2.1, compared alongside #6, cover seven models. Qwen3.8 is the successor, and Qwen3.6 stays visible as the baseline it replaces. The specialist entries retain distinct coding roles rather than claiming a new cross-vendor benchmark ranking.

Six criteria govern the recommendations:

1. Downloadable weights: Each model needs an official Hugging Face card and public publisher weight files. A hosted-only model cannot qualify.
2. Hardware evidence: Official precision and complete file-byte totals anchor the table. A publisher's named machine guidance is stated separately from an inferred planning target.
3. Card-documented coding behavior: Repository reasoning, tools, coordinated edits, and recovery from failures matter to the job, but only capabilities stated by the model's own card are attributed to it.
4. Serving requirements: The card's runtime guidance and out-of-memory advice reveal work a deployment may require. An unverified conversion is not treated as an official file.
5. Explicit licenses: Apache 2.0 or MIT comes from each model's own card, not from the general reputation of its model family.
6. Comparable evidence: The Qwen3.8 card directly compares it with Qwen3.6. JetBrains' model card separately compares Mellum2.1 with Qwen3.5-9B. Other results retain their benchmark names and disclosed methods; different scaffolds and benchmark versions are not one league table.

No model was exercised during this run, so the title says Compared, not Tested. The comparison uses the official cards, their embedded benchmark figures, publisher files, and rechecked pricing references. A publisher benchmark and a patch accepted in your repository remain different kinds of evidence. No local tokens-per-second figure is claimed.

The list excludes hosted-only models and models whose weights cannot be downloaded. It does not add a newer model merely because a release exists: a developer still needs an actual artifact, a clear license, and a workable deployment budget.

The ones to avoid for this job

Avoid a hosted-only model presented as a local choice. An API name and a model card do not replace downloadable weights. Confirm the actual publisher file links before investing time in a deployment.

Avoid choosing by active parameter count alone. GLM-4.7-Flash and Qwen3-Coder-Next each activate 3B parameters per token, yet their official artifacts in this comparison total 62.44 GB in BF16 and 48.41 GB in Q4_K_M respectively. Active computation and stored weights answer different questions, and those two formats are not a precision-matched memory comparison.

Avoid carrying the predecessor forward as the fresh default without evaluating the successor. Qwen3.6 can remain a useful pinned baseline. Qwen3.8's own paired comparison now gives a concrete reason to run the migration pilot.

Avoid an undocumented community quantization as the team baseline. A community build can be a valid deployment choice, but record the exact file, quantization, prompt template, runtime version, license, and checksum before several developers depend on it. Keep its provenance distinct from the publisher's evaluated checkpoint.

Avoid maximal context on day one. A 262,144-token model card is not an instruction to allocate that window for every task. Start with the smallest context that contains the relevant code and tool history. Increase it after a failed patch demonstrates missing information, not because a slider allows it.

Frequently asked questions

What is the best local AI model for coding in 2026?

Qwen3.8-27B replaces Qwen3.6 as the overall recommendation, with card-reported SWE-bench Pro scores of 61.7 versus 53.5. Its official FP8 weights total 30.87 GB, so the choice depends on an artifact that fits with working headroom. Qwen3-Coder-Next serves a larger coding-agent setup, and Qwen3.5-9B is the smaller bounded-task candidate.

What is the best self-hosted AI model for coding?

Evaluate Qwen3.8-27B first for a broad coding deployment. Qwen3-Coder-Next is a specialist for coding agents, long-horizon tools, and execution-failure recovery, with official Q4_K_M files totaling 48.41 GB. Select the format and context budget before deciding whether the server is suitable.

Which Ollama model is best for coding?

Qwen3.8-27B is the base model to evaluate first from the official-card comparison, but an Ollama package is a separate artifact. Confirm its publisher or converter, exact quantization, weight size, and current runtime support. The Hugging Face FP8 size is not an Ollama package size or proof of an available tag.

How much RAM or VRAM do I need for a local coding model?

There is no single card-certified minimum for every format here. Official weight files total 30.87 GB for Qwen3.8 FP8, 25.79 GB for Devstral Small 2 FP8, 62.44 GB for GLM BF16, 48.41 GB for Qwen3-Coder-Next Q4_K_M, 19.31 GB for Qwen3.5-9B BF16, and 8.07 GB for Mellum2.1 Q4_K_M GGUF. Context, conversion, offload, and runtime buffers change working memory; Mistral separately names an RTX 4090 or 32 GB Mac target.

Can I run Mellum2.1 in Ollama or LM Studio?

JetBrains' official GGUF card now documents both, alongside llama.cpp, and the collection contains downloadable files despite the launch post's coming-soon wording. Its Q4_K_M file is 8.07 GB before context and runtime memory. Check the installed runtime and tool-call behavior; availability is not a tested fit for every machine.

Are local AI coding models free?

The seven model downloads begin at $0, and LM Studio's supported local inference tier is $0. The system still carries hardware, electricity, setup, updates, access control, and engineering time. Optional hosted models or connected tools have a separate privacy and cost boundary.

Your Monday move

Do not start by ordering a GPU. Start with a one-repository fit test.

Monday: inventory the machine and choose one candidate

Record available VRAM or unified memory, system RAM, operating system, and whether the machine already supports LM Studio. Compare the exact official format with available memory. Evaluate Qwen3.8 first when a compatible artifact leaves headroom, consider Devstral against its stated machine guidance, and use a smaller conversion only after verifying it. Mellum2.1 Q4_K_M is another candidate when the larger official files leave too little room. Do not download all seven.

Tuesday: define three representative tasks

Use one failing test with a known fix, one small multi-file change, and one explanation task from a repository the team understands. Remove secrets and grant the coding agent only the tools the task requires. Save the expected behavior before starting.

Wednesday: run below maximum context

Begin with a bounded context and the smallest relevant file set. Record peak memory, time to first useful patch, commands requested, tests passed, and human corrections. If the model misses a dependency, add the missing file before expanding the entire context window.

Thursday: compare with the current cloud path

Run the same three tasks through the assistant or API already being paid for. Compare accepted patches and correction minutes, not prose confidence. Include setup and operator time on the local side.

Friday: make one of three decisions

Keep local if privacy, offline use, control, or accepted-patch economics improved. Keep the cloud seat if it remains cheaper and easier. Upgrade hardware only when the pilot identifies memory as the limiting factor and the local benefit is worth owning the machine.