Beste LLM's voor OpenCode – lokaal getest

Ik heb getest hoe OpenCode werkt met verschillende lokaal gehoste LLM’s via Ollama, en ter vergelijking heb ik ook enkele gratis modellen van OpenCode Zen toegevoegd.

OpenCode is op dit moment een van de meest belovende tools in het AI-developer tools-ecosysteem.

TL;DR - Beste LLM’s voor OpenCode

Duidelijke winnaar voor lokaal gebruik: Qwen 3.5 27b Q3_XXS op llama.cpp

Het model van 27b met IQ3_XXS-kwantisatie leverde een compleet, werkend Go-project met alle 8 unit-tests die slagen, een volledige README en 34 tokens/seconde op mijn setup met 16GB VRAM (CPU+GPU gemengd). Vijf sterren, zonder kanttekeningen. Dit is mijn standaardkeuze voor lokale OpenCode-sessies.

Qwen 3.5 35b op llama.cpp — snel voor coding, maar valideer alles

De 35b-versie is uitstekend voor snelle agentische coding-taken — maar mijn migratie-testen blootte een serieus betrouwbaarheidsprobleem. In twee runs met IQ3_S leverde het 63–73% mismatches in slugs, en in de IQ4_XS-kwantisatie vergeet het volledig om paginaslugs op te nemen, het genereren van categoriepaden die 8 verschillende pagina’s naar dezelfde URL zouden leiden. De coding-kwaliteit voor de IndexNow-taak was echt goed, dus dit model is de moeite waard om te gebruiken — maar vertrouw de output nooit op gestructureerde, regelgevolgende taken zonder het na te checken. Validatie is geen optie.

Verassend goed: Bigpicle (van OpenCode Zen)

Het snelst voltooid de taak — 1 minuut 17 seconden. Belangrijker nog: het was het enige model dat even pauzeerde voor het coderen om daadwerkelijk te zoeken naar de IndexNow-protocolspecificatie via Exa Code Search. Het vond direct de correcte endpoints. Als je toegang hebt tot OpenCode Zen, presteert dit model ver boven zijn gewichtsniveau.

Goed, maar alleen met hoog ’thinking’: GPT-OSS 20b

In de standaardmodus faalt GPT-OSS 20b — het raakt vast in dode WebFetch-oproepen en stopt. Schakel over naar de modus met hoog ’thinking’ en het wordt een echt bekwaam coding-assistent: volledige flag-parsing, correcte batching-logic, slagnende unit-tests, alles snel gedaan. Houd dat in gedachten voordat je het afdoet. GPT-OSS 20b faalde op gestructureerde taken, zelfs in de hoogste modus.

Overslaan voor agentisch coderen: GPT-OSS 20b (standaard), Qwen 3 14b, devstral-small-2:24b

Deze waren voorheen mijn favorieten voor snelheid in chat- en generatie-taken. Maar in agentische modus hebben ze allemaal echte problemen. Qwen 3 14b hallucineert documentatie in plaats van toe te geven dat het niets kan vinden. GPT-OSS 20b (standaard) stopt als WebFetch faalt. Devstral raakt verward bij basisbestandsoperaties. Voor OpenCode specifiek tellen instructievolging en tool-calling-kwaliteit veel meer dan pure snelheid.

Over deze test

Ik gaf elk model dat in opencode draaide twee taken/prompts:

1. Create for me a cli tool in Go, that would call bing and other search engines' indexnow endpoints to notify about changes on my website.
2. Bereid een website-migratiemap voor.

Je weet wel wat het Indexnow-protocol is, nietwaar?

Voor de tweede taak had ik een plan om sommige oude posts op deze website te migreren van het blog-URL-formaat (bijvoorbeeld https://www.glukhov.org/post/2024/10/digital-detox/) naar topic-clusters (zoals deze artikel URL: https://www.glukhov.org/ai-devtools/opencode/llms-comparison/). Dus ik heb elk LLM in OpenCode gevraagd om een migratiemap voor mij voor te bereiden, volgens mijn strategie.

Ik draaide de meeste LLM’s lokaal via Ollama, en sommige anderen lokaal via llama.cpp. Bigpicle en andere zeer grote taalmodellen waren van OpenCode Zen.

Resultaten per model

qwen3.5:9b

Volledig falen bij de eerste taak. Het model ging door zijn denkproces — het identificeerde correct de relevante services (Google Sitemap, Bing Webmaster, Baidu IndexNow, Yandex) — maar riep nooit daadwerkelijk tools aan. Het produceerde een “Build”-samenvatting zonder een enkel bestand aan te raken. Geen enkele tool-oproep.

qwen3.5:9b-q8_0

Een stap vooruit ten opzichte van de standaardkwantisatie: het creëerde tenminste een go.mod en een main.go. Maar daarna bleef het direct vast, gaf toe dat het ontbrekende imports moest toevoegen, probeerde het hele bestand te herschrijven met behulp van een shell heredoc — en faalde. De buildtijd was 1m 27s voor iets dat niet werkte.

Qwen 3 14b

Klassieke hallucinatie onder druk. Het probeerde drie keer achter elkaar IndexNow-documentatie op te halen, waarbij het elke keer een 404-troefde van een verkeerde URL (github.com/Bing/search-indexnow). In plaats van toe te geven dat het niets kon vinden, verzon het een zelfverzekerd klinkend antwoord — verkeerd API-endpoint, verkeerde authenticatiemethode. Toen ik het dwong om opnieuw te zoeken, produceerde het een tweede verzonnen antwoord dat verwees naar nog een URL die ook 404 gaf. De informatie die het rapporteerde was onjuist. Dit is het faalmode dat ik het meest wil vermijden.

GPT-OSS 20b

Tenminste was het gedrag eerlijk en methodisch. Het probeerde een lange keten van WebFetch-oproepen — indexnow.org, diverse GitHub-repositories, de eigen pagina’s van Bing — en trof 404’s of Cloudflare-blokkerings op bijna alles. Het documenteerde elk falen transparant. Uiteindelijk kon het toch niet genoeg informatie verzamelen om een werkend tool te bouwen, maar in tegenstelling tot Qwen 3 14b, zette het niets uit de lucht. Het kon gewoon niet doorbreken.

GPT-OSS 20b (hoog thinking)

Een betekenisvol ander verhaal dan in de standaardmodus. Met hoog ’thinking’ ingeschakeld, herstelde het model zich van dezelfde dode fetches en slaagde erin een compleet, werkend tool te bouwen — met correcte flag-parsing (--file, --host, --key, --engines, --batch, --verbose), GET voor enkele URL’s en POST-batches voor meerdere, volgens de IndexNow-spec.

Toen ik om documentatie en unit-tests vroeg, leverde het beide. Tests slaagden:

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

Snel ook — initiële build in 22,5s. Hoog ’thinking’ maakt gpt-oss:20b daadwerkelijk bruikbaar.

qwen3-coder:30b

De meest interessante mislukking. Het compileerde en voerde het tool daadwerkelijk uit tegen echte endpoints, zag echte API-fouten terug van Bing, Google en Yandex, en begon ze te repareren:

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"

Dat is goed instinct. Het probleem: het draaide op 720% CPU en slechts 7% GPU — extreem inefficiënt voor een model van 22 GB. Het duurde 11m 39s en de uiteindelijke output was nog steeds “niet helemaal wat verwacht wordt.” Het creëerde ook een README.md, wat een aardig extraatje is. Niet een slecht model, gewoon erg traag op mijn setup en het haalde het IndexNow-protocolformaat niet helemaal.

qwen3.5:35b (Ollama)

Solide resultaten maar traag. Het creëerde een correct Go-project, schreef tests en ze slaagden allemaal:

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

Het nadeel: 19m 11s buildtijd. Voor een model van 27 GB dat draait met 45%/55% CPU/GPU-verdeling, is dat te traag voor interactief gebruik. De kwaliteit is er, maar de latentie doodt de workflow.

Bigpicle (big-pickle)

De opvallende presteerder voor de eerste taak. Voordat het een enkele regel code schreef, gebruikte het Exa Code Search om daadwerkelijk onderzoek te doen naar het IndexNow-protocol:

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

En het vond de juiste endpoints:

• 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

Het opgeloste cobra-importprobleem schoon (go mod tidy), en het tool was klaar in 1m 17s. De rate-limit-respons die het terugkreeg van Bing tijdens het testen, was daadwerkelijk het verwachte gedrag voor een ongeldig testkey — het model identificeerde dit correct als “het tool werkt”. Imponeerend.

devstral-small-2:24b

Verward op basisniveau: het probeerde shell-commando’s (go mod init indexnowcli, go mod tidy) direct in het go.mod-bestand te schrijven, wat parse-fouten triggerde. Hoe dan ook slaagde het erin om een binary te bouwen (7,9M), maar de resulterende CLI was veel te eenvoudig — alleen indexnowcli <url> <key> zonder flag-handling, geen ondersteuning voor meerdere engines, niets. Het duurde 2m 59s + 1m 28s om een tool te krijgen die niet echt nuttig was.

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

Deze heeft me het meest van alle lokale runners geïmpresseerd. Draaiend als Qwen3.5-27B-UD-IQ3_XXS.gguf op llama.cpp (voornamelijk CPU), creëerde het een compleet tool met volledige testdekking — alle 8 tests slaagden — en een correcte README met installatie-instructies en protocoluitleg:

PASS    indexnow    0.003s

Ondersteunde engines: Bing, Yandex, Mojeek, Search.io. Buildtijd: 1m 12s voor het tool, 1m 27s voor tests en docs. Snelheid: 34 tokens/seconde. Kwaliteit: 5 sterren. Ongelooflijk resultaat voor een gekwantiseerd model dat op CPU+GPU draait.

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

Draaiend als Qwen3.5-35B-A3B-UD-IQ3_S.gguf op llama.cpp. Mijn notities hier zijn kort: “uitstekend!” — wat het ook allemaal zegt. Het grotere model op hetzelfde kwantisatieniveau leverde tenminste net zo goede resultaten als de 27b-variant, zo niet beter.

Resultaten migratiemap

Voor de tweede taak voerde ik een aparte batch uit — 7 modellen, allen dezelfde instructies, site-structuur en lijst van pagina’s gegeven. De beperking was expliciet: de slug (laatste pad-segment) moet hetzelfde blijven. Bijvoorbeeld, /post/2024/04/reinstall-linux/ moet worden /.../reinstall-linux/, niet iets anders.

Ik meet hoeveel slug-mismatches elk model produceerde — gevallen waarin de gegenereerde doel-slug verschilde van de bron-slug.

Model	Lijnen	Slug mismatches	Foutpercentage
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 -second run (llama.cpp)	81	51	63.0%
Qwen 3.5 35b IQ4_XS (llama.cpp)	80	79	98.8%

Eén ding dat alle 7 modellen identiek deden: oude URL’s in 2022-formaat hadden een maand-prefix ingebakken in de slug (bijv. /post/2022/06-git-cheatsheet/ → slug 06-git-cheatsheet). Elk model verwijderde dat prefix en gebruikte git-cheatsheet als nieuwe slug. Dat zijn 4 consistente mismatches in de top drie modellen — dus hun baseline is 4 fouten per model, niet nul.

De echte divergentie begint boven die baseline. minimax-m2.5-free, Nemotron 3 en Qwen 3.5 27b Q3_XXS overtredde de slug-regel alleen op die 4 legacy-paden — niets anders. Qwen 3.5 27b Q3_M voegde er 2 bij (hernoopte de cognee-artikel-slug en zette Base64 naar kleine letters). Bigpicle voegde er 5 bij bovenop de 4, voornamelijk door lange slugs te verkorten.

De uitschieters zitten in een andere categorie. Qwen 3.5 35b IQ3_S herschreef consistent slugs op basis van paginatitels in plaats van de bron te behouden (bijv. 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). De tweede run was iets beter (51 vs 59) maar toonde hetzelfde gedrag. Het hallucineerde ook een bronpad: het veranderde stilzwijgend comparing-go-orms-gorm-ent-bun-sqlc naar comparing-go-orms-gorm-ent-bun-sql (dropte de c), dus beide kanten van die regel stemden met elkaar overeen — maar waren allebei verkeerd. mimov2 was even agressief in het verkorten: gnome-boxes-linux-virtual-machines-manager → gnome-boxes, vm-manager-multipass-cheatsheet → multipass.

De IQ4_XS-kwantisatie van de 35b is een heel ander faalcategorie: 98.8% slug mismatches — maar het probleem is niet verkeerde slugs, het is dat het model vergeet om slugs helemaal op te nemen. In plaats van /new-section/page-slug/, produceerde het categoriepaden zoals /developer-tools/terminals-shell/ en /rag/architecture/. Acht bronpagina’s eindigden gemappt op /developer-tools/terminals-shell/ — allemaal naar dezelfde URL wijzend, wat rampzalig zou zijn als het gebruikt wordt. /developer-tools/ alleen verzamelde al vijf aparte pagina’s. De output is volkomen onbruikbaar.

Voor deze taak kwam de kleinere gekwantiseerde Qwen 3.5 27b Q3_XXS overeen met de beste presteerders — terwijl twee 35b-kwantisaties zwaar faalden, elk op hun eigen manier.

Conclusie

Ik ben blij om zowel Qwen 3.5 35b als Qwen 3.5 27b lokaal te draaien op llama.cpp met gekwantiseerde gewichten — de hardware-beperkingen zijn realiteit (16GB VRAM betekent IQ3/IQ4 kwantisaties), maar de workflow is solide.

De 27b Q3_XXS is de betrouwbare dagelijkse bestuurder. Het volgt instructies precies, produceert complete output en is snel genoeg voor interactief gebruik. Bij de migratiemap-taak kwam het overeen met de beste cloud-modellen.

De 35b is bekwaam maar onvoorspelbaar bij gestructureerde taken. Voor open-einde coding — schrijf me een tool, bouw dit — presteert het goed. Maar als de taak strenge regels heeft (zoals “de slug moet hetzelfde blijven”), hallucineert het vrijelijk bij alle kwantisaties die ik testte: slugs herschrijven vanuit titels, slugs volledig weghalen, zelfs stilzwijgend de bronpaden bewerken om zijn verkeerde output zelfconsistent te laten lijken. Als je de 35b gebruikt voor iets dat gestructureerde output produceert die je direct wilt gebruiken, bouw dan een validatiestap in je workflow. Neem niet aan dat de output correct is alleen omdat het plausibel lijkt.

Als je benieuwd bent naar de snelheid waarmee deze LLM’s presteren, bekijk dan Beste LLM’s voor Ollama op 16GB VRAM GPU.