# Claude Code Goes Local: What Ollama v0.14 Means for Consultancies > How Ollama v0.14 lets you run Claude Code on-premise so client code never leaves the building, and where local models still fall short of cloud. **Type:** Breakdown · **Read time:** 7 min · **For:** Managing Partner, Delivery lead · **Published:** 9 Jun 2026 **Video companion:** https://www.youtube.com/watch?v=62SS7c7BAso [All resources](https://aigenticlab.com/resources) · [View as HTML](https://aigenticlab.com/resources/claude-code-goes-local-ollama-v014) --- ### The blocker ## Why governance teams keep saying no to AI coding tools Every time a developer uses Claude Code, your source code leaves the building. It goes to Anthropic's servers, gets processed, and comes back as a suggestion. For most software products that is a reasonable trade-off. For a consultancy handling client IP, it is a compliance problem. Tools like GitHub Copilot, Claude Code, and Cursor all work the same way: you type code, the tool sends it to a cloud API, the model processes it, and suggestions come back. The intelligence lives on someone else's server. Client contracts routinely prohibit sending code or proprietary logic to third parties, and even where contracts are silent, the risk often is not worth the productivity gain. The result is limbo. Some developers experiment, others are blocked, there is no consistent approach, and no governance team comfortable signing off. The villain is not AI itself — it is the generic cloud-first tools that were never designed for firms operating under client confidentiality obligations. ### The change ## What Ollama v0.14 actually changed Ollama is an open-source tool that lets you run large language models locally, on your own hardware. Version 0.14, released in early 2026, added Anthropic API compatibility. In practical terms, Ollama can now respond in the format Claude Code expects. Claude Code does not care whether it is talking to Anthropic's servers or a local endpoint — it just needs something that speaks the right protocol. So you can point Claude Code at a local Ollama instance, and your code never leaves your machine or your internal servers. > For consultancies, that removes the compliance blocker: governance teams can approve it because the data stays on-premise. There are no API costs beyond electricity, and the developer experience — the Claude Code interface and workflow — remains unchanged. The important caveat: you are not running Claude. You are running an open-source model through Claude Code's interface, and the capability gap matters. ### Ten-minute build ## How to set it up The setup runs to five steps and takes about ten minutes. From that point the workflow is identical to cloud Claude Code. - **Install Ollama.** Download from ollama.com for your operating system — a single terminal command on Mac and Linux, a straightforward installer on Windows. - **Pull a coding model.** Not every model handles coding well. Qwen3 Coder and GPT OSS 20B are the current recommended local options; GLM 4.7 works for Ollama's cloud models. One hard requirement: at least 32,000 tokens of context length, and a recent GPU or M-series Mac. - **Install Claude Code.** Available for Mac and Windows via a single command. If your team already uses it with Anthropic's API, this is done. - **Set the environment variables.** Two variables route requests locally rather than to Anthropic's servers. - **Run Claude Code with a model flag.** Launch with `--model` followed by your chosen local model name, and verify through the config command. The two environment variables look like this: ``` ANTHROPIC_AUTH_TOKEN=ollama ANTHROPIC_BASE_URL=localhost:11434 ``` ### The honest read ## What works and what does not Local models are useful for a specific category of coding tasks. They are not a straight replacement for cloud Claude. **What works well:** - Simple refactoring and code clean-up - Boilerplate generation — repetitive code you would copy and paste anyway - Documentation: docstrings, README files, inline comments - Straightforward test generation **Where they fall short:** - Complex multi-file changes — local models lose context and forget what they were doing earlier in the task - Subtle bugs and edge cases — open-source models at this scale are not as sharp as Claude Sonnet and will miss things - Speed — response times are noticeably slower, particularly on older hardware - The 32k context ceiling hurts on larger codebases; you cannot feed it the whole project If your team is currently using Claude Code with Claude 4 on the cloud, this will feel like a downgrade — because it is. Cloud Claude runs 200k context, with a 1 million context rollout already in progress. Local models are not competing with that. They are competing with not having AI coding assistance at all. ### Task triage ## Which tasks belong where The right question is not "local or cloud?" It is "which tasks belong where?" A simple way to map it: - **High sensitivity, straightforward tasks — use local.** Client code that cannot leave your network, where the work is contained: refactoring a function, generating documentation, writing tests for known-good logic. - **High complexity, lower sensitivity — use cloud.** Internal tools, open-source projects, anything where quality matters more than data residency. - **Mixed workload — split by task type.** Local for client-facing code, cloud for internal tooling and complex work. Document which tasks go where and make it policy, not individual judgement. This is a **Govern** decision in the 5 Steps for AI Leadership framework. Before rolling out local Claude Code, firms need a written position on which code categories require local execution, which tools are approved, and how developers should make that call. Without that policy document, you end up with the same informal patchwork you are trying to move away from. ### The bottom line ## What this means for your firm The Ollama v0.14 update removes the most common reason governance teams block AI coding tools in consultancies. The data residency problem is solved and the compliance conversation becomes much simpler. What it does not do is give you cloud-level capability on local hardware — you get governed access in exchange for reduced performance on complex work. For firms currently blocked from any AI coding assistance by data handling concerns, this is a significant unlock. For firms already running cloud Claude Code without restrictions, it adds a governed option for client-sensitive work without replacing the primary workflow. The practical move is to test it on a narrow, well-defined use case: documentation generation for a current client project, or test generation for a contained module. Measure whether the output quality is sufficient. If it is, expand. If it is not, you have a clearer picture of where local models sit in your toolset.