Worth being precise about what shipped here, because the headlines make it sound like an Anthropic feature and it isn’t. Ollama v0.33.0 (released around Aug 21-22, 2026) added a toggle that routes Claude Desktop’s model calls to locally-running (or Ollama-cloud) open models — Qwen, DeepSeek, Kimi, and friends. It’s not an MCP server, and Anthropic didn’t build it. Ollama built a dedicated local proxy that impersonates a “third-party gateway” Claude Desktop already knew how to talk to, specifically to route around Claude Desktop’s outright rejection of non-Anthropic model IDs — a wall that killed Ollama’s first attempt at this integration months earlier. Understanding that the plumbing lives entirely on Ollama’s side matters, because it tells you where to look when something breaks (spoiler: it already has).
How you actually turn it on
The whole thing is UI-driven, which is the right call for adoption but worth walking through once: open the Ollama desktop app, go to Apps, toggle Claude on. Ollama auto-configures Claude Desktop’s gateway setting behind the scenes — no manual JSON editing, no config file surgery. Then in Claude Desktop’s own settings you pick which local model to route to, restart, and you’re talking to a model running entirely on your machine (or Ollama’s cloud tier, for the models too large to run locally) from inside Claude Desktop’s UI. There’s a menu-bar control on Mac for switching a given conversation between local and cloud Claude on the fly. To back out, either flip the toggle off or run ollama launch claude-desktop --restore. It’s desktop-only for now — Claude Code CLI isn’t wired into this — and Windows support is “forthcoming,” so if you’re on Windows this is a wait-and-see item, not a today item.
What models you actually get
The supported lineup as of this release: Qwen (qwen3, qwen3.5, qwen3.8:27b at roughly 18GB in Q4_K_M quantization with a 256K context window, qwen2.5-coder, qwen3-coder:30b), DeepSeek (deepseek-r1 runs locally; deepseek-v4-flash is cloud-only, 1M token context, 284B total params with only 13B active per token via MoE routing), and Kimi (kimi-k2.6, cloud-only, 256K context, multimodal). GLM-5.2 gets mentioned in Ollama’s broader release notes but isn’t clearly confirmed as wired into this specific Claude Desktop integration — I’d verify against your local Ollama model list before assuming it shows up in the picker.
The tradeoffs, with actual numbers
This is the part that matters for deciding whether to use it beyond novelty. Local inference on consumer hardware clocks in around 15-25 tokens/sec, versus 60-80+ tokens/sec for cloud Claude — noticeably slower but not painful for a single response. Latency is the bigger gap: 10-60 seconds for local generation versus 2-5 seconds cloud, which changes how it feels to use, especially mid-conversation. Tool-calling reliability is the number I’d actually watch if you’re planning to delegate real work: open models land around 85-90% reliability on routine coding tasks compared to cloud Claude, and that gap widens meaningfully on complex multi-step tasks, large refactors, and error recovery — exactly the scenarios where you want an agent you don’t have to babysit. Some feature gaps show up too: Connectors and web search were reported unavailable in certain local-model configurations at launch.
On the upside: Ollama states a strict Zero Data Retention policy with telemetry disabled by default, which is the actual reason to reach for this over cloud Claude for a chunk of your work — not speed, privacy and cost. No API spend for anything routed locally, works offline/air-gapped, and satisfies data-residency requirements that cloud API calls can’t.
A live bug worth knowing about before you demo this to your team
GitHub issue ollama/ollama#15992 documents Claude Desktop’s Cowork feature correctly discovering 39 models from Ollama’s gateway /v1/models endpoint, then reporting “0 usable models” and silently falling back to a hardcoded “Legacy Model” (claude-sonnet-4-6) — with no error surfaced to the user. If you flip this on and Claude Desktop seems to just ignore your model selection, check whether you’re actually still talking to cloud Claude before assuming your local setup is broken. This is the kind of failure mode that erodes trust fast if a team hits it without knowing it’s a known issue.
Where this actually earns a spot in a workflow
My honest read: this is a good default for task-based routing, not a cloud-Claude replacement. Use a local Qwen or DeepSeek model for routine, low-stakes work — boilerplate, quick lookups, anything where a wrong tool call just means you retry — and keep cloud Claude for the multi-step refactors and anything touching customer data you don’t want leaving your machine anyway. The single-UI toggle is genuinely the useful part here; asking an engineer to context-switch between two separate apps for “cheap task” vs. “hard task” is friction nobody sustains. Just don’t roll this out to a team expecting local models to match cloud Claude on complex agentic work yet — the tool-calling reliability numbers say it isn’t there, and the silent-fallback bug means your first “why isn’t this using my local model” ticket is probably already filed somewhere.
Sources: The New Stack — Ollama’s Claude Desktop integration, Ollama Blog, Ollama Docs