I tried running Claude Code locally with Ollama v0.15

Introduction

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

With the release of Ollama v0.15 on January 23, 2026, the ollama launch claude command was added. This makes it very easy to set up Claude Code to run on local models. I was excited and tested it with the expectation that "maybe we can finally use Claude Code with a local LLM," but to get straight to the point, it was not practical at this time.

In this article, I'll share the actual results I tested and why it didn't work well. I hope this saves time for anyone who is trying to do the same thing.

Ollama's Claude Code Support

Anthropic API Compatibility Mode Added in v0.14.0

With Ollama v0.14.0 released on January 12, 2026, a /v1/messages endpoint compatible with the Anthropic API was added. By setting environment variables, Claude Code can connect to local Ollama.

# Traditional method (v0.14.0 and later)
export ANTHROPIC_BASE_URL=http://localhost:11434
export ANTHROPIC_API_KEY=ollama
export ANTHROPIC_MODEL=qwen2.5-coder:1.5b

ollama launch Command Added in v0.15

In v0.15, the ollama launch claude command was added, eliminating the need to set environment variables.

# Simple method for v0.15 and later
ollama launch claude

# When specifying a model
ollama launch claude --model qwen2.5-coder:1.5b

When executed, "Launching Claude Code with {model}..." is displayed, and Claude Code launches with environment variables automatically configured. If no model is specified, one is automatically selected from available models.

What I Expected

• A code agent usable with zero API costs
• An environment where sensitive code is not sent externally
• The ability to develop in offline environments

Test Environment

• MacBook Pro (M4 32GB)
• macOS 26.2
• Ollama v0.15.1 (tested on January 25, 2026)
• Claude Code v2.1.15
• Test models:
  • qwen2.5-coder:1.5b (986 MB)
  • gemma3:4b (3.3 GB)
  • llama3.1:8b (4.9 GB)
  • qwen2.5-coder:14b (9.0 GB)

Test Results

The API Endpoint Itself Works

First, Ollama's Anthropic API-compatible endpoint worked correctly.

const response = await fetch('http://localhost:11434/v1/messages', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json', 'x-api-key': 'ollama' },
  body: JSON.stringify({
    model: 'qwen2.5-coder:1.5b',
    max_tokens: 100,
    messages: [{ role: 'user', content: 'Say hello in TypeScript' }],
  }),
});
// → Response returned normally

Code generation with Ollama alone is also fine.

ollama run qwen2.5-coder:1.5b --verbose
# → Operates at 78 tokens/sec, code generation is good

Problems Occur When Connecting with Claude Code

However, various problems occurred when connecting with Claude Code.

Problem 1: Misinterpreting Ambiguous Instructions (qwen2.5-coder:1.5b)

❯ Write FizzBuzz
⏺ The 10th FizzBuzz is 15.

In response to the instruction "write code," it returned a calculation result. When I explicitly instructed "write FizzBuzz code in TypeScript," it succeeded, but that's different from how Claude Code is naturally used.

For clear instructions like "write a simple counter component in React with TypeScript," it was able to generate correct code.

❯ Write a simple counter component in React with TypeScript

⏺ import React from 'react';

  const Counter: React.FC = () => {
    const [count, setCount] = React.useState(0);
    return (
      <div>
        <p>Count: {count}</p>
        <button onClick={() => setCount(count + 1)}>Increment</button>
        <button onClick={() => setCount(count - 1)}>Decrement</button>
      </div>
    );
  };

  export default Counter;

  This Counter component works as follows:
  1. Displays the current count
  2. Clicking the video increases the count  ← ?
  3. Clicking the magic button decreases the count  ← ?

  This component is implemented in TypeScript and uses React's useState and useEffect
  Hooks.  ← useEffect is not used

The code itself is correct, but the explanation contains hallucinations that contradict the actual code, such as "video," "magic button," and "uses useEffect." Even if code can be written, attention must be paid to the reliability of explanations.

Problem 2: API Error Due to Native Tool Non-Support (gemma3:4b)

❯ Write a simple counter component in React with TypeScript
⏺ API Error: 400 {"error":{"message":"gemma3:4b does not support tools"}}

Claude Code tries to use tools for file operations, etc., but gemma3:4b does not support native tool calls (function calling), resulting in an error. There is a possibility of handling this with custom prompt templates, but it cannot be used as-is with Claude Code.

Problem 3: Confused by System Prompts (llama3.1:8b)

llama3.1:8b supports tool calls, but a different problem occurred.

In an environment with a complex CLAUDE.md (such as character settings), there were cases where asking for a "counter" generated a "TodoList," or it started explaining the contents of CLAUDE.md settings.

With CLAUDE.md removed, code generation itself was possible.

❯ Write a simple counter component in React with TypeScript

⏺ import React from 'react';

  interface CounterProps {
    initialCount: number;
  }

  const Counter = ({ initialCount }: CounterProps) => {
    const [count, setCount] = React.useState(initialCount);
    return (
        Count: {count}
        <button onClick={() => setCount(count + 1)}>+1
    );
  };

  export default Counter;

✻ Cooked for 34s

Structured code including Props definitions was generated, but the JSX was incomplete (tags not closed), and processing took 34 seconds. Even with an 8B model, it might work if CLAUDE.md is simple, but there are issues with output quality and speed.

Problem 4: Tool Calls Output as JSON Text

There were also cases where tool calls were not executed and the JSON was output as-is.

❯ Write a simple counter component in React with TypeScript
⏺ {
    "name": "TodoWrite",
    "arguments": {
      "componentName": "Counter",
      "language": "TypeScript"
    }
  }

No file was actually created; only the JSON of the tool call was displayed. Moreover, "TodoWrite" is a task management tool in Claude Code and is not used for code generation. Small models "recognize" Claude Code's tool definitions but are unable to select and execute the correct tool.

Even with the same prompt, code is sometimes output, and the results are unstable and not reproducible.

Additional Testing: No Improvement with 14B Model (qwen2.5-coder:14b)

I also tested with the 14B model in hopes that "a larger model might work."

❯ Write a simple counter component in React with TypeScript

⏺ {
    "name": "TodoWrite",
    "arguments": {
      "todoList": [
        { "task": "Create a new React component file named `Counter.tsx`" },
        { "task": "Define the initial state for the counter..." },
        ...
      ]
    }
  }

✻ Cogitated for 57s

The same problem occurred with 14B as well. Instead of writing code, it tried to create a task list, and the tool call was output as JSON text. Processing time was also slow at 57 seconds, and increasing the model size did not resolve the integration issues with Claude Code.

Test Results Summary

Current Conclusion

Claude Code + local models are not practical at this time.

Why It Doesn't Work

1. Claude Code is designed on the premise of complex system prompts and tool calls. Since tool definitions alone use approximately 11,000 tokens worth of context, small models of 8B or less cannot correctly process this enormous context.
2. Many local models do not support tool calls (function calling), or their support is incomplete.

Hopes for the Future

What Can Be Expected in the Short Term

• There is a possibility of improvement with 30B–70B class models, but given that problems were not resolved even with 14B, expectations are low (needs further testing)
• Tools like Continue.dev that use simpler system prompts (around 6.5K) might be practical

What Can Be Expected in the Medium to Long Term

• Optimization of Claude Code for local models
• Improvement of small model tool-calling capabilities

If You Still Want to Use Local LLM

While integration with Claude Code is difficult, code generation with Ollama alone is sufficiently practical.

# Simple code generation
ollama run qwen2.5-coder:1.5b "Write an email validation function in TypeScript"

# Actual measurements (M4)
# - Generation: 78 tokens/sec
# - Quality: Practical code with type annotations

For use cases like asking questions directly from the terminal or calling the API from a custom script, local models are fully usable.

Summary

Ollama v0.14.0's Anthropic API compatibility mode works technically, but reproducing the full functionality of Claude Code with local models is currently difficult.

If your goal is to "get a Claude Code-equivalent experience locally," you might want to consider the following instead.

1. Running 30B–70B models in a GPU environment such as NVIDIA DGX Spark (needs testing)
2. Limiting to simple code completion with Continue.dev
3. Using Ollama alone from the terminal

I hope this article serves as a reference for those who are trying to do the same testing.

Reference Links

• Ollama Blog: ollama launch
• Ollama Anthropic Compatibility
• Ollama Blog: Claude Code with Anthropic API compatibility
• Ollama Tool Calling