Claude Code is built to talk Anthropic’s /v1/messages API; routing it at a local Ollama model takes a bridge that translates between the Anthropic Messages format and Ollama’s OpenAI-compatible endpoint, and the open-weight coding models that hold up behind that bridge today are a short list. The most useful picks are Qwen3-Coder-30B-A3B-Instruct for a 24 GB card and Devstral Small 2 24B Instruct 2512 for a 16 GB card; Qwen3-Coder-Next is the largest single-card frontier pick and KAT-Coder-V2.5-Dev is the strongest-scoring option outside the Qwen family on its own card. Anthropic explicitly states the configuration is unsupported.
The local-routing gap
Claude Code’s official sources describe an Anthropic-format endpoint served at /v1/messages. The compatibility guide states that “a gateway must expose at least one of the following API formats to Claude Code clients,” with the Anthropic Messages row read by ANTHROPIC_BASE_URL pointing at /v1/messages and the optional /v1/messages/count_tokens. Ollama serves a different contract: /v1/chat/completions, OpenAI’s wire format, with /v1/models and /v1/embeddings alongside it. The two endpoints do not speak the same protocol, so nothing works until a gateway in front of Ollama speaks the Anthropic one.
The “Other LLM gateways” page is more direct: “Anthropic doesn’t endorse, maintain, or audit third-party gateway products, and doesn’t support routing Claude Code to non-Claude models through any gateway.” That means a translation layer is required, the user is on their own when an anthropic-beta value or a streaming event is dropped, and “this configuration works today” is the most that can be claimed. Tools through /v1/chat/completions are in Ollama’s supported-field set, but tool_choice, n, logit_bias, and user are not.
The implication for the rest of the article: every model recommendation below assumes a translation gateway in front of the Ollama endpoint - the open-source @musistudio/claude-code-router mentioned on the Qwen3-Coder blog, or an equivalent Anthropic-format bridge - and every feature is conditional on that bridge passing through the Anthropic Messages betas Claude Code sends today.
The shortlist
Six open-weight coding models shipped in 2025-2026 carry the necessary mix of long context, agentic tool training, and a licence that allows the configuration. The table ranks them by Ollama default tag size, the smallest HF safetensors total I could measure on the API, and the SWE-bench Verified score on each model’s own card.
| Use case | Model | Ollama default tag | HF params (total / active) | Licence | SWE-bench Verified |
|---|---|---|---|---|---|
| 24 GB consumer card | Qwen3-Coder-30B-A3B-Instruct | qwen3-coder:30b (19 GB) | 30.5B / 3.3B | Apache 2.0 | not on card |
| 16 GB card | Devstral Small 2 24B Instruct 2512 | devstral:24b (14 GB) | 24B dense (~24.01 GB safetensors) | Apache 2.0 | 68.0 |
| Alternative 24 GB tier | KAT-Coder-V2.5-Dev | (no Ollama tag) | 35B / 3B active | Apache 2.0 | 69.40 |
| Open-licence 24 GB tier | GLM-4.7-Flash | glm-4.7-flash (19 GB) | 30B / 3B active | MIT | 59.2 |
| Frontier single-card | Qwen3-Coder-Next | qwen3-coder-next (52 GB) | 80B / 3B active (~79.7 GB safetensors) | Apache 2.0 | not on card |
| Frontier multi-card | Qwen3-Coder-480B-A35B | qwen3-coder:480b (290 GB) | 480B / 35B active | Apache 2.0 | not on card |
The Ollama library tags are the published Q4_K_M default: 19 GB for the 30B-A3B, 14 GB for Devstral Small 2 24B (the devstral:latest tag points at the same 24B Instruct 2512 weights), 19 GB for GLM-4.7-Flash, 52 GB for Qwen3-Coder-Next, 290 GB for the 480B frontier. Ollama has not published a tag for KAT-Coder; that one needs Hugging Face safetensors converted to GGUF or served through vLLM, which a gateway can reach the same way.
Qwen3-Coder-Next is the largest single-card option in the list. Its card lists “Claude Code, Qwen Code, Qoder, Kilo, Trae, Cline” explicitly under CLI/IDE integrations, and publishes 80B total with 3B activated and 262,144 native tokens - but it carries no benchmark table in text. The results sit in images on the card, which points readers to the Qwen blog for evaluation detail, so its SWE-bench column is marked “not on card” here rather than guessed at. Devstral Small 2 24B Instruct 2512’s card lists Claude Code as a “supported scaffolding framework” alongside other harness names; KAT-Coder-V2.5-Dev’s card names Claude Code 2.1.195 as the harness used to evaluate SWE-bench. None of these mention implies Anthropic endorsement; the previous section’s caveat holds for all of them.
How the bridge goes together
Two pieces of plumbing are required. The first is Ollama itself, listening on http://localhost:11434/v1/chat/completions after ollama serve runs. The second is a translation gateway that exposes the Anthropic Messages format at the URL Claude Code reads from ANTHROPIC_BASE_URL. The gateway needs four things:
- Accept
/v1/messagesrequests with the Anthropic body and header set, includinganthropic-betavalues andsystemarrays with their cache markers. - Translate them into OpenAI-style
/v1/chat/completionscalls that include the model’s tool schema undertools(the field Ollama documents as supported). - Translate streaming Anthropic SSE back to OpenAI-format SSE, including a
pingevent when the upstream is quiet, because “Claude Code aborts a streaming response once no bytes reach it for longer than its streaming idle timeout” and a quiet thinking pause otherwise trips the watchdog. - Alias the underlying model id through a name that contains
claudeoranthropic. The picker filter on the gateway’s/v1/modelsresponse keeps only entries because “Claude Code keeps an entry when itsidcontainsclaudeoranthropicanywhere in the string, matched case-insensitively.”
@musistudio/claude-code-router is the open-source project the community uses for this bridge; the Qwen3-Coder blog documents it as @musistudio/claude-code-router alongside Alibaba Cloud’s hosted claude-code-proxy endpoint. The hosted endpoint is a paid Alibaba service, not a self-hosted replacement. The blog quotes Alibaba’s documented flow as “you can now use Qwen3-Coder with Claude Code” and “Then you should be able to use Claude Code with Qwen3-Coder!” - both directed at the hosted DashScope proxy, not at a local Ollama process.
Cline’s OpenAI-compatible path uses qwen3-coder-plus as the configured model name and points at DashScope; swapping Ollama in requires pointing Cline (or the same Ollama OpenAI base URL through Claude Code Router) at the local 11434 endpoint instead.
What holds up, and what doesn’t
Three patterns are stable across the recommended models.
Long context for repository-scale work. Qwen3-Coder-30B-A3B-Instruct publishes 262,144 native tokens on its card; Qwen3-Coder-Next publishes the same number; KAT-Coder-V2.5-Dev supports 262,144 natively and recommends YaRN or other RoPE scaling past that limit; Devstral Small 2 24B Instruct 2512 is 256K, and the Ollama tag for GLM-4.7-Flash is published at 198K. Claude Code’s session keeps a growing conversation history; a 32K-context model loses the trailing file contents on a real multi-file refactor.
Tool-call training. Qwen3-Coder-30B-A3B-Instruct’s card states “most platform such as Qwen Code, CLINE” for agentic coding support; Qwen3-Coder-Next lists six CLI/IDE integrations by name; Devstral Small 2 is described on its card as “designed to excel at agentic coding tasks, making it a great choice for software engineering agents.” A general chat model without explicit tool-call training tends to forget the tool schema mid-conversation.
Permissive licence. Apache 2.0 covers four of the five picks (Qwen3-Coder-30B-A3B, Qwen3-Coder-Next, Devstral Small 2 24B Instruct 2512, KAT-Coder-V2.5-Dev) and MIT covers GLM-4.7-Flash. None of the licences in the table prohibit commercial use at the figures cited.
Three things don’t necessarily hold up.
Force-tool selection. Ollama’s /v1/chat/completions documentation lists tools as supported but does not list tool_choice. Claude Code’s “tool must be invoked” prompts degrade gracefully because the model can still emit the tool call, but patterns that depend on tool_choice: required are not preserved through the supported-field set.
Sub-agent features. Claude Code’s auto-mode classifier, the advisor tool, and beta context-management fields may reject behind an OpenAI-format gateway that does not forward their paired anthropic-beta values; behaviour is version-dependent, and breaking the pairing produces a 400 with “Extra inputs are not permitted” per the protocol guide.
Cost visibility. Because Ollama’s gateway model discovery only keeps entries whose id contains claude or anthropic, the picker shows my-alias-claude-sonnet-4-6 rather than qwen3-coder:30b. The aliases work; raw Ollama tag ids do not appear.
Bottom line
For a 24 GB consumer card the working configuration today is qwen3-coder:30b behind a translation gateway, with the gateway aliasing the model id to a string that contains claude or anthropic so it shows up in the picker. For a 16 GB card the same pattern works with devstral:24b (14 GB Q4_K_M, Apache 2.0, SWE-bench Verified 68.0). For a 64 GB+ card qwen3-coder-next (52 GB Q4_K_M, Apache 2.0, 80B total with 3B activated, 262,144 native tokens) is the largest single-card option on the list; KAT-Coder-V2.5-Dev at 35B/3B (Apache 2.0, SWE-bench Verified 69.40) is a viable alternative outside the Qwen family, though it has no Ollama tag. GLM-4.7-Flash adds an MIT option at the same MoE footprint, fits the 24 GB tier at 19 GB, and scores lower on the card’s SWE-bench number (59.2). Anthropic does not support any of this; the pipeline’s stability depends on the gateway forwarding Anthropic-beta values and SSE pings correctly, and tool_choice-dependent patterns are not preserved through Ollama’s supported fields. The economic case still depends on the local AI vs API cost crossover, and the broader coding-model landscape is on the VRAM tier guide.