Cursor with a local model: why localhost fails, what stays local, alternatives and GPU

Using Cursor with Ollama or a local LLM

Cursor can call a model that you host, through its "Override OpenAI Base URL" setting, but the request is assembled on Cursor's servers and sent from there. The model must therefore be reachable from the internet, and your prompts, including the code in them, pass through Cursor's backend before they reach your GPU. A local model in Cursor moves only the inference onto your hardware, and the code still leaves your network. To keep it in the building, use an editor or extension that calls the model directly, such as VS Code with Cline or Kilo Code, on a workstation with one NVIDIA RTX PRO 5000 Blackwell 48 GB and Qwen3.8-27B as a starting point.

This guide is for developers and small product teams who use Cursor and tried to plug in Ollama, and for the person who decides which tools may see the company's source code. The first half explains what Cursor does with a local model, the second half the setup that keeps code in the house. Terminal agents such as Claude Code, OpenCode and Codex with a local model have their own guide: Claude Code with a local model.

Why localhost and LAN addresses fail in Cursor

Cursor's Data Use page, last updated on 3 September 2026, states: "Even if you use your API key, your requests will still go through our backend!", and explains that this is where Cursor does its final prompt building. Its documentation on API keys says the same: "All requests are routed through our backend where we do the final prompt building", and the key itself "will be sent up to our server with every request".

If you enter http://localhost:11434/v1 as the base URL, Cursor's server tries to call its own localhost. ngrok, which maintains a guide for this case, puts it this way: "Cursor's servers try to call localhost on their own machines, not yours." Cursor's changelog from 22 June to 20 October 2026 announces no direct connection to local models.

What the tunnel workaround means for your code

The workaround in ngrok's guide is a tunnel: a program on your workstation, such as ngrok or Cloudflare Tunnel, opens a public HTTPS address that forwards to Ollama on port 11434 or LM Studio on port 1234. You enter that address with /v1 under Cursor Settings, Models, as the overridden OpenAI base URL, together with the exact model ID.

A request then travels from your editor to Cursor's backend, where the prompt is built, through the tunnel provider's network to your machine, and back the same way. ngrok's guide says it directly: if your code must stay on your network, "a local model in Cursor doesn't solve that by itself". The public address brings a second risk, which ngrok also names: "Your URL is public, so anyone who finds it could use your GPU." Its guide therefore adds a traffic policy that rejects requests without a secret token. That step matters more for Ollama than for most servers. Ollama's FAQ describes no login for its API, and CVE-2026-103663, published on 8 October 2026 and fixed in Ollama 0.35.0, lets an unauthenticated request to /api/pull write files outside the model store. An Ollama instance behind an open tunnel publishes that API to the internet.

What stays local with Cursor, feature by feature

Cursor's Data Use page (3 September 2026), security page (25 August 2026) and its documentation pages on API keys and privacy at docs.cursor.com and ngrok's Cursor guide, all read on 30 October 2026, and Cursor's changelog, read on 31 October 2026.

Cursor's documentation on API keys states that "Custom API keys only work for features that use standard models", and that "Some Cursor features (like Tab Completion, Apply from Chat, and Composer) require specialized models" which "won't work with custom API keys". Its privacy page at docs.cursor.com says that for codebase indexing "Cursor will upload your codebase in small chunks to our server to compute embeddings", keeps embeddings and metadata such as hashes and obfuscated file names, and that "all plaintext code ceases to exist after the life of the request". The Data Use page adds that, with Privacy Mode on, "Customer Data will not be used for training by Cursor" and that Cursor "maintains zero data retention (ZDR) agreements with all providers"; it also says Cursor caches file contents temporarily on its servers, encrypted with client-generated keys.

We found no documented offline mode for these features. Cursor's security page, last updated on 25 August 2026, states that "Our app makes requests to Cursor backend domains to deliver API, update, and marketplace functionality." Cursor's changelog of 2 September 2026 adds self-hosted machines for its agents: the codebase, build outputs and secrets stay on internal machines, and the agent runs its tool calls there. The entry does not say where the model runs or where the prompt is built, and the Data Use page of 3 September 2026 still sends requests through Cursor's backend.

Editors and agents that call the model directly

The alternative is a tool that sends requests from your own computer to the model. When the editor itself calls http://localhost:11434 or an address on your internal network, no cloud relay is involved, and the code stays where the model runs.

npm registry entries of cline and opencode-ai, GitHub repositories of Kilo Code, Continue and Roo Code, Kilo's blog of 21 April 2026, Kilo's Ollama provider page, Cline's and Zed's documentation on local models, read on 30 October 2026.

Cline is an agent that edits files and runs commands with your approval. Its documentation covers Ollama, LM Studio and Atomic Chat and tells you to enable its "Use Compact Prompt" setting for local inference. Kilo Code is MIT-licensed, runs in VS Code, JetBrains IDEs and a CLI, and, according to Kilo's blog of 21 April 2026, its VS Code extension was rebuilt "from the ground up on the OpenCode server". Kilo's Ollama page says "You need to have at least 32k to get decent results" and recommends qwen3-coder:30b for its agent. Zed lists llama.cpp, LM Studio, Ollama and local OpenAI-compatible servers for its agent and inline assistant, and a self-hosted option for its edit predictions, the closest local counterpart to Cursor's Tab. Zed sends a context of 4,096 tokens to Ollama unless you set context_window, which is too short for agents.

Two former options are gone. Roo Code's repository was archived on 15 May 2026, and its README points to the community fork ZooCode and to Cline. Continue's repository states that it "is no longer actively maintained and is read-only for all users". Our guide to the private coding assistant covers Cline and Continue for teams, and our comparison of self-hosted Copilot alternatives adds the server-side products with an admin console.

You can order the workstation alone, the setup of Cline or Kilo Code with Ollama and the model alone, or both together: the workstation delivered with everything installed and configured; write to us and we suggest the best solution for your tasks and budget.

Which local model comes close to Cursor's cloud models

In Cursor, the agent normally runs on cloud models from providers such as OpenAI, Anthropic and Google, the ones its API key documentation names, and a local replacement has to be large enough to edit several files and call tools reliably. We start from Qwen3.8-27B, published by Qwen in August 2026 under Apache 2.0, with a native context of 262,144 tokens. In Qwen's own table it scores 73.0 on Terminal Bench 2.1 against 78.2 for "Opus4.6 Max", and 61.7 against 53.4 on SWE-bench Pro. Qwen ran its own models on SWE-bench Pro in the Claude Code harness and took the officially reported score for Opus, so the pairs are not like-for-like. These are the vendor's figures; our article on whether a local model is good enough for vibe coding sets them against other evidence.

The faster option is Qwen3.6-35B-A3B (April 2026, Apache 2.0), a mixture-of-experts model with 3 billion of its 35 billion parameters active per token, which Qwen's card lists at 73.4 on SWE-bench Verified. Ollama lists both: qwen3.8:27b at 18 GB in 4-bit and 30 GB as q8_0, and qwen3.6:35b-a3b at 24 GB in 4-bit.

StorageReview measured Qwen3.8-27B in NVFP4 with vLLM 0.27.1 (14 October 2026): with one request, every card that ran the model, from the RTX PRO 4500 Server Edition and an L40S to an RTX PRO 6000 Workstation Edition, landed between 17 and 22 tokens per second. For a dense model, memory bandwidth sets the limit: the 8-bit 27B model reads about 28 GB of weights per token, the checkpoint less its embedding table, so the RTX PRO 5000's 1,344 GB/s gives about 47 tokens per second for one request and an RTX PRO 6000 Workstation Edition or Max-Q (1,792 GB/s) about 63, an upper bound by our estimate.

Workstation tiers for one developer and for a team

Memory decides which model and context fit. Our users-per-card rule counts 90 per cent of the memory the driver reports, less 3 GiB per card, for the weights plus one cache per session. With Ollama's default 16-bit cache, a 128K session of Qwen3.8-27B needs 8.14 GiB and a 64K session 4.14 GiB, by our arithmetic from its configuration as in our Qwen hardware guide; Qwen3.6-35B-A3B needs about 1.3 GiB per 64K session.

Usable memory by our users-per-card rule: 25.7, 40.0 and 83.0 GiB per card; Ollama sizes as listed on ollama.com on 30 October 2026 (24 and 30 GB), Qwen's FP8 checkpoint 28.7 GiB as in our Qwen guide; 16-bit cache, FP8 cache in brackets. WS: Workstation Edition (a Max-Q has the same memory), SE: Server Edition. Our estimates, not measurements.

The 48 GB card leaves 12.1 GiB after the 8-bit weights, one 128K session; the 72 GB version of the RTX PRO 5000 holds four, as our comparison of the RTX PRO 5000 48 GB and 72 GB explains for other models. An RTX PRO 6000 Workstation Edition with 96 GB holds six 128K sessions of the 8-bit model, three of the 16-bit version, or Qwen3-Coder-Next in FP8 with about five 64K sessions, as our private coding assistant guide sizes it. On the two-card server, vLLM with an FP8 cache halves the per-token part of each session, so each card holds 13 sessions of 128K and the server 26. A 24 GB card such as the RTX PRO 4000 leaves too little room for either model at agent context. Our guide to vibe coding workstations by RTX PRO tier compares the kits for people who build new apps from prompts. For teams, our guide to a server for coding agents sizes 20 to 100 developers.

By our estimate (card, a 350 W processor and 15 per cent for the rest), a workstation with one RTX PRO 5000 draws about 0.75 kW at full load and one with an RTX PRO 6000 Workstation Edition about 1.1 kW, both on an ordinary 230 V circuit.

Setting it up so the code stays in the building

• Ollama 0.35.0 or later, because of CVE-2026-103663; Ollama is actively developed as of October 2026, so keep it updated. Ollama binds to 127.0.0.1:11434 by default, which is right for a personal workstation. The setting OLLAMA_NO_CLOUD=1 removes Ollama's cloud models and web search, as its FAQ describes, so no request leaves the machine by mistake.
• Context. Ollama's documentation says coding tools "should be set to at least 64000 tokens", set with OLLAMA_CONTEXT_LENGTH, while its default on a 24 to 48 GiB card is 32K. In Kilo Code set "Context Window Size (num_ctx)", in Zed context_window.
• Shared use. If several developers use one GPU, bind Ollama to the internal network only, put an authenticating proxy in front and raise OLLAMA_NUM_PARALLEL; our guide to securing a GPU server covers the proxy.
• Telemetry. Visual Studio Code's telemetry.telemetryLevel setting turns its own telemetry off, and its documentation notes that extensions "may be collecting their own usage data and are not controlled by" that setting; check each extension, as our article on telemetry in self-hosted AI tools does for the server side.
• Outbound traffic. A firewall rule that allows the workstation only the update and model download sources it needs catches what a setting misses.

Tell us which editor your developers use and how large the repositories are, and we propose the configuration.

When Cursor with a tunnel can still make sense

If the code is not confidential and your rules allow Cursor's processing, Privacy Mode and the zero data retention agreements on its Data Use page may be enough, and a tunnel to your own GPU adds a local model to the chat and agent while Tab and Composer stay on Cursor's models. Protect the tunnel with a token, as ngrok's guide shows, and keep Ollama current. Where the code is confidential, or customer contracts forbid sending it to third parties, the direct tools above are the cleaner route. Which data may go where is a company decision, which our guide to hybrid AI, our article on trade secrets and AI tools and our AI coding assistant policy help to make; your legal counsel confirms what your contracts allow.

FAQ