Beste LLMs für OpenCode – lokal getestet

Ich habe getestet, wie OpenCode mit mehreren lokal gehosteten Ollama-LLMs funktioniert, und zum Vergleich habe ich einige kostenlose Modelle von OpenCode Zen hinzugefügt.

OpenCode gehört derzeit zu den vielversprechendsten Tools im Ökosystem der KI-Entwicklerwerkzeuge.

TL;DR – Beste LLMs für OpenCode

Der klare Gewinner für lokale Nutzung: Qwen 3.5 27b Q3_XXS auf llama.cpp

Das 27b-Modell mit der IQ3_XXS-Quantisierung lieferte ein vollständiges, funktionierendes Go-Projekt mit allen 8 bestandenenen Unit-Tests, einem vollständigen README und einer Geschwindigkeit von 34 Token/Sekunde auf meiner Setup-Konfiguration mit 16 GB VRAM (CPU+GPU gemischt). Fünf Sterne, ohne Einschränkungen. Dies ist mein bevorzugtes Modell für lokale OpenCode-Sessions.

Qwen 3.5 35b auf llama.cpp – schnell beim Coden, aber alles validieren

Das 35b-Modell ist hervorragend für schnelle, agentenbasierte Codieraufgaben – doch meine Tests zur Migrationskarte haben ein ernsthaftes Zuverlässigkeitsproblem aufgedeckt. Bei zwei Durchgängen mit IQ3_S-Quantisierung ergab dies eine Mismatch-Rate für Slugs von 63–73 %, und bei der IQ4_XS-Quantisierung vergaß es ganz, die Seitenslugs einzubeziehen, sodass es Pfade für Kategorien generierte, die 8 verschiedene Seiten auf dieselbe URL abbilden würden. Die Qualität des Codes bei der IndexNow-Aufgabe war tatsächlich gut, daher lohnt sich die Nutzung dieses Modells – vertrauen Sie jedoch niemals seiner Ausgabe bei strukturierten Aufgaben mit strikten Regeln, ohne sie zu überprüfen. Validierung ist nicht optional.

Überraschend gut: Bigpicle (von OpenCode Zen)

Das schnellste Modell zur Erledigung der Aufgabe – 1 Minute 17 Sekunden. Noch wichtiger: Es war das einzige Modell, das vor dem Codieren kurz pausierte, um tatsächlich nach der IndexNow-Protokollspezifikation mittels Exa Code Search zu suchen. Es fand alle korrekten Endpunkte beim ersten Versuch. Wenn Sie Zugriff auf OpenCode Zen haben, leistet dieses Modell weit mehr als erwartet.

Gut, aber nur mit hohem Denkmodus: GPT-OSS 20b

Im Standardmodus scheitert GPT-OSS 20b – es stößt auf Sackgassen bei WebFetch-Aufrufen und stoppt. Wechseln Sie in den Modus mit hohem Denkvermögen, und es wird zu einem tatsächlich fähigen Codierungsassistenten: vollständige Flag-Parsing, korrekte Batch-Logik, bestandenene Unit-Tests, alles schnell erledigt. Denken Sie daran, bevor Sie es ablehnen. GPT-OSS 20b scheiterte jedoch auch im hohen Modus bei strukturierten Aufgaben.

Für agentenbasiertes Coden überspringen: GPT-OSS 20b (Standard), Qwen 3 14b, devstral-small-2:24b

Diese waren früher meine Favoriten für Geschwindigkeit bei Chat- und Generierungsaufgaben. Aber im Agentenmodus haben sie alle echte Probleme. Qwen 3 14b halluziniert Dokumentation, anstatt zuzugeben, dass es nichts findet. GPT-OSS 20b (Standard) bleibt stehen, wenn WebFetch fehlschlägt. Devstral gerät bei grundlegenden Dateioperationen in die Verwirrung. Für OpenCode ist die Qualität der Befolgung von Anweisungen und des Tool-Calls weitaus wichtiger als die reine Geschwindigkeit.

Über diesen Test

Ich stellte jedem in opencode laufenden Modell zwei Aufgaben/Prompts:

1. Erstelle mir ein CLI-Tool in Go, das die IndexNow-Endpunkte von Bing und anderen Suchmaschinen aufruft, um über Änderungen auf meiner Website zu benachrichtigen.
2. Bereite eine Website-Migrationskarte vor.

Sie wissen, was das IndexNow-Protokoll ist, richtig?

Für die zweite Aufgabe habe ich einen Plan, einige alte Beiträge auf dieser Website vom Blog-URL-Format (beispielsweise https://www.glukhov.org/post/2024/10/digital-detox/) zu Themenclustern (wie dieser Artikel-URL: https://www.glukhov.org/ai-devtools/opencode/llms-comparison/) zu migrieren. Daher habe ich jedes LLM auf OpenCode gebeten, eine Migrationskarte für mich gemäß meiner Strategie vorzubereiten.

Ich führte die meisten LLMs auf lokal gehostetem Ollama aus, und einige andere auf lokal gehostetem llama.cpp. Bigpicle und andere sehr große Sprachmodelle stammten von OpenCode Zen.

Ergebnisse jedes Modells

qwen3.5:9b

Kompletter Misserfolg bei der ersten Aufgabe. Das Modell durchlief seinen Denkprozess – es identifizierte korrekt die relevanten Dienste (Google Sitemap, Bing Webmaster, Baidu IndexNow, Yandex) – rief aber nie tatsächlich ein Tool auf. Es produzierte eine “Build”-Zusammenfassung, ohne eine einzige Datei anzufassen. Keine Tool-Aufrufe.

qwen3.5:9b-q8_0

Ein Schritt nach oben gegenüber der Standardquantisierung: Es erstellte zumindest ein go.mod und ein main.go. Dann steckte es jedoch sofort fest, gab zu, dass es fehlende Imports hinzufügen musste, versuchte, die ganze Datei mit einem Shell-Heredoc neu zu schreiben – und scheiterte. Die Bauzeit betrug 1 Minute 27 Sekunden für etwas, das nicht funktionierte.

Qwen 3 14b

Klassische Halluzination unter Druck. Es versuchte dreimal hintereinander, die IndexNow-Dokumentation abzurufen, und traf jedes Mal auf eine 404-Fehlermeldung von einer falschen URL (github.com/Bing/search-indexnow). Anstatt zuzugeben, dass es nichts finden konnte, fabrizierte es eine selbstbewusste Antwort – falscher API-Endpunkt, falsche Authentifizierungsmethode. Als ich es aufforderte, erneut zu suchen, produzierte es eine zweite erfundene Antwort, die auf eine weitere URL verwies, die ebenfalls 404 zurückgab. Die gemeldeten Informationen waren falsch. Das ist das Versagensmuster, das ich am meisten vermeiden möchte.

GPT-OSS 20b

Zumindest war das Verhalten ehrlich und methodisch. Es versuchte eine lange Kette von WebFetch-Aufrufen – indexnow.org, verschiedene GitHub-Repositories, Bing-eigene Seiten – und stieß fast überall auf 404er oder Cloudflare-Blockaden. Es dokumentierte jeden Fehler transparent. Am Ende konnte es immer noch nicht genügend Informationen sammeln, um ein funktionierendes Tool zu bauen, aber anders als Qwen 3 14b hat es nichts erfunden. Es konnte einfach nicht durchdringen.

GPT-OSS 20b (hohes Denkvermögen)

Eine bedeutend andere Geschichte im Vergleich zum Standardmodus. Mit aktiviertem hohem Denkvermögen erholte sich das Modell von denselben Sackgassen-Fetches und schaffte es, ein vollständiges, funktionierendes Tool zu bauen – mit ordnungsgemäßem Flag-Parsing (--file, --host, --key, --engines, --batch, --verbose), GET für einzelne URLs und POST-Batches für mehrere, gemäß der IndexNow-Spezifikation.

Als ich nach Dokumentation und Unit-Tests fragte, lieferte es beides. Tests bestanden:

=== RUN   TestReadURLsFile
--- PASS: TestReadURLsFile (0.00s)
=== RUN   TestReadURLsNoProtocol
--- PASS: TestReadURLsNoProtocol (0.00s)
ok  	indexnow-cli	0.002s

Auch schnell – erste Bauzeit in 22,5 Sekunden. Hohes Denkvermögen macht gpt-oss:20b tatsächlich nutzbar.

qwen3-coder:30b

Das interessanteste Versagen. Es kompilierte und führte das Tool tatsächlich gegen echte Endpunkte aus, sah echte API-Fehlermeldungen von Bing, Google und Yandex zurück und begann, sie zu beheben:

Error notifying Bing: received status code 400 ... "The urlList field is required."
Error notifying Google: received status code 404 ...
Error notifying Yandex: received status code 422 ... "Url list has to be an array"

Das ist guter Instinkt. Das Problem: Es lief bei 720 % CPU und nur 7 % GPU – extrem ineffizient für ein 22-GB-Modell. Es dauerte 11 Minuten 39 Sekunden, und das finale Ergebnis war immer noch “nicht ganz das, was erwartet wurde”. Es erstellte auch ein README.md, was eine nette Geste ist. Kein schlechtes Modell, nur sehr langsam auf meinem Setup, und es hat das IndexNow-Protokollformat nicht vollständig getroffen.

qwen3.5:35b (Ollama)

Solide Ergebnisse, aber langsam. Es erstellte ein ordentliches Go-Projekt, schrieb Tests, und alle bestanden:

=== RUN   TestHashIndexNowPublicKey/non-empty_key
--- PASS
=== RUN   TestGetPublicKeyName/standard_root
--- PASS
=== RUN   TestGetPublicKeyName/custom_root
--- PASS

Der Nachteil: 19 Minuten 11 Sekunden Bauzeit. Für ein 27-GB-Modell, das mit einer CPU/GPU-Aufteilung von 45 %/55 % läuft, ist das für interaktive Nutzung zu langsam. Die Qualität ist da, aber die Latenz tötet den Workflow.

Bigpicle (big-pickle)

Das herausragende Modell für die erste Aufgabe. Bevor es eine einzige Zeile Code schrieb, nutzte es Exa Code Search, um tatsächlich das IndexNow-Protokoll zu recherchieren:

◇ Exa Code Search "IndexNow protocol API endpoint how to notify search engines"

Und es fand die richtigen Endpunkte:

• Global: https://api.indexnow.org/indexnow
• Bing: https://www.bing.com/indexnow
• Yandex: https://webmaster.yandex.com/indexnow
• Yep: https://indexnow.yep.com/indexnow
• Amazon: https://indexnow.amazonbot.amazon/indexnow

Es löste das cobra-Import-Problem sauber (go mod tidy), und das Tool war in 1 Minute 17 Sekunden fertig. Die Rate-Limit-Antwort, die es während des Tests von Bing zurückbekam, war tatsächlich das erwartete Verhalten für einen ungültigen Testschlüssel – das Modell identifizierte dies korrekt als “das Tool funktioniert”. Beeindruckend.

devstral-small-2:24b

Verwirrt auf einer grundlegenden Ebene: Es versuchte, Shell-Befehle (go mod init indexnowcli, go mod tidy) direkt in die go.mod-Datei zu schreiben, was Parse-Fehler auslöste. Irgendwie schaffte es trotzdem, ein Binärfile (7,9 MB) zu bauen, aber das resultierende CLI war viel zu einfach – nur indexnowcli <url> <key> ohne Flag-Verarbeitung, ohne Unterstützung für mehrere Engines, nichts. Es dauerte 2 Minuten 59 Sekunden + 1 Minute 28 Sekunden, um ein Tool zu erhalten, das nicht wirklich nützlich war.

qwen3.5:27b (llama.cpp, IQ3_XXS Quantisierung)

Das hat mich von allen lokalen Runnern am meisten beeindruckt. Als Qwen3.5-27B-UD-IQ3_XXS.gguf auf llama.cpp (meistens CPU) ausgeführt, erstellte es ein vollständiges Tool mit vollständiger Testabdeckung – alle 8 Tests bestanden – und ein ordnungsgemäßes README mit Installationsanweisungen und Protokollerklärung:

PASS    indexnow    0.003s

Unterstützte Engines: Bing, Yandex, Mojeek, Search.io. Bauzeit: 1 Minute 12 Sekunden für das Tool, 1 Minute 27 Sekunden für Tests und Dokumentation. Geschwindigkeit: 34 Token/Sekunde. Qualität: 5 Sterne. Ein unglaubliches Ergebnis für ein quantisiertes Modell, das auf CPU+GPU läuft.

qwen3.5:35b (llama.cpp, IQ3_S Quantisierung)

Ausgeführt als Qwen3.5-35B-A3B-UD-IQ3_S.gguf auf llama.cpp. Meine Notizen hier sind kurz: “exzellent!” – das sagt alles. Das größere Modell auf demselben Quantisierungslevel lieferte mindestens genauso gute Ergebnisse wie die 27b-Variante, wenn nicht sogar bessere.

Ergebnisse der Migrationskarte

Für die zweite Aufgabe führte ich einen separaten Batch durch – 7 Modelle, alle mit denselben Anweisungen, der gleichen Website-Struktur und der gleichen Seitenliste. Die Einschränkung war explizit: der Slug (der letzte Pfadsegment) muss gleich bleiben. Zum Beispiel muss /post/2024/04/reinstall-linux/ zu /.../reinstall-linux/ werden, nicht zu etwas anderem.

Ich maß, wie viele Slug-Mismatches jedes Modell produzierte – Fälle, bei denen der generierte Zielslug vom Quellslug abwich.

Model	Zeilen	Slug-Mismatches	Fehlerrate
minimax-m2.5-free	80	4	5,0 %
Nemotron 3	78	4	5,1 %
Qwen 3.5 27b Q3_XXS (llama.cpp)	80	4	5,0 %
Qwen 3.5 27b Q3_M (llama.cpp)	81	6	7,4 %
Bigpicle	81	9	11,1 %
mimo-v2-flash-free	80	42	52,5 %
Qwen 3.5 35b IQ3_S - zweiter Durchlauf (llama.cpp)	81	51	63,0 %
Qwen 3.5 35b IQ4_XS (llama.cpp)	80	79	98,8 %

Eine Sache, die alle 7 Modelle identisch taten: Alte URLs im Format von 2022 hatten ein Monatspräfix im Slug eingebaut (z. B. /post/2022/06-git-cheatsheet/ → Slug 06-git-cheatsheet). Jedes Modell entfernte dieses Präfix und verwendete git-cheatsheet als neuen Slug. Das sind 4 konsistente Mismatches in den drei besten Modellen – also ist ihre Basis 4 Fehler pro Modell, nicht null.

Die eigentliche Divergenz beginnt oberhalb dieser Basis. minimax-m2.5-free, Nemotron 3 und Qwen 3.5 27b Q3_XXS verletzten die Slug-Regel nur bei diesen 4 Legacy-Pfaden – nichts anderes. Qwen 3.5 27b Q3_M fügte 2 weitere hinzu (benannte den Slug des cognee-Artikels um und machte Base64 klein). Bigpicle fügte 5 weitere zu den 4 hinzu, hauptsächlich durch Verkürzung langer Slugs.

Die Ausreißer gehören in eine andere Kategorie. Qwen 3.5 35b IQ3_S schrieb Slugs konsistent von Seitentiteln um, anstatt die Quelle zu erhalten (z. B. executable-as-a-service-in-linux → run-any-executable-as-a-service-in-linux, file-managers-for-linux-ubuntu → context-menu-in-file-managers-for-ubuntu-24). Der zweite Durchlauf war etwas besser (51 gegenüber 59), zeigte aber dasselbe Verhalten. Es halluzinierte auch einen Quellpfad: Es änderte stillschweigend comparing-go-orms-gorm-ent-bun-sqlc zu comparing-go-orms-gorm-ent-bun-sql (ließ das c weg), sodass beide Seiten dieser Zeile übereinstimmten – aber beide falsch waren. mimov2 war ähnlich aggressiv beim Kürzen: gnome-boxes-linux-virtual-machines-manager → gnome-boxes, vm-manager-multipass-cheatsheet → multipass.

Die IQ4_XS-Quantisierung des 35b ist eine ganz andere Kategorie des Versagens: 98,8 % Slug-Mismatches – aber das Problem sind nicht falsche Slugs, sondern dass das Modell vergaß, Slugs überhaupt einzubeziehen. Anstatt /new-section/page-slug/ produzierte es Kategoriepfade wie /developer-tools/terminals-shell/ und /rag/architecture/. Acht Quellseiten endeten auf /developer-tools/terminals-shell/ – alle zeigten auf dieselbe URL, was katastrophal wäre, wenn es verwendet würde. Allein /developer-tools/ sammelte fünf separate Seiten. Die Ausgabe ist völlig unbrauchbar.

Für diese Aufgabe entsprach das kleinere, quantisierte Qwen 3.5 27b Q3_XXS den besten Performern – während zwei 35b-Quantisierungen auf ihre eigene Weise schlecht versagten.

Fazit

Ich bin glücklich, sowohl Qwen 3.5 35b als auch Qwen 3.5 27b lokal auf llama.cpp mit quantisierten Gewichten auszuführen – die Hardware-Einschränkungen sind real (16 GB VRAM bedeutet IQ3/IQ4-Quantisierungen), aber der Workflow ist solide.

Das 27b Q3_XXS ist der zuverlässige Alltagsbegleiter. Es folgt Anweisungen präzise, produziert vollständige Ausgaben und ist schnell genug für interaktive Nutzung. Bei der Aufgabe der Migrationskarte entsprach es den besten Cloud-Modellen.

Das 35b ist fähig, aber bei strukturierten Aufgaben unvorhersehbar. Bei offen-ended Codieraufgaben – “schreib mir ein Tool”, “baue das” – leistet es gute Arbeit. Aber wenn die Aufgabe strenge Regeln hat (wie “der Slug muss gleich bleiben”), halluziniert es frei bei allen Quantisierungen, die ich getestet habe: Slugs von Titeln umschreiben, Slugs ganz weglassen, sogar stillschweigend die Quellpfade bearbeiten, um seine falsche Ausgabe selbstkonsistent erscheinen zu lassen. Wenn Sie das 35b für etwas verwenden, das strukturierte Ausgaben erzeugt, die Sie direkt verwenden planen, bauen Sie einen Validierungsschritt in Ihren Workflow ein. Nehmen Sie nicht an, dass die Ausgabe korrekt ist, nur weil sie plausibel aussieht.

Wenn Sie neugierig sind, mit welcher Geschwindigkeit diese LLMs performen, schauen Sie sich Beste LLMs für Ollama auf 16GB VRAM GPU an.