I have been spending a lot of time experimenting with local AI models on an NVIDIA GB10 system.

Like a lot of people running local models, I started with the usual questions:

• Which model is fastest?
• Which one has the biggest context window?
• Which one scores highest on coding benchmarks?
• How large a model can I squeeze into 128 GB of unified memory?
• Is a 100+ billion parameter model automatically better than a 30 billion parameter model?

Those questions turned out to be less interesting than the one I eventually started asking:

Which local model actually behaves like the best software engineer when given a real codebase and told to investigate it autonomously?

So I built a simple experiment.

The results surprised me.

A roughly 29 GB Qwen model consistently produced a better engineering review than models occupying 65, 80, and even 97 GB of my GB10's memory.

And just as interestingly, several models marketed specifically for coding performed worse than more general-purpose models.

The Hardware

The inference server for these tests is an NVIDIA GB10-based system with approximately:

121 GiB usable system/unified memory
16 GiB swap

Ollama runs as a LAN service and the models are accessed remotely from my Fedora workstation.

For these tests I configured Ollama around a large-context, single-agent workload:

OLLAMA_CONTEXT_LENGTH=262144
OLLAMA_NUM_PARALLEL=1

I also eventually settled on keeping only one heavyweight model resident at a time.

That became important.

Rapidly switching between 60–100 GB models can create considerable memory churn. One model, Mistral Medium 3.5, genuinely exceeded the available memory at the configured context size and triggered the Linux OOM killer.

By contrast, Laguna S 2.1 successfully loaded at the full 262K context while occupying roughly 97 GB.

Running models this large locally is quite possible on a GB10, but there is a substantial difference between:

"The model technically fits"

and:

"This is a model I actually want to use all day."

The Agent Harness

I used Pi Coding Agent as the harness for the local-model comparison.

That distinction matters.

I wasn't really benchmarking:

"Can this model answer a coding question?"

I was benchmarking:

"Can this model autonomously explore a repository, use tools intelligently, reject bad hypotheses, follow evidence across multiple files, and prioritize the most important engineering problems?"

Every local model received the same repository, the same environment, and the exact same prompt.

The repository was Hamstik, a Next.js/PostgreSQL project management and issue tracking application I am developing.

I created a disposable Git worktree so the agents could safely inspect the project:

git worktree add --detach /tmp/hamstik-pi-test HEAD
cd /tmp/hamstik-pi-test

Then every model received this prompt:

Review this repository as an experienced software engineer.

Do not modify any files.

First determine what this application does and how it is structured by
inspecting the implementation yourself.

Then identify the five highest-impact correctness, reliability,
architectural, or maintainability problems that you can verify from the
implementation.

For every finding:

• identify the relevant files and implementation
• explain why it is a real problem
• distinguish verified problems from speculation
• recommend a concrete improvement

Do not rely on documentation unless you verify it against the implementation.

Work autonomously until you have enough evidence to give me the review.

That last part was intentional.

I didn't want five code smells.

I wanted the model to investigate.

What This Benchmark Actually Tests

This is not a traditional coding benchmark.

There is no single expected patch and no unit test that tells the model whether it succeeded.

Instead, the model needs to perform several difficult tasks simultaneously.

Repository exploration

It has to decide which files matter instead of blindly reading everything.

Hypothesis generation

It has to notice suspicious implementation patterns.

Verification

It then has to determine whether the suspicious pattern is actually broken.

Cross-layer reasoning

Some bugs only become visible when comparing:

React component
↓
API contract
↓
authorization
↓
database schema

Epistemic calibration

This might be the most important one.

A good reviewer needs to be able to say:

"I thought this was broken. I investigated it. It is actually correct."

Several models were surprisingly bad at doing that.

Prioritization

Finding fifteen problems isn't useful if the final top five consist mostly of cosmetic architecture complaints while a broken authentication path sits unnoticed.

That ended up separating the best models from the rest.

The Models

I tested a fairly ridiculous collection of models that can realistically run on a single GB10.

Among them were:

• Qwen 3.8 27B MTP Q8
• Qwen 3.6 35B-A3B MTP Q8
• Qwen3-Coder-Next Q8
• Nemotron 3.5 Lightning
• Laguna S 2.1
• Laguna XS 2.1
• Gemma 4 31B
• Muse Glimmer 30B
• GLM 4.7 Flash
• GPT-OSS 120B
• Devstral Small 2 24B Q8

I also ran the same general review using Codex with GPT-5.6 Sol as an external reference point.

That wasn't an apples-to-apples local-model comparison, but it gave me a useful idea of what a very strong review looked like.

The Result That Kept Repeating

The best local reviewer was:

Qwen 3.8 27B MTP Q8

And it wasn't particularly close.

Its review identified issues including:

• an OAuth identity/session-ID mismatch
• suspended tenants remaining writable through API authorization paths
• globally ambiguous issue-key resolution
• board ordering that looks correct optimistically in the browser but isn't fully persisted
• authentication endpoints that deserve targeted brute-force protection

What impressed me wasn't merely that it found bugs.

It repeatedly did something several other models failed to do:

Interesting hypothesis
↓
inspect implementation
↓
realize initial assumption was wrong
↓
discard finding
↓
continue investigating

For example, multiple models suspected Hamstik's issue-number generation was vulnerable to a concurrency race.

The implementation essentially does:

UPDATE project
SET issue_counter = issue_counter + 1
RETURNING issue_counter;

inside a PostgreSQL transaction.

Qwen investigated it and correctly concluded that the atomic UPDATE ... RETURNING pattern was safe.

Several other models promoted variants of that same hypothesis into their final reports.

That difference matters.

A senior reviewer who gives me five false positives creates more work than one who gives me three important findings.

Model Size Was a Terrible Predictor

One of the most interesting outcomes was how poorly memory footprint predicted engineering quality.

For example:

Qwen 3.8 Q8
~29 GB
best local review

versus:

Laguna S 2.1
~97 GB loaded
strong review, but not as good

and:

GPT-OSS 120B
~65 GB
one of the weakest reviews

GPT-OSS was particularly interesting.

It identified what it believed were syntax problems in code that was syntactically valid.

Then its own tooling produced contradictory evidence.

Instead of rejecting the hypothesis, the model rationalized around the evidence and continued presenting the problem.

That is nearly the worst possible behavior for autonomous software review.

The problem wasn't intelligence in the abstract.

It was calibration.

Coding Models Weren't Necessarily Better Reviewers

Another surprising result was the performance of explicitly coding-oriented models.

Qwen3-Coder-Next

This is a large coding-focused model and was perfectly capable of navigating the repository.

But its final review included several weak or incorrect conclusions.

Interestingly, during the run it sometimes found better problems and then failed to rank them.

That suggests a distinction between:

implementation ability

and:

engineering judgment.

I would absolutely still test Qwen3-Coder-Next on a benchmark like:

Implement this feature.
Run the tests.
Fix the failures.
Verify the result.

That is a different capability from:

Find the five things in this repository that I should care about most.

Devstral Small 2

This result reinforced the same point.

Devstral Small 2 was extremely efficient as an agent, but its review contained multiple serious mistakes.

It claimed PostgreSQL UPDATE ... RETURNING returned the old value.

It doesn't.

It claimed a Next.js 16 application was missing middleware because it used proxy.ts instead of middleware.ts.

Next.js 16 intentionally renamed the middleware convention to Proxy.

It also described a transaction-owned tx.insert(...) operation as being outside the transaction.

These aren't subjective disagreements about architecture.

They're factual mistakes.

So while Devstral may be excellent at concrete software-engineering tasks, it performed poorly on this particular autonomous-review benchmark.

The Next.js 16 Trap

This repository happened to contain an excellent accidental test.

Hamstik uses Next.js 16.

Next.js 16 renamed:

middleware.ts

to:

proxy.ts

Several models saw:

src/proxy.ts

and confidently reported:

"There is no middleware.ts, so this authentication code is dead."

That would have been correct advice for an older Next.js project.

It is incorrect for Next.js 16.

This is a great example of why repository review demands more than pattern matching.

A model needs to reason about:

framework
+
framework version
+
implementation

not just:

"I remember Next.js middleware being called middleware.ts."

Laguna S Was Strong, but Expensive

Laguna S 2.1 produced one of the better local reviews.

It found:

• the suspended-tenant API authorization gap
• OAuth account collision behavior
• invitation replay/idempotency problems
• several board data-shape inconsistencies

It also showed healthy self-correction during its investigation.

But it was enormously heavier operationally.

While loaded:

Model:   ~97 GB
Context: 262144
Memory:  ~102 GiB used

It left roughly 18 GiB available on the GB10.

That's impressive.

It's also not something I particularly want running just to review a TypeScript repository when a ~29 GB model does the job better.

Laguna XS Produced One of the Strangest Results

The smaller Laguna XS looked attractive because it occupied dramatically less memory.

Then I looked at Pi's cumulative token statistics.

It had processed approximately:

8.5 million cumulative input tokens

during one repository review.

That doesn't mean it had an 8.5-million-token context window.

Agent harnesses repeatedly send accumulated context back to the model on subsequent turns, so Pi's cumulative input counter can greatly exceed the active context window.

Still, it tells us something important.

A small model can be cheap per inference while becoming expensive as an agent if it repeatedly rereads context and takes many steps to reach a conclusion.

This became one of my favorite lessons from the experiment:

Inference efficiency and agent efficiency are not the same thing.

Gemma 4 31B Was a Pleasant Surprise

Gemma 4 31B didn't produce the deepest review, but it behaved conservatively.

It correctly reasoned through PostgreSQL's concurrency behavior rather than inventing an issue-counter race.

It found real problems in the invitation workflow.

It was also relatively efficient.

Its weakness was breadth.

At one point Gemma spent considerable effort looking for where invitations were actually created.

It couldn't find anything.

That was potentially a major product-level finding:

The application contains invite acceptance but apparently no invitation creation workflow.

Instead Gemma said, essentially:

"That's strange."

and moved on.

A stronger reviewer connects that observation to the end-to-end feature.

That difference between code inspection and system reasoning showed up repeatedly.

Muse Found a Great Bug

Muse Glimmer found one of the cleanest deterministic defects in the repository.

The React client creates an issue link using something equivalent to:

{
"targetId": "...",
"type": "..."
}

while the API expects:

{
"linkedId": "...",
"type": "..."
}

Deletion had a similar mismatch:

client: linkId
server: linkedId

The result is straightforward:

User clicks Create Link
↓
client sends targetId
↓
API reads linkedId
↓
linkedId is missing
↓
400 VALIDATION_ERROR

That is exactly the kind of finding I want from an autonomous reviewer.

Codex independently found the same problem.

Several other models inspected both files and missed it entirely.

Nemotron Was Ridiculously Fast

Nemotron 3.5 Lightning deserves its own category.

It wasn't the best reviewer, but it was exceptionally fast while still finding legitimate problems.

Its weakness was severity calibration.

It tended to promote plausible architecture concerns into high-severity findings without proving the impact strongly enough.

But as a first-pass investigator?

I really liked it.

I could imagine a workflow such as:

Nemotron
↓
very fast exploratory review
↓
Qwen 3.8
↓
skeptical verification / prioritization

That may be more useful than simply running one enormous model.

Context Usage Was Also Fascinating

Pi reports cumulative input/output token counts as well as active-context utilization.

Approximate results looked like this:

The fascinating part is Qwen 3.8.

It didn't win by brute-force exploration.

It actually processed less cumulative input than almost every serious competitor.

That suggests it was choosing better investigative branches and abandoning weak ones earlier.

For agentic workflows, that is enormously valuable.

My Informal Ranking

This is not a scientific leaderboard.

It is one repository, one prompt, one harness, and one kind of engineering task.

But for autonomous senior-engineer repository review, my approximate ranking ended up looking like this:

GPT-5.6 Sol through Codex was still the strongest review overall and served as my rough reference at around 9/10.

But that wasn't really the interesting result.

The interesting result was how close some local models could get.

What I Would Actually Run

After this exercise, I wouldn't select models based purely on parameter count.

For my GB10, I would currently think about the local models in roles.

Primary autonomous reviewer

Qwen 3.8 27B MTP Q8

It had the best combination of:

• repository exploration
• cross-file reasoning
• skepticism
• prioritization
• context efficiency
• manageable memory footprint

Fast investigator

Nemotron 3.5 Lightning

Great when I want an agent to rapidly explore an unfamiliar codebase and give me leads.

Conservative second opinion

Gemma 4 31B

Not as deep as Qwen, but relatively disciplined and inexpensive to keep around.

Heavyweight second reviewer

Laguna S 2.1

Capable, but difficult to justify operationally when smaller models perform nearly as well or better.

The Bigger Lesson

The experiment changed how I think about local coding models.

I used to think primarily in terms of:

parameters
quantization
context window
tokens per second
benchmark score

I still care about all of those.

But for autonomous engineering agents, I now care much more about:

How quickly does the model reject a bad hypothesis?

Does contradictory evidence make it change its mind?

Can it connect behavior across UI, API, authorization, and database layers?

Can it distinguish "this smells odd" from "this is actually broken"?

Can it find ten things and still choose the five that matter?

Those qualities don't appear cleanly on a model card.

And they don't necessarily scale with parameter count.

The most surprising outcome from this entire exercise was simple:

The best local software reviewer I tested was not the biggest model. It was the model that wasted the least time being wrong.

For my GB10, at least for this kind of autonomous repository analysis, that model was Qwen 3.8.