Guide · 2026-07-22

How to Use a Local Ollama LLM as Cursor's Backend

Last updated 2026-07-22

Cursor can run on your own Ollama models, but only if you understand the one architectural catch that breaks every naive localhost setup.

By Mohamed Meguedmi · 9 min read

The one thing you must understand before you start

Almost every failed "Ollama in Cursor" attempt dies on the same misconception: that Cursor talks to your model directly. It does not. When you set a custom OpenAI-compatible base URL, Cursor still routes the request through its own backend servers, which then call the URL you provided. That server has no idea what http://localhost:11434 means on your machine.

This single fact dictates the entire setup. To make a local Ollama model work as Cursor's backend, you must give Cursor a URL that is reachable from the public internet. In practice that means running a secure tunnel from a service back to the Ollama server on your machine. Skip this and the Verify button will fail every time, no matter how correct your model name is.

Verdict up front: if you need Cursor's full agentic experience with zero friction, keep using its hosted models. Choose the local Ollama route when data residency, air-gapped-adjacent workflows, or per-seat API cost are the deciding factors — and accept a reduced feature set as the price.

Prerequisites and hardware reality check

A local coding model is only useful if it fits in VRAM and still leaves room for a usable context window. Undersized hardware forces heavy quantization or CPU offload, and a 32B model crawling at 3 tokens/second makes Cursor feel broken rather than private.

Model (GGUF)	Quant	Approx VRAM	Realistic min GPU	Best role
Qwen2.5-Coder 7B	Q4_K_M	~6 GB	RTX 3060 12GB	Cmd+K quick edits
DeepSeek-Coder-V2 16B Lite	Q4_K_M	~10 GB	RTX 4070 12GB	Balanced chat
Codestral 22B	Q4_K_M	~13 GB	RTX 4080 16GB	Chat + refactor
Qwen3-Coder 30B A3B	Q4_K_M	~19 GB	RTX 4090 24GB	Fast MoE chat
Qwen2.5-Coder 32B	Q4_K_M	~20 GB	RTX 4090 24GB	Best overall quality

VRAM figures assume a modest context; raising num_ctx to 32K adds several gigabytes of KV cache on top. On a 24 GB card, a 32B Q4_K_M model with 16K context is comfortable; 32K context starts to squeeze. For deeper VRAM math across quant levels, see our benchmarks hub and the cost calculator.

Step-by-step: wiring Ollama into Cursor

1. Install Ollama. Download it from ollama.com/download and confirm it runs with ollama --version. Ollama exposes an OpenAI-compatible API at /v1 automatically.
2. Pull a coding model. Start with the recommended default:

   ollama pull qwen2.5-coder:32b

   Model details and tags are listed on the Ollama library page.
3. Expand the context window with a Modelfile. This is the step most guides skip. Create a file named Modelfile:

   FROM qwen2.5-coder:32b
   PARAMETER num_ctx 16384

   Then build the enlarged variant:

   ollama create qwen-coder-16k -f Modelfile

   Remember the name qwen-coder-16k — Cursor must reference it exactly.
4. Expose the endpoint publicly. Because Cursor calls your URL from its cloud, tunnel port 11434. With ngrok:

   ngrok http 11434

   Copy the generated HTTPS forwarding URL (for example https://ab12cd34.ngrok-free.app). A Cloudflare Tunnel is the more durable alternative for a persistent setup.
5. Configure Cursor. Open Settings → Models. Add a custom model whose name exactly matches qwen-coder-16k. Under the OpenAI API section, set the Base URL to your tunnel URL with the /v1 suffix (e.g. https://ab12cd34.ngrok-free.app/v1) and enter any non-empty string as the API key — Ollama ignores it, but Cursor requires the field.
6. Deselect every hosted model. Before verifying, uncheck all of Cursor's default models so only your local model remains enabled. Cursor's Verify step tests against the OpenAI provider, and leaving hosted models selected causes confusing failures.
7. Verify and use. Click Verify. On success, open Chat (Ctrl/Cmd + L) or Cmd+K and your prompt now runs entirely on the local model.

What actually works — and what doesn't

Setting a local backend does not give you a full local Cursor. The proprietary features that make Cursor feel magical are the ones you lose. Be clear-eyed about the trade before committing.

Feature	Local Ollama model?	Notes
Chat (Ctrl/Cmd+L)	Yes	Full quality of your chosen model
Cmd+K inline edit	Yes	Works well with 7B-32B coders
Tab autocomplete	No	Uses Cursor's proprietary model only
Agent / Composer multi-file	Partial / unreliable	Depends on tool-call fidelity of the model
Codebase indexing (@codebase)	Limited	Embeddings still handled server-side

The Cursor community has repeatedly flagged that Tab autocomplete cannot be redirected to a local model, and that the custom-model path targets Chat and inline editing. If Tab-style completion is your priority, an extension-based flow (VS Code with a local-first assistant) is a better architectural fit than forcing Cursor into that role.

Best local models for a Cursor backend in 2026

Model choice matters more than any config tweak. The numbers below are indicative HumanEval-class pass rates for the quantized GGUF builds people actually run locally — treat them as a ranking signal, not lab-precise figures. Full methodology is on our methodology page.

Model	Params	Indicative HumanEval	Tokens/s (RTX 4090, Q4_K_M)	Editor's take
Qwen2.5-Coder 32B	32B dense	~92%	~28	Best quality that fits 24 GB
Qwen3-Coder 30B A3B	30B MoE (3B active)	~90%	~55	Near-32B quality, roughly 2x faster
Codestral 22B	22B dense	~81%	~38	Strong FIM, lighter VRAM
DeepSeek-Coder-V2 16B Lite	16B MoE	~81%	~60	Great value on 12 GB cards
Qwen2.5-Coder 7B	7B dense	~88%	~90	Snappy Cmd+K on modest GPUs

Our recommendation is unambiguous: on a 24 GB GPU, run Qwen2.5-Coder 32B Q4_K_M for the highest-quality Chat, and keep Qwen2.5-Coder 7B Q4_K_M loaded for latency-sensitive Cmd+K edits. If token speed frustrates you, switch the heavy slot to the MoE Qwen3-Coder 30B A3B. You can see how these rank against hosted options in the model catalog. Model cards for the Qwen coders are published on Hugging Face.

Performance tuning that actually moves the needle

• Preload the model. Cold starts on a 32B model add seconds of latency per session. Keep it warm with OLLAMA_KEEP_ALIVE=-1 so it never unloads while you work.
• Match context to hardware. Don't set num_ctx to 32K on a card that can only spare a few GB for KV cache — you'll trigger CPU offload and tank throughput. 16K is the sweet spot on 24 GB.
• Prefer Q4_K_M over lower quants. Dropping to Q3 to squeeze a bigger model in rarely pays off; the quality loss on code generation is visible, while Q4_K_M holds up well.
• Use a persistent tunnel. A free ngrok URL rotates on restart, forcing you to re-enter the Base URL. A named Cloudflare Tunnel or a reserved domain removes that daily friction.

For programmatic comparisons across models and quant levels, the free BestLLMfor public API (CC BY 4.0) and our open-source MCP server expose the same benchmark data used on this site, so you can script your own model-selection logic or wire live specs into an agent.

The verdict

Using a local Ollama LLM as Cursor's backend is genuinely viable in 2026, but it is a deliberate trade, not a free upgrade. You gain privacy and eliminate per-request cost; you give up Tab autocomplete, reliable Agent mode, and the frictionless polish of hosted models.

Your priority	Recommendation
Code must never leave your control	Local Ollama + tunnel, Qwen2.5-Coder 32B
Maximum speed & full features	Stay on Cursor's hosted models
Best free autocomplete experience	VS Code + local-first extension, not Cursor
Occasional private chat, low cost	Qwen3-Coder 30B A3B on a 24 GB GPU

If privacy or cost is the deciding constraint, follow the seven steps above, run the 32B Qwen coder, and accept Chat + Cmd+K as your working surface. For everyone else, the honest answer is that Cursor's hosted models remain the smoother path.