Private AI coding with Cline and Zed

Most AI coding assistance ships your code to someone else’s server. That’s fine for a side project and a hard no for a lot of real work. The alternative is to run the model yourself: a local model behind Ollama, driven by a tool that lives in your editor. Your source never leaves the machine, and there’s no per-token bill.

I’ve written before about the private setup in the abstract. This post is the concrete, currently-maintained version: the same local engine, paired with two tools I’d actually recommend today. Cline if you want an agent inside VS Code, and Zed if you’d rather have the assistant built into a faster editor.

Why local at all?

#

Two reasons, and neither is going away:

• Privacy. Proprietary code never transits a third-party API. Under an NDA, a compliance regime, or an internal IP policy, “the data never left the machine” is a much shorter conversation than a vendor data-processing review.
• No marginal cost. No per-token bill, no rate limits, no monthly cap to defend at the next budget review. Once the hardware is paid for, inference is free.

The tradeoff is that you supply the compute. A capable coding model wants real RAM and ideally a GPU. That is the whole cost of admission.

The engine: Ollama plus a local model

#

Both tools below talk to the same thing, so set this up first. Ollama is the runtime: it pulls models, runs them, and exposes a local endpoint.

On macOS I install it via Homebrew:

brew install ollama
brew services start ollama

Or grab the installer from the Ollama site. Then pull a model. A practical starting pair is one general model for chat and edits and a smaller one for fast autocomplete:

# chat and inline edits
ollama run llama3.1

# faster autocomplete
ollama run qwen2.5-coder:1.5b

If your hardware has more headroom, the coding-focused open models have come a long way. Families like Qwen3-Coder and Devstral run a credible autonomous coding loop on a single modern GPU, still fully local. Start small, confirm the workflow, then size up.

Ollama serves on http://127.0.0.1:11434. Everything below points at that address.

Cline: an agent inside VS Code

#

Cline is an open-source extension that turns VS Code into an agentic coding environment. It plans a change, edits files, runs commands, and shows you each step for approval. It’s actively maintained and one of the most-used coding agents going right now, which is exactly what you want in the tool you’re standardizing on.

The setup shape:

1. Install the Cline extension from the VS Code marketplace.
2. In its settings, choose Ollama as the API provider.
3. Point it at http://127.0.0.1:11434 and select the model you pulled above.

That’s it. From there Cline works against your local model with no key and no cloud. For an agent that reads and writes across your project, keeping it local is the difference between “handy” and “allowed at work.” Cline’s own Ollama guide has the current provider settings if the menu has shifted.

Zed: the assistant built into the editor

#

If you’d rather not bolt an agent onto VS Code, Zed is the other direction: a fast, Rust-based editor with AI assistance built in, and native support for Ollama as a model provider. I have a full Zed setup guide that covers installation and configuration; the local-AI part is a matter of adding Ollama as a provider in the assistant settings and picking your model.

Zed suits you if speed is the priority and you like the assistant living in the editor rather than as an extension you manage. Cline suits you if you want a more autonomous agent that drives multi-step changes. Both keep the code on your machine, which is the point.

Which to pick

#

• Reach for Cline when you want an agent that plans and executes multi-step edits inside a familiar VS Code setup.
• Reach for Zed when you want a fast editor with the assistant native, and less extension overhead.

You are not locked in either way. The engine underneath is the same Ollama endpoint, so switching tools costs you nothing you can’t redo in a few minutes. That is the whole reason to keep the editor layer loose: tools come and go, but a local model you own outlives all of them.

Performance considerations

#

Running models locally is resource-intensive. A few levers:

• Model size. Pick a model that fits your RAM and GPU. A smaller coder model that answers instantly beats a larger one that stalls your editor.
• Context window. Trimming context or batching requests helps on constrained hardware.
• Hardware. More RAM, or a GPU-accelerated build (CUDA or ROCm), is the single biggest speedup. If you do this daily, it pays for itself.

Resources

#

• Ollama and the Ollama GitHub
• Cline
• My Zed editor setup guide