Inhalt

Ein Modell, das auf dem eigenen PC läuft, soll Code schreiben. Das ging im Prinzip schon vor Jahren, aber möglich war nur die Vervollständigung – das Weiterschreiben einer angefangenen Zeile. Der agentische Einsatz, also „das Repository lesen, mehrere Dateien ändern, Tests laufen lassen", war für lokale Hardware zu schwer.

Genau da hat sich zwischen Ende 2025 und 2026 etwas bewegt. Dieser Artikel ordnet ausschließlich anhand von Primärquellen ein, was heute tatsächlich geht und wo es hakt. Das Ergebnis vorweg: Es funktioniert. Allerdings gibt es eine Hürde – ohne eine einzige geänderte Einstellung geht es lautlos kaputt.

📌 Zu den Zahlen in diesem Artikel: Benchmarks und Modellspezifikationen stammen durchgehend von den Herstellern selbst (offizielle Angaben von Mistral AI, die offiziellen Qwen-Modellkarten, die Ollama-Dokumentation, die Cline-Dokumentation und Anthropic). Aus zweiter Hand von Übersichtsartikeln ist nichts übernommen – bei der Recherche sind mehrfach Sammelbeiträge aufgetaucht, die Werte von Modellen einer ganz anderen Größe verwechselt hatten.

1. Was sich geändert hat – offene Modelle erreichen den agentischen Betrieb

Am deutlichsten zeigt sich der Wandel daran, dass die Modellhersteller selbst inzwischen mit „agentischem Programmieren" werben.

In der offiziellen Qwen-Modellkarte steht ausdrücklich: „unterstützt die meisten Plattformen wie Qwen Code oder CLINE und bringt ein eigens entworfenes Function-Call-Format mit" – die Editor-Erweiterung wird also namentlich genannt (Qwen3-Coder-30B-A3B-Instruct model card). Das Modell ist mit Blick auf einen konkreten Coding-Agenten gebaut.

Mistral AI geht in dieselbe Richtung. Das am 9. Dezember 2025 vorgestellte Devstral 2 ist ein Spezialmodell, das ausdrücklich für „agentisches Programmieren" gedacht ist, und die kleinere Variante Devstral Small 2 (24B) wurde unter Apache 2.0 veröffentlicht (Introducing: Devstral 2 and Mistral Vibe CLI).

Als es nur Vervollständigung war

Die angefangene Zeile zu Ende schreiben. Ein kleines Modell genügt, und der Kontext darf kurz sein. Das lief lokal ohne Mühe.

Sobald es agentisch wird

Nötig sind präzise Werkzeugaufrufe und ein langer, tragfähiger Kontext. Inzwischen gibt es offene Modelle, die dort ankommen.

2. Es gibt zwei Sorten Werkzeug – Continue und Cline sind grundverschieden

Wer beides verwechselt, wird von den Ergebnissen enttäuscht. Beides sind VS-Code-Erweiterungen, beide sprechen mit Ollama, aber die Entwurfsphilosophie ist eine völlig andere.

　 Continue Cline
Charakter Paket aus Vervollständigung, Chat und Bearbeitung Eigenständig arbeitender Coding-Agent
Rollenverteilung Pro Rolle ein eigenes Modell – chat / edit / apply / rerank / autocomplete Ein Modell erledigt alles von der Planung bis zur Ausführung
Hardwarebedarf Niedrig. Für die Vervollständigung reichen Modelle mit wenigen GB Hoch. Es braucht langen Kontext und präzise Werkzeugaufrufe
Passender Einsatz Beim Schreiben schneller werden Ganze Aufgaben abgeben

Der Ansatz von Continue, jeder Rolle ein eigenes Modell zuzuweisen, passt gut zu lokaler Hardware. Für die Vervollständigung ein kleines, schnelles Modell, für den Chat ein großes – diese Aufteilung ist genau der Punkt. Auch der offizielle Ollama-Leitfaden nennt für die Vervollständigung ausdrücklich leichtgewichtige Modelle wie qwen2.5-coder:1.5b oder starcoder2:3b (Continue — Ollama guide).

⚠️ Allerdings sind die in offiziellen Dokumentationen empfohlenen Modelle mitunter veraltet. Der genannte Leitfaden schlägt für den Chat llama3.1:8b oder deepseek-r1:32b vor, und das ist gegenüber dem heutigen Angebot mehrere Generationen alt. Die Arbeitsschritte der Dokumentation sind brauchbar, aber die Modellnamen sollte man nicht ungeprüft übernehmen, sondern anhand von „4. Modellwahl" neu entscheiden.

3. Die erste Falle – die Kontextlänge hängt am VRAM

Das ist das wichtigste Kapitel dieses Artikels. Wer es nicht kennt, landet in dem Zustand, in dem „die Einrichtung geklappt hat, der Agent aber mittendrin unsinnig handelt". Und zwar ohne jede Fehlermeldung.

Die Ursache liegt in der Standard-Kontextlänge von Ollama. Sie ist kein fester Wert, sondern ergibt sich automatisch aus der Menge des VRAM (Ollama — Context length).

VRAM Standard-Kontextlänge
unter 24 GiB 4k
24 bis 48 GiB 32k
48 GiB und mehr 256k

Ein üblicher Gaming-PC (8 bis 16 GB VRAM) fällt in die oberste Zeile. Also 4k. Ein Agent überschreitet das mit Systemprompt, Dateiinhalten und den Hin-und-Rück-Runden der Werkzeugaufrufe mühelos, und der Anfang des Gesprächs wird still abgeschnitten. Anweisungen werden vergessen, dieselbe Aktion wiederholt sich, das Ziel geht unterwegs verloren – die Ursache ist nicht mangelnde Intelligenz des Modells, sondern dass der Kontext schon am Eingang weggeworfen wird.

Ollama schreibt für diesen Einsatzzweck ausdrücklich: „Für anspruchsvolle Aufgaben wie Websuche oder Coding-Werkzeuge sollte der Kontext auf mindestens 64000 Token gesetzt werden." Eingestellt wird das über eine Umgebungsvariable beim Serverstart.

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

Wer die App-Version nutzt, kann den Wert auch über den Schieberegler in den Einstellungen ändern.

⚠️ Mit dem Hochdrehen allein ist es aber nicht getan. Auch die offizielle Dokumentation warnt: „Eine größere Kontextlänge erhöht den Speicherbedarf für die Ausführung des Modells."

Passt das Modell nicht mehr ins VRAM, wandern Teile davon auf die CPU und es wird dramatisch langsamer. Ob es wirklich greift, prüft man mit ollama ps – so steht es in der offiziellen Anleitung. Dort sieht man, ob alles auf der GPU liegt.

Auch auf der Cline-Seite gibt es eine Antwort auf dasselbe Problem. Die offizielle Dokumentation empfiehlt, „Use Compact Prompt zu aktivieren" und „die Aufgabe eng zu fassen (je kleiner der Kontext, desto schneller die Antwort)" (Cline — Running models locally). Weil der Systemprompt eines Agenten selbst schon lang ist, gibt es eine Einstellung, die genau dort kürzt.

4. Modellwahl – was pro VRAM-Klasse realistisch ist

Auf die Empfehlungen aus Übersichtsartikeln sollte man sich lieber nicht verlassen. Im geprüften Umfang fanden sich Beiträge, die Modelle von Mitte 2025 als „Empfehlung für 2026" führten, und solche, die den Wert eines 480B-Modells in die Spalte eines 30B-Modells geschrieben hatten. Hier stehen ausschließlich Herstellerangaben.

Modell Größe Kontext Lizenz SWE-bench Verified
Qwen3.6-35B-A3B 35B (3B aktiv) 262.144 (maximal 1.010.000) Apache 2.0 73,4
Devstral Small 2 24B 256K Apache 2.0 68,0 %
Devstral 2 (Referenz, zu groß) 123B 256K Modified MIT 72,2 %

Quellen: Modellkarte Qwen3.6-35B-A3B (Terminal-Bench 2.0 liegt bei 51,5, QwenClawBench bei 52,6) und die offizielle Ankündigung von Mistral AI (9. Dezember 2025). Die Werte wurden jeweils von den Herstellern selbst gemessen und stammen nicht aus einer unabhängigen Vergleichsmessung.

Bemerkenswert ist das „3B aktiv" bei Qwen3.6-35B-A3B. Von den 35B sind bei jedem Durchlauf tatsächlich nur 3B im Einsatz, und genau darin liegt der Vorteil von MoE (Mixture of Experts). Eine Struktur, die zugleich auf die Klugheit eines großen und die Geschwindigkeit eines kleinen Modells zielt – und damit gut zum lokalen Betrieb passt.

Download-Größe und nötige Ausstattung

In der Ollama-Bibliothek stehen bei qwen3.6 die Varianten 27b (18GB) und 35b (23GB) nebeneinander. Für Macs gibt es zusätzlich Tags mit dem Zusatz -mlx.

Die Richtwerte für den Arbeitsspeicher, die Cline offiziell nennt, lauten so: 16 bis 32 GB für kleine Modelle, 32 bis 64 GB für mittelgroße Coding-Modelle und 64 GB oder mehr für große Modelle mit größerem Kontext.

VRAM 8 bis 12 GB

Auf die Vervollständigung mit Continue beschränken. Den agentischen Betrieb entweder auslassen oder mit der Cloud kombinieren.

VRAM 16 bis 24 GB

Devstral Small 2 (24B) ist in Reichweite. Weil Luft für einen längeren Kontext bleiben muss, ist Quantisierung Pflicht.

VRAM ab 24 GB / Unified Memory ab 32 GB

Qwen3.6 als 27b/35b wird realistisch. Auch der Standardkontext steigt auf 32k.

Mistral schreibt zu Devstral Small 2, es laufe „auf Consumer-GPUs und sogar auf reinen CPU-Konfigurationen". Dass „läuft" und „läuft schnell genug für den Agentenbetrieb" zweierlei sind, sollte man dabei allerdings im Kopf behalten.

5. Einrichtung – der kürzeste Weg

① Ollama installieren und den Kontext festlegen

Die Reihenfolge zählt. Die Kontextlänge wird festgelegt, bevor das Modell geladen wird.

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

Die Installation selbst behandelt der komplette Ollama-Guide, dort finden sich die Einzelheiten.

② Das Modell holen

ollama pull qwen3.6:27b

Wird das VRAM knapp, nimmt man Devstral Small 2. Beide sind von vornherein für den agentischen Betrieb gebaut – das ist der Unterschied zu allgemeinen Chatmodellen.

③ Prüfen, ob alles auf der GPU liegt

ollama ps

Diesen Schritt nicht überspringen. Sobald etwas auf die CPU ausweicht, fühlt sich das Ganze völlig anders an. Hinter dem Eindruck „lokale LLMs sind zu langsam zum Arbeiten" steckt sehr oft genau das.

④ Die Erweiterung verbinden

Sowohl in Cline als auch in Continue wählt man als Anbieter Ollama und trägt http://localhost:11434 ein. Der offizielle Hinweis von Cline ist schlicht: „Stellen Sie sicher, dass Ollama läuft, bevor Sie einen Prompt senden." Besondere Einstellungen braucht es nicht.

Wer Cline verwendet, sollte zusätzlich Use Compact Prompt aktivieren.

6. Der Abstand zur Cloud lässt sich kaum noch messen

Das gehört ehrlich gesagt. Ein Vergleich der Form „lokale Modelle erreichen X Prozent der Cloud" lässt sich derzeit nicht sauber aufstellen. Der Grund: Die Benchmarks passen nicht mehr zusammen.

Die offenen Modelle veröffentlichen SWE-bench Verified. Qwen3.6-35B-A3B liegt bei 73,4, Devstral Small 2 bei 68,0 %. Die Frontier-Seite dagegen entfernt sich von dieser Kennzahl.

Tatsächlich enthält die Ankündigung von Claude Opus 5 durch Anthropic keinen SWE-bench-Verified-Wert. Genannt werden Frontier-Bench v0.1, CursorBench 3.2, der AA Coding Agent Index und FrontierCode 1.1, und dabei überwiegen relative statt absoluter Formulierungen (etwa „mehr als doppelt so leistungsfähig wie Opus 4.8" oder „innerhalb von 0,5 % des Spitzenwerts von Fable 5").

⚠️ Wer also eine Zahl der Art „lokal erreicht X Prozent von Claude" liest, sollte skeptisch sein. Mit hoher Wahrscheinlichkeit wurden Ausgangs- und Zielgröße nicht mit derselben Kennzahl gemessen oder es wird mit einem mehrere Generationen alten Claude verglichen. Über SWE-bench Verified lassen sich heute im Grunde nur noch offene Modelle untereinander vergleichen.

Was sich trotzdem sagen lässt

Auch ohne passende Zahlen ist klar, an welchen Stellen strukturell ein Unterschied entsteht.

Wo lokal im Vorteil ist

Der Code verlässt den Rechner nicht, keine nutzungsabhängigen Kosten (man kann beliebig oft durchlaufen lassen), Betrieb offline, keine Ratenbegrenzung.

Wo die Cloud im Vorteil ist

Schlussfolgern über mehrere Dateien hinweg, Stabilität bei langen autonomen Läufen, keine Anschaffungskosten, das Modell wird von selbst neuer.

Dass der Unterschied gerade beim „Schlussfolgern über mehrere Dateien hinweg" auffällt, hat einen Grund. Dort wird viel Kontext verbraucht und es stapeln sich Dutzende Entscheidungen. Der Genauigkeitsunterschied einer einzelnen Entscheidung wirkt sich mit jeder Runde multiplikativ aus. Was beim Nachbessern einer einzelnen Datei nicht auffällt, wird bei Arbeiten auf Repository-Ebene spürbar.

7. Stimmt es, dass lokal kostenlos ist?

Dass keine API-Rechnung kommt, stimmt – kostenlos ist es trotzdem nicht. Es ändert sich nur die Form der Kosten.

Posten Lokal Cloud
Anschaffungskosten GPU mit viel VRAM / großzügiger Unified Memory keine
Kosten, die mit der Nutzung steigen nur der Strom Token-Abrechnung oder Pauschale
Schwer sichtbare Kosten Aufwand für Einrichtung und Pflege, Nachziehen bei Modellwechseln keine (trägt der Anbieter)

Deshalb kehrt sich „was ist günstiger" je nach Vergleichsbedingung um. Wer bereits eine GPU der 24-GB-Klasse besitzt, fährt lokal fast ohne Zusatzkosten. Wer keine hat, bekommt für den Preis dieser GPU mehrere Jahre Abonnement. Genauer ist es, die Antwort an zwei Fragen festzumachen: „Läuft täglich viel?" und „Ist die Hardware schon da?".

8. Fazit zur Arbeitsteilung

Was für lokal spricht

Der Code darf den Rechner nicht verlassen (Vertrag, interne Vorgaben), die Hardware ist bereits vorhanden, man will ohne Blick auf die Anzahl ausprobieren, man arbeitet offline.

Was nicht dafür spricht

„Weil es kostenlos ist" (die Hardware ist nicht mitgerechnet), „weil es schnell wirkt" (die Cloud ist meistens schneller).

Am realistischsten ist die Kombination. Die Vervollständigung in Continue übernimmt ein kleines lokales Modell und läuft dauerhaft mit, größere Arbeitspakete gehen an einen Cloud-Agenten. Vervollständigung kommt oft vor und ist einzeln leicht, passt also nach lokal; ein Agent kommt selten vor und ist einzeln schwer, passt also in die Cloud – die Lastprofile sind genau gegenläufig.

Zusammenfassung

  • Offene Modelle haben das agentische Programmieren erreicht. Sowohl Qwen als auch Mistral veröffentlichen Spezialmodelle, die Editor-Erweiterungen namentlich nennen.
  • Die größte Hürde ist die Standard-Kontextlänge von Ollama. Unter 24 GiB VRAM sind es 4k, und der Agent geht lautlos kaputt. Offiziell empfohlen sind für Coding-Zwecke mindestens 64000.
  • Nach dem Hochsetzen mit ollama ps prüfen, ob alles auf der GPU liegt. Wandert etwas auf die CPU, wird es unvergleichlich langsam.
  • Continue und Cline sind grundverschieden. Ersteres weist jeder Rolle ein Modell zu und ergänzt Code, Letzteres ist ein autonomer Agent. Der Hardwarebedarf unterscheidet sich.
  • Der Vergleich „X Prozent der Cloud" trägt kaum noch. Die Frontier-Seite veröffentlicht SWE-bench Verified immer seltener.
  • Es ist nicht „kostenlos", sondern „anders verteilt". Ob die Hardware schon da ist, dreht die Antwort um.

FAQ

F1. Lässt sich der agentische Betrieb auch mit einer GPU mit 8 GB VRAM nutzen?

Das wird eng. Selbst wenn das Modell hineinpasst, bleibt kein Spielraum, um den Kontext zu verlängern. Der Ollama-Standard liegt unter 24 GiB VRAM bei 4k, und die Erhöhung auf 64000 treibt den Speicherbedarf hoch – beides zugleich ist mit 8 GB schwierig. Realistisch ist, sich auf die Vervollständigung mit Continue zu beschränken oder nur die Vervollständigung lokal zu betreiben und den Agenten in die Cloud zu legen.

F2. Womit sollte man anfangen, mit Cline oder mit Continue?

Wer zum ersten Mal ein lokales LLM einsetzt, nimmt Continue. Der Hardwarebedarf ist niedriger, und wenn etwas nicht läuft, ist die Fehlersuche einfacher. Erst prüfen, ob die Vervollständigung angenehm läuft, und dann zum agentischen Betrieb weitergehen – so lässt sich trennen, ob das Problem am Modell oder an der Konfiguration liegt.

F3. Läuft das auch auf einem Mac?

Ja. Der Unified Memory steht unmittelbar als VRAM-Äquivalent zur Verfügung, deshalb lassen sich dort sogar eher große Modelle unterbringen. In der Ollama-Bibliothek gibt es für qwen3.6 auch Tags mit dem Zusatz -mlx (für Apple Silicon). Allerdings gilt die Regel, dass sich die Standard-Kontextlänge aus der Speichermenge ergibt, hier genauso, eine Prüfung ist also nötig.

F4. Welches Modell ist „das klügste"?

Rein nach den veröffentlichten Werten hat unter den hier genannten Qwen3.6-35B-A3B mit SWE-bench Verified 73,4 den höchsten Wert. Allerdings handelt es sich um Messungen der Hersteller selbst und nicht um einen unabhängigen Direktvergleich. In der Praxis fallen die Lizenz (Devstral Small 2 und Qwen3.6 stehen beide unter Apache 2.0) und die Frage, ob das Modell in das vorhandene VRAM passt, stärker ins Gewicht.

F5. Warum geht es kaputt, ohne dass ein Fehler erscheint?

Weil alles, was über die Kontextlänge hinausgeht, nicht als Fehler, sondern als Abschneiden behandelt wird. Das Modell antwortet innerhalb des „übergebenen Bereichs" ganz normal. Im Ergebnis zeigt sich das als vergessene Anweisungen, wiederholte Aktionen und verlorenes Ziel und sieht nach mangelnder Leistungsfähigkeit des Modells aus. Ob man weiß, dass hier die Konfiguration verdächtig ist, entscheidet darüber, wie schnell man die Ursache eingrenzt.

F6. Welche Quantisierung sollte man wählen?

Im Zweifel beginnt man am besten bei etwas in der Größenordnung von Q4_K_M. Die Unterschiede der Formate (GGUF / GPTQ / AWQ) und die Auswahl sind im kompletten Guide zu Quantisierungsformaten zusammengefasst. Beim Programmieren ist „ein etwas kleineres Modell mit schwächerer Quantisierung" meist stabiler als „ein größeres Modell mit starker Quantisierung" – weil das Format der Werkzeugaufrufe exakt eingehalten werden muss.

F7. Darf man das mit dem Code der eigenen Firma nutzen?

Solange alles lokal bleibt, verlässt der Code den Rechner nicht – das ist der größte Vorteil lokaler LLMs. Allerdings sollte man die Einstellungen der Erweiterung prüfen. Auch wenn der Anbieter auf Ollama zeigt, können Telemetrie oder andere Funktionen nach außen kommunizieren. Und ob es die internen Vorgaben erlauben, ist eine Frage jenseits der Technik, deshalb sollte man zuerst die Richtlinien im Unternehmen klären.

Verwandte Artikel