Can you run code review with a local LLM, and what hardware does it take?

Yes, at three realistic tiers (status July 2026): 8-12GB VRAM runs 7-8B coder models - useful for focused, diff-level review; 16GB runs the 14B class comfortably. 24GB (RTX 3090/4090 territory) runs quantized 32B-class models like Qwen3 32B, where local review starts feeling like a serious second opinion. Below 8GB, deterministic checks plus a very small model for summaries is the honest setup. RAM-only works but is slow enough to change how you use it.

Which models are worth using for local code review?

The Qwen coder family has been the consistent recommendation across sizes in 2026 community testing - Qwen 2.5 Coder 7B at the entry tier, the Qwen3 generation at 14B and 32B above it. The practical advice ages fast, deliberately: check a current leaderboard the week you set up, because the best-local-model answer has changed roughly quarterly. What does not change is the sizing logic - pick the largest coder model your VRAM runs at Q4 quantization with usable speed.

How hard is the setup really?

The runtime is the easy part: Ollama (or llama.cpp directly) serves a quantized model with an OpenAI-compatible API in minutes, and most tools that accept a custom endpoint can point at it. The real work is the workflow around it. Deciding what the model reviews, wiring it into pre-commit or CI, and keeping prompts and context sizes within what a local model handles well. Plan a day for a useful pipeline, not an hour.

How much worse is a local model than a frontier model, honestly?

Noticeably, and the gap depends on the task. On focused diff review with clear instructions, a 32B-class local coder model catches a solid share of what matters. On long-context reasoning across many files, subtle architectural implications, and rare-language corner cases, frontier models remain clearly ahead (status July 2026). The honest framing: local review trades peak insight for a hard data boundary - a trade that is right where the code must not travel and wrong where it may.

What carries the quality load if the model is smaller?

Structure. A smaller model reviewing against a written task with boundaries and acceptance criteria outperforms its weight class, because the hardest part. Knowing what the change was supposed to do - is handed to it instead of guessed. Add the deterministic layer (types, tests, linters, build), which has zero quality loss offline, and the local setup covers more than its benchmark scores suggest. The model is the icing; the reference and the deterministic checks are the cake.

When is local LLM review the wrong choice?

When nothing stops you from using stronger options. If your policies permit cloud processing for the code in question, a frontier model or a good cloud reviewer will catch more per run. Local review earns its keep where the data boundary is the constraint - client code, regulated repositories, air-gapped environments - or as the always-available baseline layer that costs nothing per query. Choosing it for ideology rather than constraints usually ends in quiet disuse.

Local-first

Local LLM Code Review

Last updated: 2026-07-025 min read

Local LLM code review is workable from about 8GB of VRAM and gets serious at 24GB, where quantized 32B-class coder models run (status: July 2026). The honest trade: peak insight for a hard data boundary - no code leaves the machine. What makes the smaller model punch up is structure: a written task as the review reference, plus the deterministic layer, which loses nothing offline.

Contents

Why teams do this at all

The motivation is the data boundary, not the benchmark. A local model means the review step adds no provider to your jurisdiction analysis, no entry in the transmission-path map, and no per-query cost that scales with AI volume. The BSI/ANSSI baseline - verify generated output - applies identically; local review is one way to run that verification where the code must not travel.

The hardware tiers, honestly labeled

Each tier pairs the VRAM it needs with the coder-model class it runs and the review it realistically carries. The model picks are dated community readings that age quarterly, and the capability labels are the page's own honest judgment - not a benchmark claim.
	Typical hardware	Coder-model class	What review it carries
Entry	8-12GB VRAM (RTX 3060/4060) or 16GB Apple SiliconLocalLLM.in, Ollama VRAM-tier guide (community reading) · 2026	7-8B coder (e.g. Qwen 2.5 Coder 7B, Q4)PromptQuorum, best local LLMs by VRAM tier (community reading) · 2026Model picks age quarterly - check a current leaderboard at setup.	Focused diff review, summaries, obvious-bug passesHonest capability label · 2026-07
Mid	16GB VRAM or 32GB unified memoryLocalLLM.in, Ollama VRAM-tier guide (community reading) · 2026	14B class (Q4)PromptQuorum, best local LLMs by VRAM tier (community reading) · 2026Model picks age quarterly - check a current leaderboard at setup.	Solid single-file and small-diff review with clear tasksHonest capability label · 2026-07
Serious	24GB VRAM (RTX 3090/4090) or 48GB+ unifiedLocalLLM.in, Ollama VRAM-tier guide (community reading) · 2026	32B class (e.g. Qwen3 32B, Q4)PromptQuorum, best local LLMs by VRAM tier (community reading) · 2026Model picks age quarterly - check a current leaderboard at setup.	A real second opinion on typical PRs; multi-file within context limitsHonest capability label · 2026-07
Team server	48GB+ VRAM or multi-GPULocalLLM.in, Ollama VRAM-tier guide (community reading) · 2026	32-70B class, larger contextPromptQuorum, best local LLMs by VRAM tier (community reading) · 2026Model picks age quarterly - check a current leaderboard at setup.	Shared review endpoint for a whole team's pre-commit hooksHonest capability label · 2026-07

Each tier pairs the VRAM it needs with the coder-model class it runs and the review it realistically carries. The model picks are dated community readings that age quarterly, and the capability labels are the page's own honest judgment - not a benchmark claim.

Two setup notes that save disappointment: Q4-quantized models are the working standard (roughly a quarter of the FP16 memory at minor quality cost), and Ollama gets a model serving an OpenAI-compatible API in minutes - the runtime was solved years ago; the workflow around it is where your day goes. Community VRAM-tier guides track the current model picks per tier.

How the tiers and the data path are derived

Scope: Teams that must keep code on their own machine and want AI review anyway. Where the code actually goes at each step, and what carries the quality when the model is small.
Status: July 2026
Method: Hardware sizing is read from the community VRAM-tier guides; the runtime from Ollama's own docs. The verify-the-output baseline from the BSI/ANSSI recommendation; and the fully-local vs local-first vs cloud distinction from where each step sends the code.
Load-bearing facts: Fully local: The coder model runs on your own hardware behind Ollama; the code under review never leaves the machine and adds no provider to your transmission-path mapOllama, local model runtime (first-party) · 2026
Local-first: Reality Graph's written task, change-against-task verification and evidence report stay in your environment by design; the whole review loop runs where the code already isReality Graph architecture · 2026-07
Cloud, for contrast: A frontier or cloud reviewer sends the code to a provider; it catches more per run but reintroduces exactly the transmission path local review removesData-path contrast · 2026-07
The deterministic layer: Types, tests, linters and the build run offline with zero data egress and zero quality loss; the model only ever sees what survived themDeterministic-layer analysis · 2026-07
Verify the output either way: The obligation to verify generated code applies identically regardless of where the model runs; local review is one way to run that verification where the code must not travelBSI/ANSSI, verify AI-assistant output (regulator baseline) · 2024
The stable sizing rule: Pick the largest coder model your VRAM runs at Q4 quantization with usable speed; the model names age, but this rule does notLocalLLM.in, Ollama VRAM-tier guide (community reading) · 2026
Deliberately excluded: Any data-privacy or security guarantee - running local removes a transmission path, it does not certify your data hygiene
Any evergreen model recommendation - the best-local-model answer changes roughly quarterly; check a current leaderboard at setup
Any benchmark or frontier-parity claim - a local model trades peak insight for the data boundary, and this page says so
Limitations: VRAM tiers and model picks are dated July 2026 community readings and move; the sizing logic (largest coder model at Q4) is the stable part
Local review is one change at a time on laptop-tier hardware; throughput needs a sized team server
A local 32B model is not a frontier model on long-context or architectural reasoning, and no quantization trick changes that

Local removes the transmission path, not the need for hygiene: cite where the code goes at each step, and read the model picks as post-July-2026 but still moving.

What makes a small model punch up

A written task as the reference. The hardest review question - what was this change supposed to do? - gets answered by the task, not guessed by the model. Scope and criteria checks are exactly the focused work smaller models do well.
The deterministic layer first. Types, tests, linters, build - zero quality loss offline, zero VRAM. The model only ever sees what survived them.
Small, focused diffs. Local context windows are the binding constraint; review per change, not per branch, and the constraint mostly stops binding.

Framed this way, the model is the icing: the reference and the deterministic checks carry the quality load, and the LLM adds judgment-shaped findings on top. That is also why the honest comparison with frontier models - which remain clearly ahead on long-context and architectural reasoning - matters less in this setup than raw benchmarks suggest.

The honest limits

A local 32B model is not a frontier model. Multi-file reasoning at depth, subtle cross-cutting implications and rare stacks favor the big cloud models, and no quantization trick changes that (status: July 2026). Throughput is also real - a shared team server needs sizing, and a laptop-tier setup reviews one change at a time. The decision rule from the local review guide applies: local where the data boundary binds, stronger models where it does not - by repository, not by ideology.

Where Reality Graph fits

Reality Graph is the structure side of this page: local-first by design, it provides the written task, the change-against-task verification and the evidence report that make a modest local model far more useful than its size - and the whole loop stays in your environment, matching the reason you chose local in the first place. It does not ship an LLM and does not require one particular model; it makes whatever you run verifiable. The detail of which bytes stay on your hardware is written out separately, including the exceptions.

The concrete setup steps this points to

Pick the largest coder model your VRAM runs at Q4 with usable speed
Serve it locally behind an OpenAI-compatible endpoint with Ollama
Feed it the written task and only what survived types, tests and linters
Wire it into pre-commit or CI and review per change, not per branch

What it does not give you

Frontier-model quality from a small local model - the gap is real
An evergreen model pick - check a leaderboard at setup time
A data-privacy verdict - local removes a transmission path, hygiene still applies
A reason to skip the deterministic layer - it carries the base load offline

Local and local-first keep the code in your environment, which removes a transmission path - it is not a privacy guarantee, and the deterministic layer still carries the base load.

FAQ

Can you run code review with a local LLM, and what hardware does it take?: Yes, at three realistic tiers (status July 2026): 8-12GB VRAM runs 7-8B coder models - useful for focused, diff-level review; 16GB runs the 14B class comfortably. 24GB (RTX 3090/4090 territory) runs quantized 32B-class models like Qwen3 32B, where local review starts feeling like a serious second opinion. Below 8GB, deterministic checks plus a very small model for summaries is the honest setup. RAM-only works but is slow enough to change how you use it.
Which models are worth using for local code review?: The Qwen coder family has been the consistent recommendation across sizes in 2026 community testing - Qwen 2.5 Coder 7B at the entry tier, the Qwen3 generation at 14B and 32B above it. The practical advice ages fast, deliberately: check a current leaderboard the week you set up, because the best-local-model answer has changed roughly quarterly. What does not change is the sizing logic - pick the largest coder model your VRAM runs at Q4 quantization with usable speed.
How hard is the setup really?: The runtime is the easy part: Ollama (or llama.cpp directly) serves a quantized model with an OpenAI-compatible API in minutes, and most tools that accept a custom endpoint can point at it. The real work is the workflow around it. Deciding what the model reviews, wiring it into pre-commit or CI, and keeping prompts and context sizes within what a local model handles well. Plan a day for a useful pipeline, not an hour.
How much worse is a local model than a frontier model, honestly?: Noticeably, and the gap depends on the task. On focused diff review with clear instructions, a 32B-class local coder model catches a solid share of what matters. On long-context reasoning across many files, subtle architectural implications, and rare-language corner cases, frontier models remain clearly ahead (status July 2026). The honest framing: local review trades peak insight for a hard data boundary - a trade that is right where the code must not travel and wrong where it may.
What carries the quality load if the model is smaller?: Structure. A smaller model reviewing against a written task with boundaries and acceptance criteria outperforms its weight class, because the hardest part. Knowing what the change was supposed to do - is handed to it instead of guessed. Add the deterministic layer (types, tests, linters, build), which has zero quality loss offline, and the local setup covers more than its benchmark scores suggest. The model is the icing; the reference and the deterministic checks are the cake.
When is local LLM review the wrong choice?: When nothing stops you from using stronger options. If your policies permit cloud processing for the code in question, a frontier model or a good cloud reviewer will catch more per run. Local review earns its keep where the data boundary is the constraint - client code, regulated repositories, air-gapped environments - or as the always-available baseline layer that costs nothing per query. Choosing it for ideology rather than constraints usually ends in quiet disuse.

Keep reading

SetupLocal AI Code ReviewReviewing and verifying AI-generated code inside your own environment, without uploading source to an external service - who needs it, and how to set it up.Local-firstAir-Gapped AI Code VerificationVerification is the offline-friendly half of AI coding: the deterministic layer is offline-native, local models run disconnected, evidence is files with the code. What the gap really constrains: the generator.All articlesThe whole collection - 58 cited, dated guides on verifying AI-generated code.

Sources

Want to see what your last agent run would have looked like?

Request access