Claude Code Gratis Uitvoeren Met Ollama Lokale Modellen

Claude Code Gratis Uitvoeren Met Ollama Lokale Modellen

Mijn Claude Pro-abonnement kostte me vorige maand weer $20. Ik staarde even naar de factuur — niet omdat twintig dollar veel is, dat is het niet — maar omdat ik had gelezen over de nieuwe Anthropic API-compatibiliteitslaag van Ollama, en een vraag had me al weken beziggehouden: wat als ik het volledige agentframework van Claude Code kon draaien op een lokaal model op mijn eigen GPU, zonder ook maar één token naar de servers van Anthropic te sturen?

Dus probeerde ik het. Drie verschillende modellen. Twee weken echt projectwerk. En de resultaten verrasten me oprecht — al niet op de manier die je zou verwachten.

De korte versie: ja, je kunt Claude Code volledig gratis uitvoeren met lokale modellen via Ollama, en voor een specifieke categorie van ontwikkelwerk is het verbluffend capabel. Voor een andere categorie valt het volledig door de mand. Het interessante is uitzoeken waar die grens precies ligt, want die ligt niet waar de meeste mensen aannemen. Ik laat je de exacte grens zien die ik heb gevonden — en de specifieke taken waarbij lokale modellen mijn verwachtingen overtroffen — zodra we door de setup heen zijn.

Maar eerst wat context over waarom dit verder gaat dan twintig dollar per maand besparen.

Waarom Lokaal Draaien van Claude Code Het Spel Verandert

Claude Code is in mijn ervaring de beste AI-codeeragent die er momenteel beschikbaar is. Het draait in je terminal. Het leest je codebase, bewerkt bestanden, voert tests uit, beheert git, en voert meerstaps-ontwikkelworkflows uit met een mate van autonomie die me soms nog steeds verrast. Ik heb er complete agentsystemen mee gebouwd, klantenprojecten mee opgeleverd, contentpipelines geautomatiseerd over vier websites.

Het probleem is altijd de betaalmuur geweest. Je hebt ofwel een Claude Pro-abonnement of raw API-credits nodig om het te gebruiken. Dat is een harde drempel voor studenten, indie hackers, open-source-bijdragers, en iedereen die gewoon wil experimenteren zonder financiële verplichtingen aan te gaan.

Ollama heeft de vergelijking veranderd. Als je het nog niet hebt gebruikt: Ollama is eigenlijk Docker voor taalmodellen — je pulled modellen zoals je container-images pulled, en ze draaien lokaal op je hardware. De recente toevoeging van Anthropic API-compatibiliteit betekent dat Ollama nu het API-eindpunt van Anthropic kan nabootsen. Claude Code merkt het verschil niet. Het stuurt verzoeken naar wat het denkt dat Anthropic's server is, en Ollama onderschept ze, routeert ze naar welk lokaal model je hebt geladen, en stuurt antwoorden terug in het formaat dat Claude Code verwacht.

Dat is de truc. De volledige tooling-infrastructuur van Claude Code — bestandsbewerking, zoekopdrachten in code, terminalopdrachten, sub-agents, geplande prompts — alles werkt via deze compatibiliteitslaag. Het model dat de intelligentie aanstuurt verandert. Het framework blijft identiek.

Het ding dat niemand je vertelt is dit echter: het model dat je kiest maakt enorm veel uit, en de relatie tussen modelgrootte, VRAM-vereisten en daadwerkelijke codeer-performance is niet lineair. Ik testte drie configuraties en kreeg wildly verschillende resultaten van elk. We komen na de setup op die benchmarks terug — en één ervan heeft echt veranderd hoe ik over lokale AI-ontwikkeling denk.

Wat Je Nodig Hebt Voor Je Begint

Laat me eerlijk zijn over de hardwarevereisten, want hier gaan veel tutorials de mist in. Ze tonen je een setup die op een monsterlijk werkstation draait en vergeten dan terloops te vermelden dat het niet werkt op jouw MacBook Air.

Ik gebruik een NVIDIA GeForce RTX 4090 met 24GB VRAM. Dat is een serieuze GPU. Voor de 3B-parametermodellen heb je dat absoluut niet nodig — een kaart met 6-8GB VRAM handelt die prima af. Maar als we bij de 32B-parametermodellen komen die daadwerkelijk kwaliteitscode produceren? Dan wil je minimaal 24GB. De M-serie MacBooks met 32GB+ unified memory kunnen dit ook aan, maar verwacht langzamere inferentiesnelheden vergeleken met een dedicated NVIDIA-kaart.

De kritieke drempel is contextlengte. Voor de agentfuncties van Claude Code om goed te werken — met name de parallelle sub-agent-uitvoering en bewerking van meerdere bestanden — heb je minimaal 32K tokens aan context nodig. Kleinere contextvensters zorgen ervoor dat de agent de inhoud van bestanden kwijtraakt halverwege een bewerking, eerdere instructies vergeet, en gefragmenteerde wijzigingen produceert die je codebase kapotmaken. Ik heb dit geleerd door te kijken hoe een 3B-model met 8K context probeerde een serviceklasse te refactoren. Het bewerkte de eerste helft prachtig en vergat toen volledig dat de tweede helft bestond.

Dit is de minimale setup:

• GPU: 8GB+ VRAM voor kleine modellen (3B-7B), 24GB+ voor serieus werk (32B+)
• RAM: Minimaal 16GB systeemgeheugen, 32GB aanbevolen
• Opslag: 5-30GB per model afhankelijk van grootte
• OS: macOS, Linux of Windows (WSL2 aanbevolen op Windows)
• Software: Node.js 18+, npm, Ollama, Claude Code CLI

Er zijn websites — ik gebruik sites zoals ollama.com/search en diverse VRAM-calculators — waarmee je je exacte GPU kunt matchen aan compatibele modellen. Check dit voordat je een 20GB-model downloadt dat je kaart niet aankan.

Nu het deel waarvoor je eigenlijk hier bent.

De Volledige Setup: Van Nul Naar Draaiend in 10 Minuten

Ik loop dit door op macOS/Linux eerst, dan behandel ik de Windows-verschillen. Het hele proces duurt ongeveer tien minuten, aangenomen dat je een fatsoenlijke internetverbinding hebt voor de modeldownload.

Stap 1: Installeer Ollama

Ga naar ollama.com en download het installatieprogramma voor jouw platform. Op macOS is het een standaard .dmg. Op Linux is er een one-liner:

curl -fsSL https://ollama.com/install.sh | sh

Controleer na installatie of het draait:

ollama --version
# Zou iets moeten tonen als: ollama version 0.6.x

Ollama draait als een achtergrondservice. Op macOS start het automatisch. Op Linux moet je het mogelijk handmatig starten:

# Start Ollama service (Linux)
systemctl start ollama

# Of direct uitvoeren
ollama serve

De server luistert standaard op http://localhost:11434. Die URL is belangrijk — dit is waar Claude Code verbinding mee maakt.

Stap 2: Pull Je Eerste Model

Hier wordt het interessant. Je kiest het brein dat je codeeragent aanstuurt. Ik testte er drie, en ik geef je de aanbeveling alvast: begin met qwen2.5-coder:3b voor je eerste run. Het is snel, lichtgewicht, en goed genoeg om het concept te bewijzen voordat je tijd investeert in het downloaden van grotere modellen.

# Snel en licht — prima voor het testen van de setup
ollama pull qwen2.5-coder:3b

# Capabeler — heeft 16GB+ VRAM nodig
ollama pull qwen2.5-coder:14b

# Het echte werk — heeft 24GB+ VRAM nodig maar echt indrukwekkend
ollama pull qwen2.5:32b

De downloadgroottes zijn respectievelijk ongeveer 2GB, 9GB en 20GB. Terwijl het downloadt, laten we Claude Code gereedmaken.

Stap 3: Installeer Claude Code

Als je Claude Code nog niet hebt geïnstalleerd, is het een eenvoudige npm-installatie:

npm install -g @anthropic-ai/claude-code

Verifieer de installatie:

claude --version

Je kunt ook de Claude Code desktop-app gebruiken als je dat prefereert — de environment variable-aanpak werkt met beide.

Stap 4: Wijs Claude Code naar Ollama

Dit is de cruciale stap. Je moet Claude Code vertellen te stoppen met zoeken naar de cloud-API van Anthropic en in plaats daarvan te communiceren met je lokale Ollama-server. Twee omgevingsvariabelen regelen dit.

Op macOS/Linux:

export ANTHROPIC_BASE_URL=http://localhost:11434
export ANTHROPIC_API_KEY=ollama

Op Windows (Opdrachtprompt):

set ANTHROPIC_BASE_URL=http://localhost:11434
set ANTHROPIC_API_KEY=ollama

Op Windows (PowerShell):

$env:ANTHROPIC_BASE_URL = "http://localhost:11434"
$env:ANTHROPIC_API_KEY = "ollama"

De API-sleutel kan letterlijk van alles zijn — Ollama controleert hem niet. Ik gebruik "ollama" omdat het in mijn shellgeschiedenis duidelijk maakt dat ik lokaal draai en geen echte API-credits verbruik.

Om dit permanent te maken, voeg die export-regels toe aan je .bashrc, .zshrc of shellprofiel. Ik bewaar de mijne in een apart script dat ik sourct wanneer ik lokale modus wil:

# ~/scripts/claude-local.sh
export ANTHROPIC_BASE_URL=http://localhost:11434
export ANTHROPIC_API_KEY=ollama
echo "Claude Code pointed at local Ollama"

Dan run ik gewoon source ~/scripts/claude-local.sh als ik wil wisselen. Als ik de echte Claude nodig heb, unset ik die variabelen of open ik een nieuwe terminal met mijn echte Anthropic-sleutel.

Stap 5: Start Claude Code Met Je Lokale Model

Nu het moment van de waarheid:

claude --model qwen2.5-coder:3b

Als alles correct is bedraad, start Claude Code op precies zoals het altijd doet — zelfde interface, zelfde commando's, zelfde toolmogelijkheden. Het enige verschil is de intelligentie erachter. Je prompts gaan naar localhost in plaats van de servers van Anthropic. Je tokens verlaten je machine nooit.

Probeer eerst iets eenvoudigs:

> Create a Python function that reads a CSV file and returns the top 5 rows sorted by a specified column

Als je het model ziet nadenken, code genereren en aanbieden om die naar een bestand te schrijven — gefeliciteerd. Je draait Claude Code gratis op je eigen hardware.

Dit is waar de meeste tutorials eindigen. Maar het interessante verhaal is wat er gebeurt als je dit daadwerkelijk probeert te gebruiken voor echt werk.

Drie Modellen, Twee Weken, Één Eerlijke Beoordeling

Ik committeerde me aan het gebruik van deze lokale setup voor twee weken daadwerkelijk ontwikkelwerk. Geen speelgoedprojecten — echt klantwerk, echte deadlines, echte codebases. Ik wisselde af tussen drie modellen en hield bij wat elk model goed aankon en waar elk model tekortschoot.

Qwen 2.5 Coder 3B: De Snelheidsduivel

Dit kleine model draait bliksemsnel, zelfs op bescheiden hardware. Responstijden waren onder de 2 seconden voor de meeste prompts. Ik gebruikte het voor:

• Het genereren van standaard CRUD-endpoints in Laravel
• Het schrijven van unit-testskeletten
• Het aanmaken van TypeScript-interfaces vanuit JSON-voorbeelden
• Eenvoudige bestandsscaffolding en projectinitialisatie
• Het genereren van git commit-berichten

Voor deze taken presteerde het op misschien 70-75% van de kwaliteit van Claude Sonnet. De code compileerde. De logica klopte. De naamgevingsconventies waren redelijk. Voor scaffolding met name — het genereren van het skelet van een nieuwe serviceklasse, een nieuwe API-route, een nieuw React-component — was het verrassend capabel.

Waar het fout ging: alles wat bewustzijn van meerdere bestanden vereist. Ik vroeg het een authenticatieservice te refactoren die vier verschillende bestanden raakte. Het behandelde het eerste bestand perfect, maakte redelijke wijzigingen in het tweede, en tegen het derde bestand was het de wijzigingen die het al had gemaakt kwijt. Het vierde bestand was in wezen gehallusineerd — het verwees naar functies die het dacht te hebben geschreven maar dat niet had.

Het 3B-model denkt één bestand tegelijk. Dat is prima voor geïsoleerde taken. Het is een dealbreaker voor architectureel werk.

Qwen 2.5 32B: De Verrassing

Ik verwachtte incrementele verbetering. Ik kreeg een kwalitatieve verschuiving. Het 32B-model maakte niet alleen minder fouten — het demonstreerde echte meerstapredenering die het 3B-model niet kon evenaren.

Ik gaf het dezelfde authenticatierefactor. Het plantte de wijzigingen over alle vier de bestanden voordat het een enkele regel schreef. Het identificeerde een circulaire afhankelijkheid die ik zelf niet had opgemerkt. Het stelde voor een gedeelde interface te extraheren om het soort drift te voorkomen dat typisch optreedt wanneer je gerelateerde services onafhankelijk wijzigt.

Was het zo goed als Claude Sonnet? Nee. De codestructuur was ongeveer 85% zo netjes, en het gebruikte af en toe patronen die technisch correct maar niet idiomatisch waren voor het framework dat ik gebruikte. Maar het deed iets wat het 3B-model absoluut niet kon: het redeneerde over de relaties tussen bestanden in plaats van elk bestand geïsoleerd te behandelen.

De afweging is snelheid. Terwijl het 3B-model in 2 seconden reageerde, nam het 32B-model 8-15 seconden per reactie, en complexe bewerkingen over meerdere bestanden konden 30+ seconden duren. Op mijn RTX 4090 met 24GB VRAM gebruikte het bijna alles wat beschikbaar was. Als je met minder VRAM werkt, verwacht kwantiseringsoverhead en nog langzamere inferentie.

De parallelle sub-agentfunctie verraste me hier het meest. Ik zette twee sub-agents op — één die de API van een npm-pakket onderzocht en één die de integratiecode schreef. Beide draaiden gelijktijdig via het lokale model. De coördinatie was niet perfect (de onderzoeksagent produceerde soms samenvattingen die de codeeragent verkeerd interpreteerde), maar het feit dat het überhaupt werkte op een lokaal model dat draait op consumenten-hardware imponeerde me oprecht.

De Echte Claude Sonnet: Nog Steeds de Benchmark

Na twee weken met lokale modellen schakelde ik voor een dag terug naar echte Claude Sonnet. Het verschil was direct merkbaar op drie gebieden:

Complexe redeneerketens. Een taak die vereiste dat je bedrijfslogica begreep, deze koppelde aan databaseschemawijzigingen, migraties genereerde, modelrelaties bijwerkte, en API-responses aanpaste — Claude Sonnet behandelde dit als één coherente gedachte. De lokale modellen hadden constante begeleiding nodig bij elke stap.

Nuance in codekwaliteit. Claude Sonnet schrijft niet alleen werkende code. Het schrijft code die de conventies volgt van het specifieke project dat het bekijkt. Het pikt patronen op in je bestaande codebase en spiegelt deze. De lokale modellen schreven generiek correcte code die vaak aanvoelde alsof die van een ander project kwam.

Foutherstel. Als iets niet werkte, analyseerde Claude Sonnet de fout, traceerde die terug naar de oorzaak, en loste hem op — vaak anticiperend op secundaire problemen. De lokale modellen hadden de neiging het oppervlaktesymptoom te repareren en een nieuw probleem stroomafwaarts te creëren.

Dat gezegd hebbende — en dit is het deel dat me bleef bezighouden — voor waarschijnlijk 40-50% van mijn dagelijkse coderingstaken was het lokale 32B-model goed genoeg. Niet perfect. Geen vervanging. Maar goed genoeg dat ik geen tijd of kwaliteit verloor in de output.

Dit roept de echte vraag op waar ik nog steeds mee worstel.

De Eerlijke Afwegingen Die Niemand Wil Bespreken

Ik heb een dozijn berichten gezien die beweren dat je je Claude-abonnement "volledig kunt vervangen" met lokale modellen. Dat is ofwel oneerlijk of geschreven door iemand die Claude Code niet voor serieus werk gebruikt. Laat me direct zijn over de beperkingen.

De kwaliteit van toolgebruik varieert enorm. De kracht van Claude Code komt van zijn vermogen om tools te gebruiken — bestanden lezen, opdrachten uitvoeren, codebases doorzoeken, meerdere bestanden atomisch bewerken. De officiële Claude-modellen werden specifiek getraind en verfijnd voor dit toolaanroepgedrag. Lokale modellen ondersteunen het API-formaat voor toolaanroepen, maar hun daadwerkelijke toolgebruik is minder betrouwbaar. Ik zag het 3B-model ongeveer één keer per sessie proberen een bestand te bewerken dat niet bestond. Het 32B-model was beter maar riep tools nog steeds af en toe aan met misvormde argumenten.

Beveiligingsgevoelig werk is een harde nee. Ik doe cybersecurityconsultancy. Codebeoordeling op kwetsbaarheden, automatisering van penetratietests, genereren van beveiligingsauditrapporten — ik zou nooit een 3B open-source model vertrouwen met dit werk. De faalmodi zijn te gevaarlijk. Een gemiste SQL-injectievector of een gehallucineerde "deze code is veilig"-beoordeling kan echte schade veroorzaken. Voor beveiligingswerk gebruik ik zonder uitzondering de echte Claude Sonnet.

Contextvenesterbeheer voelt anders aan. Zelfs met 32K context lijken lokale modellen eerdere context agressiever te "vergeten" dan de officiële modellen van Claude. Ik vermoed dat dit een combinatie is van verschillen in aandachtsmechanismen en kwantiseringsartefacten. De praktische impact: je moet belangrijke beperkingen vaker herhalen, en lange sessies degraderen sneller.

Modelupdates zijn jouw verantwoordelijkheid. Als Anthropic Claude verbetert, krijgt elke gebruiker de update direct. Met lokale modellen moet je releases bijhouden, nieuwe versies pullen, ze testen tegen je workflows, en af en toe regressions opvangen. Ik ben gebrand door een modelupdate die toolaanroepcompatibiliteit twee dagen brak voordat een fix werd uitgebracht.

Dit is mijn eerlijke beoordeling, en ik wou dat iemand me dit had verteld voordat ik begon: deze setup is een aanvulling, geen vervanging. Ik gebruik lokale modellen voor de onderste 40-50% van taken — scaffolding, boilerplate, eenvoudige automatisering, testgeneratie, documentatieconcepten. Ik gebruik echte Claude voor de bovenste 50-60% — architectuurbeslissingen, complexe refactoring, beveiligingsgevoelig werk, alles waarbij subtiele kwaliteitsverschillen zich ophopen tot echte problemen.

Die verdeling heeft mijn Claude API-gebruik bijna gehalveerd. Wat betekent dat hoewel ik nog steeds voor Pro betaal, ik meer waarde krijg uit elke dollar omdat ik alleen de moeilijke problemen naar het beste model stuur.

Dat is de mentaliteitsverschuiving. Denk niet "gratis vervanging." Denk "intelligente routering."

Geavanceerde Configuratie: Het Meeste Halen Uit Je Setup

Zodra de basissetup werkt, zijn er een paar optimalisaties die een betekenisvolle impact hadden op mijn workflow.

Persistente Modelconfiguratie

In plaats van het model bij elke start te specificeren, kun je het instellen als standaard:

# Voeg toe aan je .bashrc of .zshrc
export CLAUDE_MODEL=qwen2.5-coder:3b

# Dan gewoon starten met
claude

Ik onderhoud eigenlijk twee aliassen:

# In .zshrc
alias claude-local='source ~/scripts/claude-local.sh && claude --model qwen2.5:32b'
alias claude-fast='source ~/scripts/claude-local.sh && claude --model qwen2.5-coder:3b'
alias claude-pro='unset ANTHROPIC_BASE_URL && claude'

Drie commando's. Drie niveaus. Snel lokaal voor snelle taken, zwaar lokaal voor substantieel werk, en Pro voor het echte werk. Ik wissel er meerdere keren per dag tussen afhankelijk van wat ik doe.

Optimalisatie van Contextlengte

Standaard stelt Ollama mogelijk niet het volledige contextvenster bloot dat jouw model ondersteunt. Je kunt dit configureren in het Modelfile of tijdens runtime:

# Controleer de huidige configuratie van je model
ollama show qwen2.5-coder:3b

# Maak een aangepast Modelfile met uitgebreide context
cat << 'EOF' > Modelfile
FROM qwen2.5-coder:3b
PARAMETER num_ctx 32768
PARAMETER temperature 0.1
EOF

ollama create qwen-code-extended -f Modelfile

De temperatuur instellen op 0.1 (in plaats van de standaard) maakt codegeneratie meer deterministisch en minder creatief. Voor coderingstaken wil je consistentie boven creativiteit. Ik verhoogde het alleen naar 0.4 bij het genereren van documentatie of commit-berichten waar enige variatie helpt.

GPU-gebruik Monitoren

Houd je VRAM-gebruik in de gaten, met name met grotere modellen:

# NVIDIA GPU's
watch -n 1 nvidia-smi

# macOS met Apple Silicon
sudo powermetrics --samplers gpu_power -i 1000

Als je GPU geen VRAM meer heeft, valt Ollama stilzwijgend terug op CPU-inferentie, en responstijden gaan van seconden naar minuten. Ik heb sessies gehad waarbij ik dit niet merkte omdat de reacties nog steeds kwamen — alleen pijnlijk langzaam. Controleer je GPU-gebruik als dingen plotseling traag aanvoelen.

Verschillende Modellen Gebruiken voor Verschillende Deeltaken

Dit is experimenteel, maar het sub-agentsysteem van Claude Code staat theoretisch toe dat verschillende agents verschillende modellen gebruiken. In de praktijk routeren ze allemaal via hetzelfde Ollama-eindpunt, maar je kunt meerdere Ollama-instanties op verschillende poorten draaien met verschillende modellen geladen:

# Terminal 1: Zwaar model voor hoofdagent
OLLAMA_HOST=0.0.0.0:11434 ollama serve

# Terminal 2: Licht model voor sub-agents
OLLAMA_HOST=0.0.0.0:11435 ollama serve

Ik heb nog geen nette manier gevonden om Claude Code sub-agents naar een andere poort te laten routeren, maar dit is het soort optimalisatie dat de community waarschijnlijk in de komende maanden zal oplossen. De architectuur ondersteunt het in theorie.

Wat Er Daadwerkelijk Verbeterde in Mijn Workflow

Na twee weken hybride gebruik — lokale modellen voor routinewerk, echte Claude voor complexe taken — veranderden drie meetbare dingen.

Tokenkosten daalden met ongeveer 45%. Mijn Anthropic-dashboard toonde de daling duidelijk. Alle eenvoudige taken die voorheen echte tokens verbrandden — bestandsscaffolding, genereren van testskeletten, standaard API-endpoints, git-bewerkingen — draaiden nu op lokale rekenkracht. Ik stuurde minder verzoeken naar Anthropic, en de verzoeken die ik wél stuurde waren complexere taken die daadwerkelijk de redeneervermogens van Claude nodig hadden.

Iteratiesnelheid nam toe voor snelle taken. Geen netwerklatentie. Geen snelheidsbeperkingen. Geen wachten op de servers van Anthropic tijdens piekuren. Het 3B lokale model reageerde sneller dan welke cloud-API dan ook, en voor eenvoudige taken is snelheid belangrijker dan briljantie. Een TypeScript-interface genereren vanuit een JSON-payload? Daarvoor heb ik geen Sonnet-niveau intelligentie nodig. Ik wil dat het in minder dan 2 seconden gedaan is.

Ik werd bewuster over modelkeuze. Dit was het onverwachte voordeel. Voor dit experiment ging elke taak naar hetzelfde model tegen dezelfde kosten. Nu denk ik actief na over welk intelligentieniveau een taak vereist voordat ik ermee begin. Dat mentale kader — "is dit een 3B-taak, een 32B-taak, of een Sonnet-taak?" — maakte me een efficiëntere ontwikkelaar, los van de tooling. Ik begon vergelijkbare taken te groeperen. Ik werd beter in het opsplitsen van complex werk in eenvoudige deeltaken die lokaal konden worden afgehandeld.

De resultaten zijn niet dramatisch — ik claim geen 10x productiviteitsverbetering. Het eerlijke getal is misschien een verbetering van 15-20% in dagelijkse doorvoer, voornamelijk door latentie te elimineren bij routinetaken en bewuster te zijn over wanneer ik dure rekenkracht inzet.

Voor een setup die niets kost buiten de hardware die je al bezit, is dat een solide rendement.

De Modellen Die Het Nu Waard Zijn om te Proberen

Snel overzicht van wat daadwerkelijk goed is voor coderingstaken begin 2026:

Qwen 2.5 Coder Series — Mijn huidige aanbeveling. De coder-specifieke varianten zijn verfijnd op code en presteren substantieel beter dan de algemene Qwen-modellen voor ontwikkelingstaken. De 3B is geweldig voor snelheid, de 14B is een solide middenweg, en de 32B is echt indrukwekkend.

DeepSeek Coder V2 — Sterk alternatief, met name voor Python-zwaar werk. Ondersteuning voor toolaanroepen is goed. Contextverwerking is competitief met Qwen.

GLM 4 — De moeite waard om te testen als je taken gestructureerde gegevensmanipulatie of API-integratie omvatten. Het verwerkt JSON goed en de implementatie van functie-aanroepen is netjes.

CodeLlama varianten — Raken achter op de Qwen- en DeepSeek-opties voor de meeste taken, maar nog steeds haalbaar als je op beperkte hardware zit en iets nodig hebt dat goed draait bij 7B parameters.

Controleer modelcompatibiliteit met je hardware voordat je je vastlegt aan een download. Een model dat niet in je VRAM past en terugvalt op CPU-inferentie bespaart je niets — het kost je tijd.

Je 24-Uurs Uitdaging

Dit is wat ik wil dat je doet voor morgen op dit tijdstip. Niet volgende week. Niet "als je er eens aan toekomt." Vandaag.

Installeer Ollama. Pull qwen2.5-coder:3b. Stel de twee omgevingsvariabelen in. Start Claude Code met --model qwen2.5-coder:3b. Geef het dan één echte taak uit je huidige project — geen hello-world-oefening, maar iets wat je daadwerkelijk gedaan wil hebben. Een hulpfunctie. Een testbestand. Een configuratiemigratie.

Kijk wat er gebeurt. Let op waar het uitblinkt en waar het struikelt. Die ervaring uit de eerste hand zal je meer vertellen over of deze setup bij jouw workflow past dan welke blogpost dan ook — inclusief deze.

Als het 3B-model je imponseert (en voor eenvoudige taken zal het dat waarschijnlijk doen), pull dan de 32B en probeer dezelfde taak. De kwaliteitssprong zal je doen herdenken wat "goed genoeg" betekent voor lokale AI.

Ik draai nog steeds zowel lokaal als cloud. Ik vermoed dat ik dat nog lang zal doen. Maar de optie om voor de helft van mijn dagelijkse taken te zakken naar gratis lokale rekenkracht terwijl ik het premium model behoudt voor het werk dat het vereist — dat is geen compromis. Dat is gewoon slim gebruik van middelen.

En eerlijk gezegd? Het beste deel is niet het geld dat je bespaart. Het is de snelheid. Geen netwerkronde-trip. Geen snelheidsbeperkingen. Geen "Anthropic ervaart hoge vraag"-berichten om 14:00 uur als iedereen aan het prompten is. Gewoon instant, lokale, private AI-codering — op jouw voorwaarden, op jouw hardware, wanneer je maar wilt.

Aan jou de keuze.

Laten We Samenwerken

Wil je AI-systemen bouwen, workflows automatiseren, of je technische infrastructuur opschalen? Ik help je graag.

• Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io