Cursor mit lokalem Modell: warum localhost scheitert, was lokal bleibt, Alternativen, GPU

Cursor mit Ollama oder einem lokalen LLM nutzen

Cursor kann über die Einstellung „Override OpenAI Base URL“ ein selbst betriebenes Modell aufrufen, aber die Anfrage wird auf Cursors Servern zusammengesetzt und von dort gesendet. Das Modell muss deshalb aus dem Internet erreichbar sein, und Ihre Eingaben samt dem Code darin laufen über Cursors Backend, bevor sie Ihre GPU erreichen. Ein lokales Modell in Cursor verlegt nur die Inferenz auf Ihre Hardware, der Code verlässt Ihr Netzwerk trotzdem. Damit er im Haus bleibt, brauchen Sie einen Editor oder eine Erweiterung, die das Modell direkt aufruft, etwa VS Code mit Cline oder Kilo Code, auf einer Workstation mit einer NVIDIA RTX PRO 5000 Blackwell 48 GB und Qwen3.8-27B als Ausgangspunkt.

Dieser Leitfaden richtet sich an Entwickler und kleine Produktteams, die Cursor nutzen und Ollama einbinden wollten, und an die Person, die entscheidet, welche Tools den Quellcode der Firma sehen dürfen. Die erste Hälfte erklärt, was Cursor mit einem lokalen Modell macht, die zweite die Einrichtung, bei der der Code im Haus bleibt. Terminal-Agenten wie Claude Code, OpenCode und Codex mit lokalem Modell behandelt ein eigener Leitfaden: Claude Code mit lokalem Modell.

Warum localhost und LAN-Adressen in Cursor nicht funktionieren

Cursors Data-Use-Seite, zuletzt aktualisiert am 3. September 2026, hält fest: „Even if you use your API key, your requests will still go through our backend!“, und erklärt, dass Cursor dort den Prompt endgültig zusammenbaut. Die Dokumentation zu API-Schlüsseln sagt dasselbe: „All requests are routed through our backend where we do the final prompt building“, und der Schlüssel selbst „will be sent up to our server with every request“.

Tragen Sie http://localhost:11434/v1 als Basis-URL ein, versucht Cursors Server, sein eigenes localhost aufzurufen. ngrok, das für genau diesen Fall eine Anleitung pflegt, formuliert es so: „Cursor's servers try to call localhost on their own machines, not yours.“ Cursors Changelog vom 22. Juni bis 20. Oktober 2026 kündigt keine direkte Verbindung zu lokalen Modellen an.

Was der Tunnel-Ausweg für Ihren Code bedeutet

Der Ausweg aus ngroks Anleitung ist ein Tunnel: Ein Programm auf Ihrer Workstation, etwa ngrok oder Cloudflare Tunnel, öffnet eine öffentliche HTTPS-Adresse, die an Ollama auf Port 11434 oder LM Studio auf Port 1234 weiterleitet. Diese Adresse tragen Sie mit /v1 unter Cursor Settings, Models als überschriebene OpenAI-Basis-URL ein, zusammen mit der genauen Modell-ID.

Eine Anfrage läuft dann von Ihrem Editor zu Cursors Backend, wo der Prompt entsteht, über das Netz des Tunnel-Anbieters zu Ihrer Maschine und auf demselben Weg zurück. ngroks Anleitung sagt es direkt: Muss Ihr Code in Ihrem Netzwerk bleiben, „a local model in Cursor doesn't solve that by itself“. Die öffentliche Adresse bringt ein zweites Risiko, das ngrok ebenfalls nennt: „Your URL is public, so anyone who finds it could use your GPU.“ Die Anleitung ergänzt deshalb eine Traffic-Policy, die Anfragen ohne geheimes Token abweist. Bei Ollama zählt dieser Schritt mehr als bei den meisten Servern. Ollamas FAQ beschreibt keine Anmeldung an der API, und CVE-2026-103663, am 8. Oktober 2026 veröffentlicht und in Ollama 0.35.0 behoben, erlaubt einer nicht authentifizierten Anfrage an /api/pull, Dateien außerhalb des Modellspeichers zu schreiben. Eine Ollama-Instanz hinter einem offenen Tunnel stellt diese API ins Internet.

Was mit Cursor lokal bleibt, Funktion für Funktion

Cursors Data-Use-Seite (3. September 2026), Sicherheitsseite (25. August 2026) und Dokumentationsseiten zu API-Schlüsseln und Datenschutz auf docs.cursor.com und ngroks Cursor-Anleitung, alle gelesen am 30. Oktober 2026, sowie Cursors Changelog, gelesen am 31. Oktober 2026.

Cursors Dokumentation zu API-Schlüsseln hält fest, dass „Custom API keys only work for features that use standard models“ und dass „Some Cursor features (like Tab Completion, Apply from Chat, and Composer) require specialized models“, die „won't work with custom API keys“. Die Datenschutzseite auf docs.cursor.com schreibt zur Indizierung der Codebasis: „Cursor will upload your codebase in small chunks to our server to compute embeddings“; gespeichert werden Embeddings und Metadaten wie Hashes und verschleierte Dateinamen, und „all plaintext code ceases to exist after the life of the request“. Die Data-Use-Seite ergänzt, dass mit aktivem Privacy Mode „Customer Data will not be used for training by Cursor“ und dass Cursor „maintains zero data retention (ZDR) agreements with all providers“; außerdem speichert Cursor laut dieser Seite Dateiinhalte vorübergehend auf seinen Servern zwischen, verschlüsselt mit Schlüsseln, die der Client erzeugt.

Einen dokumentierten Offline-Modus für diese Funktionen haben wir nicht gefunden. Cursors Sicherheitsseite, zuletzt aktualisiert am 25. August 2026, hält fest: „Our app makes requests to Cursor backend domains to deliver API, update, and marketplace functionality.“ Das Changelog vom 2. September 2026 ergänzt selbst gehostete Maschinen für Cursors Agenten: Codebasis, Build-Ergebnisse und Zugangsdaten bleiben auf internen Maschinen, und der Agent führt seine Tool-Aufrufe dort aus. Wo das Modell läuft und wo der Prompt entsteht, sagt der Eintrag nicht, und laut Data-Use-Seite vom 3. September 2026 laufen Anfragen weiterhin über Cursors Backend.

Editoren und Agenten, die das Modell direkt aufrufen

Die Alternative ist ein Tool, das die Anfragen von Ihrem eigenen Rechner an das Modell schickt. Ruft der Editor selbst http://localhost:11434 oder eine Adresse in Ihrem internen Netz auf, ist kein Cloud-Relais beteiligt, und der Code bleibt dort, wo das Modell läuft.

npm-Einträge von cline und opencode-ai, GitHub-Repositorys von Kilo Code, Continue und Roo Code, Kilos Blog vom 21. April 2026, Kilos Seite zum Ollama-Provider, die Dokumentation von Cline und Zed zu lokalen Modellen, gelesen am 30. Oktober 2026.

Cline ist ein Agent, der mit Ihrer Zustimmung Dateien bearbeitet und Befehle ausführt. Seine Dokumentation behandelt Ollama, LM Studio und Atomic Chat und empfiehlt für lokale Inferenz die Einstellung „Use Compact Prompt“. Kilo Code steht unter der MIT-Lizenz, läuft in VS Code, JetBrains-IDEs und als CLI, und laut Kilos Blog vom 21. April 2026 wurde die VS-Code-Erweiterung „from the ground up on the OpenCode server“ neu gebaut. Kilos Ollama-Seite schreibt „You need to have at least 32k to get decent results“ und empfiehlt für den Agenten qwen3-coder:30b. Zed führt llama.cpp, LM Studio, Ollama und lokale OpenAI-kompatible Server für seinen Agenten und den Inline-Assistenten auf, dazu eine selbst gehostete Option für Edit Predictions, das lokale Gegenstück zu Cursors Tab. Zed schickt Ollama einen Kontext von 4.096 Token, solange Sie context_window nicht setzen; für Agenten ist das zu kurz.

Zwei frühere Optionen gibt es nicht mehr. Das Repository von Roo Code wurde am 15. Mai 2026 archiviert, und sein README verweist auf den Community-Fork ZooCode und auf Cline. Das Repository von Continue hält fest, dass es „is no longer actively maintained and is read-only for all users“. Unser Leitfaden zum privaten Coding-Assistenten behandelt Cline und Continue für Teams, und unser Vergleich selbst gehosteter Copilot-Alternativen ergänzt die serverseitigen Produkte mit Verwaltungskonsole.

Sie können die Workstation allein bestellen, die Einrichtung von Cline oder Kilo Code mit Ollama und dem Modell allein oder beides zusammen: die Workstation mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

Welches lokale Modell an Cursors Cloud-Modelle heranreicht

In Cursor läuft der Agent normalerweise auf Cloud-Modellen von Anbietern wie OpenAI, Anthropic und Google, den Anbietern, die seine Dokumentation zu API-Schlüsseln nennt, und ein lokaler Ersatz muss groß genug sein, um mehrere Dateien zu bearbeiten und Tools zuverlässig aufzurufen. Wir beginnen mit Qwen3.8-27B, im August 2026 von Qwen unter Apache 2.0 veröffentlicht, mit einem nativen Kontext von 262.144 Token. In Qwens eigener Tabelle erreicht es 73,0 Punkte in Terminal Bench 2.1 gegenüber 78,2 für „Opus4.6 Max“ und 61,7 gegenüber 53,4 in SWE-bench Pro. Qwen hat die eigenen Modelle für SWE-bench Pro im Claude-Code-Harness gemessen und für Opus den offiziell gemeldeten Wert übernommen, die Paare sind also nicht gleichwertig. Das sind Angaben des Herstellers; unser Artikel Reicht ein lokales Modell fürs Vibe Coding? stellt sie anderen Belegen gegenüber.

Die schnellere Option ist Qwen3.6-35B-A3B (April 2026, Apache 2.0), ein Mixture-of-Experts-Modell, bei dem pro Token 3 seiner 35 Milliarden Parameter aktiv sind und das Qwens Modellkarte mit 73,4 Punkten in SWE-bench Verified führt. Ollama listet beide: qwen3.8:27b mit 18 GB in 4 Bit und 30 GB als q8_0, qwen3.6:35b-a3b mit 24 GB in 4 Bit.

StorageReview hat Qwen3.8-27B in NVFP4 mit vLLM 0.27.1 gemessen (14. Oktober 2026): Bei einer Anfrage lag jede Karte, auf der das Modell lief, zwischen 17 und 22 Token pro Sekunde, von der RTX PRO 4500 Server Edition und einer L40S bis zu einer RTX PRO 6000 Workstation Edition. Bei einem dichten Modell setzt die Speicherbandbreite die Grenze: Das 27B-Modell in 8 Bit liest pro Token etwa 28 GB Gewichte, den Checkpoint ohne seine Embedding-Tabelle, also ergeben die 1.344 GB/s der RTX PRO 5000 für eine Anfrage etwa 47 Token pro Sekunde und eine RTX PRO 6000 Workstation Edition oder Max-Q (1.792 GB/s) etwa 63, nach unserer Schätzung eine Obergrenze.

Workstation-Stufen für einen Entwickler und für ein Team

Der Speicher entscheidet, welches Modell und welcher Kontext passen. Unsere Regel für Nutzer je Karte rechnet mit 90 Prozent des Speichers, den der Treiber meldet, abzüglich 3 GiB pro Karte, für die Gewichte und einen Cache pro Sitzung. Mit Ollamas standardmäßigem 16-Bit-Cache braucht eine Sitzung von 128K mit Qwen3.8-27B 8,14 GiB und eine von 64K 4,14 GiB, nach unserer Rechnung aus der Konfiguration wie in unserem Leitfaden zu den Qwen-Hardware­anforderungen; Qwen3.6-35B-A3B braucht etwa 1,3 GiB pro Sitzung von 64K.

Nutzbarer Speicher nach unserer Regel für Nutzer je Karte: 25,7, 40,0 und 83,0 GiB pro Karte; Größen laut ollama.com am 30. Oktober 2026 (24 und 30 GB), Qwens FP8-Checkpoint mit 28,7 GiB wie in unserem Qwen-Leitfaden; 16-Bit-Cache, FP8-Cache in Klammern. WS: Workstation Edition (eine Max-Q hat denselben Speicher), SE: Server Edition. Unsere Schätzungen, keine Messungen.

Die 48-GB-Karte lässt nach den 8-Bit-Gewichten 12,1 GiB, eine Sitzung von 128K; die 72-GB-Version der RTX PRO 5000 hält vier, wie unser Vergleich RTX PRO 5000 Blackwell: 48 GB oder 72 GB? für andere Modelle erklärt. Eine RTX PRO 6000 Workstation Edition mit 96 GB hält sechs Sitzungen von 128K mit dem 8-Bit-Modell, drei mit der 16-Bit-Version oder Qwen3-Coder-Next in FP8 mit etwa fünf Sitzungen von 64K, wie unser Leitfaden zum privaten Coding-Assistenten rechnet. Auf dem Server mit zwei Karten halbiert vLLM mit FP8-Cache den Anteil je Token jeder Sitzung, sodass jede Karte 13 Sitzungen zu 128K hält und der Server 26. Eine Karte mit 24 GB wie die RTX PRO 4000 lässt für keines der beiden Modelle bei Agenten-Kontext genug Platz. Unser Leitfaden zur Vibe-Coding-Workstation nach RTX-PRO-Stufe vergleicht die Ausstattungen für Personen, die neue Apps aus Prompts bauen. Für Teams rechnet unser Leitfaden zum Server für Coding-Agenten 20 bis 100 Entwickler durch.

Nach unserer Schätzung (Karte, ein Prozessor mit 350 W und 15 Prozent für den Rest) nimmt eine Workstation mit einer RTX PRO 5000 unter Volllast etwa 0,75 kW auf, eine mit einer RTX PRO 6000 Workstation Edition etwa 1,1 kW, beide an einem normalen 230-V-Stromkreis.

Einrichtung, bei der der Code im Haus bleibt

• Ollama 0.35.0 oder neuer, wegen CVE-2026-103663; Ollama wird Stand Oktober 2026 aktiv weiterentwickelt, halten Sie es also aktuell. Ollama bindet standardmäßig an 127.0.0.1:11434, was für eine persönliche Workstation richtig ist. Die Einstellung OLLAMA_NO_CLOUD=1 entfernt laut Ollamas FAQ die Cloud-Modelle und die Websuche, damit keine Anfrage versehentlich den Rechner verlässt.
• Kontext. Ollamas Dokumentation sagt, Coding-Tools „should be set to at least 64000 tokens“, gesetzt mit OLLAMA_CONTEXT_LENGTH, während der Standard auf einer Karte mit 24 bis 48 GiB 32K beträgt. In Kilo Code setzen Sie „Context Window Size (num_ctx)“, in Zed context_window.
• Gemeinsame Nutzung. Teilen sich mehrere Entwickler eine GPU, binden Sie Ollama nur an das interne Netz, stellen einen Proxy mit Authentifizierung davor und erhöhen OLLAMA_NUM_PARALLEL; den Proxy behandelt unser Leitfaden zur Absicherung eines GPU-Servers.
• Telemetrie. Die Einstellung telemetry.telemetryLevel schaltet die Telemetrie von Visual Studio Code selbst ab, und seine Dokumentation weist darauf hin, dass Erweiterungen „may be collecting their own usage data and are not controlled by“ diese Einstellung; prüfen Sie jede Erweiterung, wie es unser Artikel zur Telemetrie in selbst gehosteten KI-Tools für die Serverseite tut.
• Ausgehender Verkehr. Eine Firewall-Regel, die der Workstation nur die nötigen Update- und Modellquellen erlaubt, fängt ab, was eine Einstellung übersieht.

Nennen Sie uns den Editor Ihrer Entwickler und die Größe der Repositorys, und wir schlagen die Konfiguration vor.

Wann Cursor mit Tunnel trotzdem passen kann

Ist der Code nicht vertraulich und erlauben Ihre Regeln die Verarbeitung durch Cursor, können Privacy Mode und die Vereinbarungen ohne Datenspeicherung auf der Data-Use-Seite genügen, und ein Tunnel zu Ihrer eigenen GPU ergänzt Chat und Agent um ein lokales Modell, während Tab und Composer bei Cursors Modellen bleiben. Schützen Sie den Tunnel mit einem Token, wie ngroks Anleitung zeigt, und halten Sie Ollama aktuell. Ist der Code vertraulich oder verbieten Kundenverträge die Weitergabe an Dritte, sind die direkten Tools oben der sauberere Weg. Welche Daten wohin dürfen, entscheidet das Unternehmen; dabei helfen unser Leitfaden zu hybrider KI, unser Artikel zu Geschäftsgeheimnissen und KI-Tools und unsere Richtlinie für KI-Coding-Assistenten, und Ihre Rechtsberatung bestätigt, was Ihre Verträge erlauben.

FAQ