How to Use Cursor with Local Models via Ollama

by

Cursor supports local models through Ollama, letting you run AI-assisted coding entirely on your own hardware — no API keys, no usage costs, no data leaving your machine. The quality is lower than frontier cloud models, but for privacy-sensitive codebases, offline work, or developers who run many short coding sessions throughout the day, local models via Cursor are a practical option worth knowing how to set up.

Why Use Local Models in Cursor

The case for local models in Cursor comes down to three scenarios:

  • Privacy — codebases with proprietary algorithms, client data, or NDA-protected code that should not transit external servers
  • Cost control — Cursor’s Pro plan includes a usage limit on premium model requests; local models are unlimited once the hardware is in place
  • Offline work — reliable coding assistance on planes, in rural areas, or in air-gapped environments

Local models are not a replacement for Claude Sonnet or GPT-4o on hard tasks. They are a sensible choice when the task is routine — writing tests, adding validation, generating boilerplate — and the context above applies. Many developers use a hybrid approach: local models for the lightweight daily tasks, switching to a cloud model for complex multi-file work.

Setting Up Ollama

Install Ollama from ollama.ai. Once installed, pull a coding-optimised model suited to your hardware:

# Strong — needs 24GB VRAM (RTX 4090 or M2 Max+)
ollama pull qwen2.5-coder:32b

# Balanced — needs 16GB VRAM
ollama pull qwen2.5-coder:14b

# Lightweight — runs on 8GB VRAM or Apple M1
ollama pull qwen2.5-coder:7b

Verify Ollama is running after pulling a model:

ollama list   # shows downloaded models
ollama run qwen2.5-coder:7b   # quick test in terminal

Ollama starts a local server on localhost:11434 with an OpenAI-compatible API. Cursor connects to this endpoint without any special plugins.

Figure 1 — Local model options for Cursor by hardware tier

Hardware Recommended model Capability RTX 4090 / M2 Max 36GB+qwen2.5-coder:32bStrong — most daily tasks RTX 3080 / M1 Pro 16GBqwen2.5-coder:14bGood for routine tasks 8GB VRAM / CPU-onlyqwen2.5-coder:7bLimited — simple edits only Multi-GPU / Mac Ultradeepseek-coder-v2:236bNear-frontier quality All models run via Ollama on localhost:11434

Connecting Cursor to Ollama

Open Cursor Settings → Models. Under “OpenAI API Key”, you will see an option to add a custom base URL. Set it to:

http://localhost:11434/v1

Then add the model name as it appears in ollama list — for example qwen2.5-coder:32b. Set any placeholder value for the API key field (Cursor requires something in the field but Ollama ignores it). Save settings, then select your local model from the model picker in the chat panel.

A quick test: open a file, ask a simple question about it in the Cursor chat panel. If the response comes from your local model, you will notice it is slightly slower than cloud responses but otherwise behaves identically — the same chat interface, the same codebase context, the same ability to reference files with @.

What Works Well with Local Models

Local models through Cursor handle some tasks better than others. Tasks where they perform well:

  • Explaining what a function or class does
  • Writing unit tests for an existing function with clear inputs and outputs
  • Adding type annotations and docstrings
  • Small, self-contained refactors within a single file
  • Generating boilerplate — config files, CRUD endpoints, data models
  • Answering questions about library APIs when the model was trained on that library

Tasks where the quality gap with frontier models is most visible:

  • Complex multi-file changes that require understanding how components relate
  • Debugging subtle bugs that require reasoning about execution flow across the codebase
  • Implementing algorithms from descriptions when the implementation is non-trivial
  • Any task that requires a long context — local models typically max out at 8k–32k tokens versus 100k+ for cloud models

Cursor Composer with Local Models

Cursor’s Composer mode (Cmd+I) works with local models, but with some caveats. The agentic multi-file editing that Composer excels at requires the model to follow a specific diff format reliably. Frontier models do this consistently; local models do it most of the time but occasionally produce malformed edits that Cursor cannot apply. When this happens, Composer shows an error and you can retry or switch to a cloud model for that specific task.

For Composer tasks with local models, keep the scope tighter than you would with a cloud model — one file at a time is more reliable than asking for changes across five files simultaneously. As local model quality improves (and it has improved rapidly — the Qwen2.5-Coder series is significantly better than what was available twelve months earlier), this limitation becomes less constraining.

Performance on Different Hardware

Inference speed varies significantly by hardware. Rough benchmarks for Qwen2.5-Coder:32b at 4-bit quantisation:

  • RTX 4090 (24GB): ~20–25 tokens/sec — responsive for coding tasks
  • M2 Max (36GB unified memory): ~18–22 tokens/sec — comparable to GPU
  • M3 Ultra (192GB unified memory): ~40+ tokens/sec — faster than most cloud API responses
  • CPU only (modern desktop): ~2–5 tokens/sec — usable but slow for longer generations

For the 7B model, roughly double these numbers. For the 14B model, numbers sit between 7B and 32B depending on the specific hardware configuration.

Keeping Ollama Models Updated

Local model families release new versions regularly. Qwen2.5-Coder replaced Qwen2-Coder, which replaced Qwen-Coder, with meaningful quality improvements at each generation. Check the Ollama model library periodically for newer versions:

ollama pull qwen2.5-coder:32b   # re-pulls latest version of the tag

When a significantly better model is released — as happens every few months in the fast-moving local model space — pulling it and updating the model name in Cursor settings is all that is needed to upgrade. No configuration changes, no new API keys, no subscription updates. This upgrade path is one of the practical advantages of local models: improvements in the open-source model ecosystem translate directly into better Cursor performance with no friction.

Running Cursor with local models via Ollama is a genuinely useful setup for the right situations. It is not a replacement for cloud models on hard tasks, but for the substantial fraction of coding work that is routine, well-defined, and better kept private, a well-chosen local model running through Cursor’s familiar interface is productive and cost-free to run.

Context Window Discipline with Local Models

The most important practical adjustment when switching from cloud to local models in Cursor is context window discipline. Cloud models like Claude Sonnet operate with 100k–200k token context windows, which means Cursor’s codebase indexing can pull in large amounts of relevant code without hitting limits. Local models typically cap at 8k–32k tokens depending on how they are configured in Ollama. In practice this means you need to be more selective about which files you reference with @ in the chat panel.

A few habits that help: reference specific functions or classes rather than entire files when possible (“@auth.py line 45-80” rather than “@auth.py”). Close files in the editor that are not relevant to the current task, since Cursor sometimes includes open files in context automatically. If Cursor reports that a response was cut off or the model lost context, drop some file references and try again with a narrower scope. These habits are good practice regardless of model, but they become essential rather than optional when working with local models’ smaller context budgets.

Security Considerations for Local Deployment

Running Ollama locally means the model server is accessible on localhost. This is secure by default — only processes on your machine can reach port 11434. However, if you are on a shared network or if you ever run Ollama with network binding enabled (for example to serve models to other machines on your LAN), ensure appropriate firewall rules are in place. Ollama itself has no authentication — any client that can reach the port can make requests. For personal local use, the default localhost binding is fine. For team deployments where multiple developers share a model server, add a reverse proxy with authentication in front of Ollama rather than exposing it directly. This is a non-issue for the typical solo developer use case but worth being aware of before opening the port on a corporate network.

Mixing Local and Cloud in One Project

Cursor makes it easy to switch models mid-session from the model picker in the chat panel. A practical hybrid workflow for a typical development day: start the morning with a local model for the straightforward tasks that will fill most of the session — adding tests, updating documentation, small bug fixes, code review questions. When you hit a genuinely complex task — a multi-file refactor, a tricky debugging session, a new feature requiring significant design thinking — switch to Claude Sonnet or GPT-4o for that specific conversation. Switch back to local when the hard task is done. This approach keeps API costs for the day to just the complex tasks where frontier model quality genuinely matters, while maintaining AI assistance for the full day’s work.

The local model landscape improves faster than almost any other area of AI development — a model that was the best option six months ago may have been superseded by something meaningfully better today. Checking the Ollama model library every month or two and re-running your own test tasks on newer models is a low-effort way to stay current. The switching cost is a single pull command, and the quality improvements across model generations have been substantial enough that regular upgrades consistently produce noticeably better coding assistance without any change to your Cursor workflow.

Leave a Comment