I tried again to run Claude Code + Ollama locally on the 128GB memory of DGX Spark

Introduction

Hello, I'm Morishige from Classmethod's Manufacturing Business Technology Department.

In a previous article, I wrote about my attempts to run Claude Code on a local LLM on a MacBook Pro (M4 32GB) — and how they all failed.

https://dev.classmethod.jp/articles/claude-code-ollama-local/

I tried models from 1.5B to 14B, but none could overcome the tool-calling barrier: Qwen2.5-Coder just output TodoWrite JSON text as-is, DeepSeek-R1 hallucinated by insisting it had read files that didn't exist, and Gemma2 endlessly generated irrelevant task lists.

With 128GB of unified memory, you can load models in the 120B class. Would something that failed at 14B work if you multiplied the model size by 10? The conclusion, to put it upfront, was: "Some models get closer to practical use, but they're still far from being a replacement for Claude Sonnet 4.5."

Changes Since Last Time

In the roughly two weeks since my previous verification (January 25, 2026), a few things have changed.

Software Updates

Ollama updated from v0.15.1 → v0.15.5. The easy setup via ollama launch claude is the same as before. Claude Code updated from v2.1.15 → v2.1.34. The biggest changes in this verification were mainly the hardware (MacBook Pro 32GB → DGX Spark 128GB) and the model scale.

Newly Released Models

Since the previous verification, new models with tool-calling support have been appearing one after another. The current Ollama Claude Code recommended models are the three lineups: qwen3-coder, glm-4.7, and gpt-oss. This time I tested four models: qwen3-coder-next, the next-generation version of qwen3-coder, glm-4.7-flash, and gpt-oss:20b / gpt-oss:120b.

• gpt-oss — An open-weight model OpenAI released publicly for the first time in about 6 years since GPT-2
• glm-4.7-flash — SWE-bench 59.2%, lightweight MoE
• qwen3-coder-next — SWE-bench 70.6%, 80B MoE specialized for coding

Claude Code consumes a large number of tokens just from tool definitions + system prompts. In Ollama v0.15.5, num_ctx is automatically set based on VRAM (262144 for 48GB or more), but this time I explicitly set it to 65536 for stability.

# Extend context in Modelfile
FROM gpt-oss:20b
PARAMETER num_ctx 65536

Verification Environment

Comparison with Last Time

Memory is 4x, bandwidth is about 2.3x. The loadable model size expands from 14B → 120B+.

Verification Tasks

I ran the following 4 tasks on each model and compared the results. The prompts are somewhat loosely written to give the models some room for interpretation :)

• Task A — FizzBuzz code generation (for comparison with last time)
  Prompt: Write FizzBuzz
• Task B — React component file creation (tool calling)
  Prompt: Write a simple counter component in React with TypeScript and save it to a file
• Task C — Reading existing code + modification (Read → Edit coordination)
  Prompt: There seems to be a bug in utils.ts, please read it and fix it

The buggy utils.ts used in Task C is the following code. Because seen.add(item) is missing in removeDuplicates, duplicate removal doesn't work, and average returns NaN on an empty array.

export function removeDuplicates<T>(items: T[]): T[] {
  const seen = new Set<T>();
  const result: T[] = [];
  for (const item of items) {
    if (!seen.has(item)) {
      result.push(item);
      // seen.add(item) is missing — duplicate removal doesn't work
    }
  }
  return result;
}

export function titleCase(str: string): string {
  return str
    .split(" ")
    .map((word) => word.charAt(0).toUpperCase() + word.slice(1).toLowerCase())
    .join(" ");
}

export function average(numbers: number[]): number {
  let sum = 0;
  for (const n of numbers) {
    sum += n;
  }
  return sum / numbers.length; // Returns NaN on empty array
}

• Task D — Project creation + test execution (multi-step agent behavior)
  Prompt: Create a new directory fizzbuzz-project, implement a FizzBuzz function in TypeScript, write tests for it, and run them

Verification Assumptions

• Each task was run 3 times to also check stability

Candidate Models for Verification

Selected from models that can run on DGX Spark's 128GB memory, with tool-calling support as a condition.

Verification 1: gpt-oss:20b

An open-weight model that OpenAI released publicly for the first time in about 6 years since GPT-2. Let's start with this as a warm-up.

Setup

ollama launch claude --model gpt-oss-20b-64k

Task A: FizzBuzz

After running 3 times, there was variability in the results.

• 1st run (48 seconds) — Only output code as text, no file was created
• 2nd run (31 seconds) — Created fizzbuzz.ts with the Write tool. Code was also correct
• 3rd run (48 seconds) — Created fizzBuzz.ts and fizzBuzz.test.ts. Even wrote tests spontaneously, but there were also moments where an Invalid tool parameters error appeared and it recovered on its own

The same prompt sometimes creates a file and sometimes doesn't. Tool-calling decisions are not stable.

Task B: React Component Generation

When I explicitly said "save to a file," it was able to create Counter.tsx with the Write tool from the first run (44 seconds). A standard implementation using useState, interface, and React.FC — no issues with code quality.

It seems to be a model that's sensitive to instruction clarity: create a file when told to "save," output text when not told to.

Task C: Reading Existing Code + Modification

Results from asking it to "read and fix" the buggy utils.ts.

• 1st run — Read was successful. Discovered the average empty array issue, but missed the missing seen.add(item) in removeDuplicates. Furthermore, it refused to Edit, saying "I will not perform the code modification itself"
• 2nd run — Attempted Edit 3 times after Read but all failed with errors. Finally reported "No bugs were detected" and "seen.add(item) is being called correctly," but since the bugs remained unchanged, this was a hallucination
• 3rd run — Correctly found both the missing seen.add and the average empty array issue in a tabular analysis. However, the fix was only a text suggestion and the Edit tool was not used

Across all 3 runs, it was never able to successfully use the Edit tool. It can "read and analyze code" but cannot "execute the fix."

Task D: Project Creation + Test Execution

npx was blocked by hooks (the verification environment had npm and npx disabled) and switched to bun, then made errors with the bun:test API (using assertEquals which doesn't exist) and after 4 retries, finally passed all tests. It took 2 minutes and 37 seconds.

What's interesting is the tenacity of reading error messages and self-correcting. Without knowing the correct bun:test API (expect), it managed to reach node:assert's strict.strictEqual as a workaround.

Impressions

Code generation quality is sufficient, but tool calling is unstable. It's particularly painful that Edit never succeeded once. While it can output code when asked to "write," it struggles with "fix existing code," and I think it falls short for fully utilizing Claude Code's agent capabilities.

Verification 2: GLM-4.7-Flash

A strong candidate with SWE-bench 59.2% that also supports ollama launch.

Setup

ollama launch claude --model glm-4.7-flash-64k

Task A: FizzBuzz

It showed clearly different behavior from gpt-oss:20b.

• 1st run (4 minutes 17 seconds) — Confirmed working directory with pwd → searched files → Read utils.ts → appended FizzBuzz function with Edit → wrote a test script with Write → ran with bun run to confirm it worked
• 2nd run (3 minutes 8 seconds) — Similarly appended to existing utils.ts with Edit. This time asked the user "Can you also create a test file to verify the behavior?"

The Edit tool that never once succeeded with gpt-oss:20b worked stably from the first run. The decision to append to an existing file rather than create a new one is also more "developer-like."

However, response time is 3-4 minutes. That's considerably slower compared to gpt-oss:20b's 30-50 seconds.

Task B: React Component Generation

From the first run, it created a directory structure with mkdir -p src/components and saved src/components/Counter.tsx with Write (4 minutes 21 seconds). It also showed the care to verify its own output by reading it back after creation.

Task C: Reading Existing Code + Modification

Despite being able to use the Edit tool, it struggled with bug detection.

• 1st run — Discovered the average empty array issue, but missed the missing seen.add(item). Ended by asking the user to confirm the fix approach
• 2nd run — Succeeded with Edit twice to add a guard to average and also added a defensive fix to titleCase. However, seen.add was still missed
• 3rd run — Judged all 3 functions as "✓ Normal." Reported "duplicate removal is working correctly" even though seen.add(item) was missing

It failed to find the missing seen.add(item) in all 3 runs. The Edit tool works stably, but its weakness in detecting implicit bugs is apparent.

Task D: Project Creation + Test Execution

This was intense. It got stuck in ESM/CJS configuration hell while trying to use Jest, and after 8 retries, passed all tests in 13 minutes 59 seconds.

What was particularly interesting was the decision to abandon the test framework itself in response to a ts-node loader error. It rewrote the Jest test code with a self-made assertEquals function, then took the bold approach of building with tsc and running directly with node. There was also a moment where it noticed that fizzbuzz(0) returns "FizzBuzz" (since 0 is a multiple of 15) and corrected the test case, showing tenacity.

However, 14 minutes is too long to wait.

Impressions

The Edit tool stability is the highest among all models, and agent-like behavior (file searching, confirmation, structuring) is also rich. On the other hand, response speed is slow at 3-14 minutes, and bug detection reasoning is weak. The impression is "good technique but shallow diagnosis."

Verification 3: Qwen3-Coder-Next

In the previous article, Qwen2.5-Coder:14b was a total failure, just outputting TodoWrite JSON text as-is. For this verification I had originally planned to try the 32B version, but on February 3, 2026, Qwen3-Coder-Next was released. It achieves 70.6% on SWE-bench Verified with an 80B MoE (3B active), and Ollama support came quickly.

Setup

ollama launch claude --model qwen3-coder-next-64k

Task A: FizzBuzz

After 3 runs, there was variability in Write tool behavior.

• 1st run (3 minutes 8 seconds) — Only output code as text, no file was created. Also showed behavior of picking up custom instructions from CLAUDE.md, similar to gpt-oss:20b
• 2nd run (3 minutes 23 seconds) — Again text output only. Code quality was high, with awareness of type definitions and array reservation
• 3rd run (8 minutes 40 seconds) — Read the existing utils.ts first, then created fizzbuzz.ts with Write. Exports 3 functions, includes JSDoc — code quality is top-class among all models

Write success rate was 1 out of 3 runs. However, the quality of the code is clearly high, with awareness of type safety and documentation.

Task B: React Component Generation

• 1st run (7 minutes 33 seconds) — Created Counter.tsx with Write from the first run. 4 props via interface, min/max limits, reset button, embedded styling — 96 lines
• 2nd run (2 minutes 28 seconds) — Reverted to text output. Code quality was equivalent but no file was created
• 3rd run (2 minutes 41 seconds) — When I explicitly said "save to file," Write succeeded. 109 lines with 3 types of callbacks: onIncrement/onDecrement/onChange — a rich implementation

Task C: Reading Existing Code + Modification

Edit tool stability was good.

• 1st run (2 minutes 0 seconds) — After Read, discovered the average empty array issue and added throw Error with Edit. However, missed the missing seen.add(item)
• 2nd run (1 minute 34 seconds) — Managed to Read, but ended by asking "Which function has a problem?" Unable to find the bug on its own
• 3rd run (1 minute 14 seconds) — Discovered the average empty array issue and added return 0 with Edit. Again missed seen.add

Failed to find the missing seen.add(item) in all 3 runs. It reported "the other functions seem fine," showing the same tendency as GLM-4.7-Flash. The Edit tool works stably, but detecting implicit bugs is a weakness.

Task D: Project Creation + Test Execution

This is where Qwen3-Coder-Next showed its true strength.

After confirming the test framework via AskUserQuestion (Vitest + ES Modules), it completed directory creation → file creation → test execution in 4 minutes 17 seconds. All 4 tests passed.

Considering that GLM-4.7-Flash took 13 minutes 59 seconds and gpt-oss:120b took 3 minutes 20 seconds on a retry, reaching this point on the first try in one shot is commendable. The "confirm then execute" approach of checking the approach with the user before acting also makes a good impression as an agent.

Impressions

Handles multiple tools and completed the multi-step task in one pass on the first try. The evolution from the previous generation is clear. On the other hand, Write stability is a challenge — Task A succeeded 1 out of 3 times and Task B 2 out of 3 times, showing variability in file creation decisions. Given that code quality is top-class among all models, this is disappointing.

Verification 4: gpt-oss:120b

This is where we enter territory unique to the DGX Spark. A 120B parameter model simply cannot run on a MacBook Pro with 32GB.

Setup

ollama launch claude --model gpt-oss-120b-64k

Task A: FizzBuzz

From the first run, it appended the FizzBuzz function to utils.ts with the Edit tool (3 minutes 23 seconds). The flow of file search → Read → Edit showed the same agent-like behavior as GLM-4.7-Flash.

Given that gpt-oss:20b couldn't even Write on the first run, the effect of 6x the parameters is clear.

Task B: React Component Generation

Created Counter.tsx with Write (2 minutes 29 seconds). A standard implementation with useState, React.FC, and styling. No particular issues.

Task C: Reading Existing Code + Modification

This task produced the most interesting results in this verification.

• 1st run (1 minute 18 seconds) — Correctly found both the missing seen.add(item) and the average empty array issue. The analysis was accurate: "since seen stays empty at all times, if (!seen.has(item)) is always true." However, the fix was text suggestion only and Edit was not used
• 2nd run (1 minute 33 seconds) — Attempted Edit. The first attempt errored, but after Re-reading it succeeded in adding a guard to average. However, the seen.add fix was missed this time
• 3rd run (1 minute 43 seconds) — Found both bugs and attempted to fix both with Edit. However, there was a quality issue where seen.add(item) was added twice (seen.add(item); seen.add(item);). The intent was correct, but the execution precision needs improvement

The only model to find both bugs on the first run is a significant point. Code comprehension seems to scale with parameter count.

Task D: Project Creation + Test Execution

In the first run, it showed unexpected behavior of trying to call Claude Code's Task tool (sub-agent delegation). It tried to delegate to Opus 4.6, Sonnet 4.5, and Haiku 4.5 in sequence, but of course Task calls from a local LLM don't work, and it spun for nearly 8 minutes.

On a retry, when I told it to "implement directly," it smoothly completed the flow of mkdir → npm init → npm install → file creation → npm test in 3 minutes 20 seconds. The Jest + ts-jest configuration was also appropriate, and all 4 tests passed.

Considering that GLM-4.7-Flash took 14 minutes for the same task, it seems that the 120B model size also benefits test environment setup knowledge.

Impressions

This is the most well-balanced model among those verified this time. High bug detection capability, can use Edit, and speed is acceptable in the 1-3 minute range. However, Edit precision is not perfect, and there are also unnecessary actions like the Task delegation miss. The feeling is "quite usable, but you wouldn't want to leave it unsupervised."

Results Comparison

Model × Task Matrix

Legend: ○ Success / △ Partial success / × Failure — Claude Sonnet 4.5 is a reference value from the cloud API

Comparison by Capability

Comparison with Last Time (MacBook Pro 32GB)

Clear improvements were seen by scaling up the model size. I'll dig deeper into this in the analysis section.

Analysis

Does Tool-Calling Precision Change with Model Size?

The clearest trend that emerged from this verification is that parameter count directly correlates with tool-calling precision.

Comparing within the same gpt-oss family, Write was unstable and Edit was impossible at 20B, but at 120B both succeeded from the first run. The active parameters in MoE differ by just 3.6B → 5.1B, but the total parameter count (amount of knowledge) increasing by 6x seems to have deepened the "understanding" of how to use tools.

Qwen also completely failed at the previous 2.5-Coder:14b, but Qwen3-Coder-Next evolved significantly through MoE architecture and reinforcement learning for function calling. It completed multi-step tasks on the first run, and aside from Write stability, it's getting close to practical use.

"Finding" and "Fixing" are Different Capabilities

gpt-oss (20b / 120b) has the ability to find bugs, but struggles with the Edit tool (20b impossible, 120b precision △). On the other hand, GLM-4.7-Flash can use the Edit tool stably, but can't detect implicit bugs (missing seen.add).

"Reasoning power to understand code" and "ability to correctly operate tools" seem to be difficult to achieve simultaneously in local LLMs at this point. Since the cloud API (Claude Sonnet 4.5) handles both perfectly on the first try, the gap lies in this "simultaneous achievement."

Advantages of MoE Models

All 4 models verified this time use MoE architecture, and all succeeded at tool calling. Combined with the previous article where Dense model Qwen2.5-Coder:32b was a total failure, it seems the benefits of MoE are significant.

MoE activates only a portion of all parameters, allowing larger models to run with the same memory consumption. If you're leveraging 128GB of unified memory, loading a large model with MoE is advantageous in terms of both knowledge capacity and speed. The MoE mechanism is also touched upon in DGX Spark First Impressions.

Use Cases Where Local LLM × Claude Code Works

The situations where I felt "there are use cases" at the current stage are the following:

• Boilerplate code generation — Tasks like "create from scratch" such as FizzBuzz or React components are reasonably practical with gpt-oss:120b
• Code review-style use — Since gpt-oss:120b seems good at bug detection, asking "are there any bugs in this code?" isn't a bad use (on the premise that you fix them yourself)
• Processing sensitive code — The biggest advantage of local LLM is that source code doesn't leave the network

Conversely, there are also situations where it still feels challenging:

• Situations where you leave existing code modification to automation — Edit precision is insufficient and supervision is necessary
• Complex multi-step tasks — You can get there, but it takes too long

Summary

In the previous MacBook Pro 32GB verification, I tried up to 14B and everything failed. But with the DGX Spark's 128GB memory environment, clear improvements were seen. In particular, gpt-oss:120b has reached a level where it can handle code generation, bug detection, and multi-step tasks reasonably well.

However, there's still a gap between "usable" and "practical." Edit precision is unstable, test execution requires multiple retries, and there are moments of waiting several minutes for a response. For tasks that Claude Sonnet 4.5 handles perfectly in seconds, local LLMs currently return results that are "mostly correct" after several minutes.

If I had to choose one, I'd recommend gpt-oss:120b. With 128GB of memory, you get decent speed thanks to MoE benefits, and bug detection was the best among all models. It's a choice that only the DGX Spark can offer.

That said, local LLM evolution is fast. Just ollama launch claude in Ollama v0.15 has made setup dramatically easier, and if new models with stronger tool-calling capabilities emerge, the situation may change. If I do the same verification again six months from now, I suspect the conclusion would be different.

Reference Links

• Previous article: Tried running Claude Code locally with Ollama v0.15
• DGX Spark First Impressions
• Ollama Blog: Claude Code with Anthropic API compatibility
• Ollama Blog: ollama launch
• Ollama Tool Calling
• Claude Code Documentation
• BFCL Leaderboard
• Qwen3-Coder-Next Official Blog
• Qwen3-Coder-Next on Ollama
• Ollama Models Library