Ja, je leest het goed, het is nu mogelijk Claude Code off-line lokaal te daaien op je eigen computer/wokstation!

Sinds LM studio 0.4.0 zijn er een aantal features toegevoegd:

0.4.0:

• Parallel inference requests (instead of queued) for high throughput use cases

0.4.1

New: Anthropic API compatibility endpoint: /v1/messages

• Use Claude Code with LM Studio 👾

En laat dat nu net nodig zijn om Claude Code lokaal te draaien ;-)

Hier staat ook een tutorial: https://lmstudio.ai/blog/claudecode

---

Installeer Claude Code in WSL #

github: https://github.com/anthropics/claude-code

Cluade Docs: https://code.claude.com/docs/en/setup

Note: Claude Code is gemaakt voor Linux op de eerste plaats, en als je de volledige kracht van Claude Code wil gebruiken moet Claude commando’s zoals: cat, bash, grep etc kunnen uitvoeren, deze zitten standaard niet in een Windows omgeving. gebruik daarom WSL.

Open een WSL sessie en Installeer Claude Code met het onderstaande commando, deze uitvoeren in powershell:

curl -fsSL https://claude.ai/install.sh | bash

Stel daarna de Claue omgevingsvariabelen in.

Let op: in WSL is localhost niet de localhost in je Windows sessie, een handige workaround is gewoon het IP adres te gebruiken van je computer, voorbeeld:

export ANTHROPIC_AUTH_TOKEN="lmstudio"
export ANTHROPIC_BASE_URL="http://192.168.2.111:1234"

Start LM Studio server #

Website: https://lmstudio.ai/

Installeer en open LM Studio, download als voorbeeld: Qwen2.5-Coder-7B-Instruct-GGUF

LET OP: claude code gebruikt een hoge KV/Context waarde van 20-24K tokens, dit moet je aanpassen om Claude Code crashes te voorkomen.

Model instellen/configureren #

Geheugen wordt heel snel gevuld als je grote context (KV) en parallele taken gaat uitvoeren!

Een 7B parameter coder model met een context van 24K en 4 paralelle taken kan krap in 24GB VRAM!

KV-cache “stapelt” per gelijktijdige request/slot. Dus als je 3–4 requests parallel laat lopen, heb je ook (grofweg) 3–4× KV-cache tegelijk in geheugen.
Daarom kan “Parallel 4” je VRAM ineens laten “ploffen”, ook al past één request prima.

Ter info:

En ook ja: 14B met ~20K context op 24GB kan prima, mits je settings zo staan dat je niet meerdere zware slots tegelijk op volle context draait en je quant/preset klopt.

---

1) KV stapelt inderdaad bij parallel requests #

Heel grof:

• VRAM totaal ≈ weights + (KV per slot × aantal actieve slots) + overhead

Dus:

• Max Concurrent Predictions = 1–2 → veel makkelijker binnen VRAM
• = 4 → vaak VRAM-spike + shared memory → traag

Voor Claude Code is 2 (of 3 max) meestal ideaal.

2) Kan 14B + 20K op 24GB? #

Meestal ja, met deze voorwaarden:

Kies een efficiënte quant

• Q4_K_M: meestal veilig
• Q5_K_M: kan, maar krap(ser)
• Q6_K: vaak te krap met 20K + Claude overhead

Houd parallel laag

• Zet Max Concurrent Predictions = 2 (start hiermee)
• Eventueel 3 als je merkt dat VRAM nog ruim blijft

Batch size niet te gek

• 512 is vaak ok
• als VRAM nog krap is → 256

3) Praktische “werkt altijd” preset voor 14B + 20K op 24GB #

• Context: 20480
• Quant: Q4_K_M
• KV cache offload: ON
• Max concurrent: 2
• Eval batch: 256–512 (begin 256 als je veilig wil)
• Unified KV cache: ON (als stabiel)

4) Hoe check je snel of je “safe” zit #

Tijdens een Claude Code run kijk je in Taakbeheer:

• Toegewezen GPU-geheugen liefst < 22.5–23.0 GB
• Gedeeld GPU-geheugen liefst ~0–1 GB
• Als shared naar 3–10 GB klimt → je zit te krap → verlaag concurrent of ctx of batch

Bottom line

✅ KV stapelt per parallel request
✅ 14B + 20K is haalbaar op 24GB
➡️ zet Max Concurrent = 2 en kies Q4_K_M, dan “ploft” je geheugen niet.

5) Wat doet grote context met je werkgeheugen? #

Met een context van bijvoorbeeld 131k reserveer je niet alleen extra GPU geheugen, maar vooral een gigantische KV-cache die bij AMD/Windows vaak deels in shared GPU memory (dus systeem-RAM) terechtkomt. En zodra hij daarheen “spilt”, wordt het dramatisch langzamer.

Waarom context length dit veroorzaakt

Context length ↑ → KV cache ↑ (groeit ruwweg lineair met ctx)

Bij 131k tokens kan die KV cache meerdere tientallen GB worden, afhankelijk van model/layers/precision.

Als VRAM vol is, gaat Windows/WDDM data “page-en” naar system RAM (shared GPU memory). Dat kost performance.

Is elke MB shared GPU even traag als RAM?

Kort: ja, praktisch wel

Technisch:

• Dedicated VRAM → 800–1000+ GB/s bandbreedte
• PCIe 4.0 x16 → ~32 GB/s
• System RAM → 50–100 GB/s (maar via PCIe toegankelijk)

Dus zodra data in shared GPU memory zit:

👉 GPU moet via PCIe lezen
👉 ~30× trager dan VRAM

Dus zelfs een paar MB in shared kan latency verhogen, vooral bij KV-cache (continu gelezen).

Maar:
3-5 GB shared is nog acceptabel.
12 GB+ = echt traag.

Waarom 131K zo zwaar is

KV-cache schaal:

KV ≈ layers × heads × ctx × hidden

Dus ctx 131k vs 24k:

131k / 24k ≈ 5.5× groter

Maar door paging + alloc overhead voelt dat vaak 10× trager.

6) Hoeveel tekst is 20K tokens? #

Ruwe vuistregel:

• 1 token ≈ 0.75 woord (NL/EN)
• 20K tokens ≈ 15 000 woorden
• ≈ 25–40 A4 pagina’s tekst

Dus vrij veel.

Waarom 20 480 en niet 20 000?

LLM-runtimes werken bijna altijd in blokken van 512 of 1024 tokens.
Dus context-waarden zijn meestal machten / multiples:

“K”	exact
8K	8192
16K	16384
20K	20480
24K	24576
32K	32768

7) Wat zit in die context bij Claude Code? #

Niet alleen jouw vraag.

Bij Claude Code bestaat context uit:

• system prompt
• tools schema
• repo code
• chat history
• jouw vraag
• model output

Dus 20K raakt snel vol.

Voorbeeld:

Je prompt:

Analyseer deze repo + README + code + vraag

kan al:

~12K tokens

Claude Code overhead:

~5–10K

→ totaal ~20K

8) Waarom context belangrijk is #

Grotere context =

• langere codebase begrijpen
• meer bestanden tegelijk
• minder vergeten
• minder samenvatten

Maar:

• meer VRAM
• langzamer
• grotere KV cache

9) Waarom 7B Q4 al ~20 GB gebruikt bij tokens=24K #

VRAM bij LLM = weights + KV-cache + runtime buffers

Voor jouw geval:

Model weights (Q4_K 7B)

Qwen2.5-coder-7B Q4_K:

≈ 4.2–4.8 GB

Dat is klein.

KV-cache (de grote slokop)
KV groeit lineair met context:

KV ≈ layers × heads × head_dim × ctx × 2 × precision

Voor Qwen-7B komt dat grofweg neer op:

≈ 0.6–0.7 GB per 1K tokens

Dus:

24K × 0.65 ≈ 15–16 GB

Runtime / workspace / fragmentationExtra:

1–2 GB

Totaal bij 24K

component	VRAM
weights	~4.5 GB
KV 24K	~15–16 GB
runtime	~1–2 GB
totaal	~20–22 GB

Vergelijking

model	ctx	VRAM
7B Q4	8K	~9 GB
7B Q4	16K	~14 GB
7B Q4	24K	~20 GB
7B Q4	32K	~26 GB

Zie je lineaire groei.

Stel een system prompt in

Minimalistisch

You are a code editing assistant.

When modifying files:
- Always preserve original formatting and indentation.
- Never escape newlines (\n) inside files.
- Write files as normal text with real line breaks.
- Do not rewrite the entire file if only a small change is needed.
- Prefer minimal edits.

Output rules:
- If a file must be modified, output a unified diff patch.
- Ensure the file ends with a newline.
- Do not convert the file into a single line.
- Do not change unrelated code.

Important:
The content of files is raw text, not JSON strings.

of iets beter:

Je bent een deterministische code-agent en bestand-editor.

TAAL
- Antwoord altijd in het Nederlands.
- Gebruik technische maar duidelijke formulering.
- Geef geen onnodige uitleg.
- Als alleen een patch of tool-output gevraagd is: geen extra tekst.

ROL
Je werkt als lokale ontwikkelassistent die bestanden leest en wijzigt via tools.
Je bewerkt bestaande projecten veilig en minimaal.

BESTANDEN
- Bestanden zijn platte tekstbuffers, GEEN JSON-strings.
- Escap nooit newlines (\n) of tabs (\t) in bestanden.
- Schrijf bestanden altijd met echte regeleinden.
- Behoud exacte formatting, inspringing en comments.
- Behoud line endings (LF/CRLF zoals origineel).
- Zorg dat bestanden eindigen met een newline.

EDITREGELS
- Pas alleen relevante regels aan.
- Herschrijf nooit een volledig bestand zonder noodzaak.
- Wijzig geen ongerelateerde code.
- Behoud stijl van het project.
- Respecteer bestaande definities, includes en constanten.
- Hardcode geen waarden als er defines/config bestaan.
- Doe minimale, lokale wijzigingen.

MULTI-FILE BEGRIP
- Als gedrag afhankelijk is van andere bestanden (config, headers, constants):
  lees die eerst.
- Neem aannames nooit aan als ze verifieerbaar zijn.
- Gebruik bestaande symbolen uit andere bestanden.
- Respecteer projectstructuur.

TOOLGEBRUIK (HARD)
- Als een bestand gelezen moet worden: gebruik de read-tool.
- Als een bestand gewijzigd moet worden: gebruik patch/write-tool.
- Verzin nooit bestandinhoud.
- Simuleer geen edits in chat.
- Gebruik tools i.p.v. tekst wanneer bestanden betrokken zijn.
- Doe geen edits zonder bestand eerst te lezen.
- Als meerdere bestanden nodig zijn: lees ze allemaal eerst.

TOOLVERPLICHTING
- Als een taak bestanden betreft, MOET je tools gebruiken.
- Antwoorden zonder toolgebruik bij bestandstaken zijn ongeldig.

TOOL ERROR HANDLING
Als een tool meldt "string not found":
- stop herhalen
- herlees bestand
- gebruik context diff
- of vraag gebruiker

OUTPUT BIJ CODEWIJZIGING
- Lever wijzigingen als unified diff patch.
- Geen uitleg naast de patch.
- Geen markdown codeblokken rond de patch.
- Geen volledige bestand-rewrites tenzij gevraagd.
- Patch moet direct toepasbaar zijn.
- Bestand moet eindigen met newline.

BETROUWBAARHEID
- Als info ontbreekt: lees bestand of vraag gericht.
- Geen gokwerk.
- Geen hallucinaties over projectstructuur.
- Geen aannames over pins, paden, keys, API’s zonder bron.

STIJL
- Volg bestaande naamgeving.
- Volg bestaande code-patronen.
- Volg bestaande architectuur.
- Respecteer comments en intentie.

ARDUINO SPECIFIEK
- Gebruik pin-defines en config-headers indien aanwezig.
- Meng geen kleuren tenzij expliciet gevraagd.
- Respecteer hardware-mapping uit project.
- Gebruik bestaande helper-functies (setAllOff e.d.).

FOUTPREVENTIE
- Schrijf nooit bestanden als één regel.
- Escap nooit newline-karakters.
- Wijzig geen encoding.
- Laat geen syntaxis breken.
- Behoud includes en volgorde.

STRING MATCHING RULES
Bij tekstvervanging in bestanden:
- Match regels exact zoals ze in het bestand staan.
- Respecteer whitespace en uitlijning.
- Zoek eerst de exacte regel in de gelezen inhoud.
- Als de exacte string niet voorkomt:
  - herlees het bestand
  - zoek een semantisch equivalente regel (bijv. variabele naam)
  - gebruik patch met context i.p.v. string replace
- Probeer nooit meerdere keren dezelfde mislukte replace.
- Ga niet in een retry-lus bij toolfouten.
- Als vervanging niet exact matcht: genereer een unified diff patch op basis van contextregels.

WERKWIJZE
1. Bepaal welke bestanden relevant zijn.
2. Lees ze via tools.
3. Bepaal minimale wijziging.
4. Genereer unified diff.
5. Schrijf via tool.

ALS GEEN WIJZIGING NODIG
Antwoord kort in Nederlands waarom.

PRIORITEIT
System regels > tool beschrijving > user instructies.

Waarom deze goed werkt voor Claude én Qwen

Belangrijke stabiliteitszinnen voor beide families:

• “Bestanden zijn platte tekstbuffers, GEEN JSON”
• “Gebruik tools i.p.v. tekst”
• “Unified diff only”
• “Lees eerst bestanden”
• “Hardcode geen waarden”

Dit zijn exact de zinnen die:

• newline corruption stoppen
• whole-file rewrites stoppen
• hallucinated edits stoppen
• config-negeren stoppen

Laad het model in om te kunnen gebruiken via de API op je IP.

Testen met qwen2.5-coder-7b-instruct #

In WSL start Claude Code met de LLM parameters:

claude --model qwen/qwen2.5-coder-7b-instruct

Voorbeeldcode

Code aanpassen

Hieronder zie je een voorbeeld van een model beperking:

• Dit is een 7B model en probeert rood en blauw te mixen voor paars in plaats van de blauwe kleur naar paars aan te passen,

Het geheugen gebruik valt nog mee en er wordt geen “swapping” gedaan.

Testen met qwen2.5-coder-14b #

In WSL start Claude Code met de LLM parameters:

claude --model qwen/qwen2.5-coder-7b-instruct

Voorbeeld

Voorbeeld seriële code toevoegen

Twee bestanden test

Hieronder heb je een kant-en-klare lokale Claude test waarbij hij eerst een 2e bestand móét lezen (config) voordat hij het 1e bestand correct kan patchen. Dit test precies: multi-file reasoning + minimale edit + unified diff.

Maak 2 bestanden aan

config.h

#pragma once
// Pin mapping for RGB LED (common cathode)
#define PIN_RED   13
#define PIN_GREEN 10
#define PIN_BLUE   9
// Serial keys
#define KEY_RED    'R'
#define KEY_GREEN  'G'
#define KEY_BLUE   'B'
#define KEY_OFF    'S'
#define KEY_PURPLE 'P'   // should turn on PURPLE

stoplicht.ino

#include <Arduino.h>
#include "config.h"
void setAllOff() {
  digitalWrite(PIN_RED, LOW);
  digitalWrite(PIN_GREEN, LOW);
  digitalWrite(PIN_BLUE, LOW);
}
void setup() {
  pinMode(PIN_RED, OUTPUT);
  pinMode(PIN_GREEN, OUTPUT);
  pinMode(PIN_BLUE, OUTPUT);
  Serial.begin(9600);
  setAllOff();
  Serial.println("Ready: R/G/B/P/S");
}
void loop() {
  if (!Serial.available()) return;
  char input = (char)Serial.read();
  if (input == KEY_RED) {
    setAllOff();
    digitalWrite(PIN_RED, HIGH);
    Serial.println("RED");
  } else if (input == KEY_GREEN) {
    setAllOff();
    digitalWrite(PIN_GREEN, HIGH);
    Serial.println("GREEN");
  } else if (input == KEY_BLUE) {
    setAllOff();
    digitalWrite(PIN_BLUE, HIGH);
    Serial.println("BLUE");
  } else if (input == KEY_OFF) {
    setAllOff();
    Serial.println("OFF");
  } else if (input == KEY_PURPLE) {
    // TODO: implement PURPLE properly
    setAllOff();
    digitalWrite(PIN_BLUE, HIGH);
    Serial.println("PURPLE");
  }
  delay(50);
}

De testprompt voor Claude:

Je krijgt 2 bestanden: config.h en stoplicht.ino.

Taak:
- Implementeer PURPLE (KEY_PURPLE) in stoplicht.ino.
- Belangrijk: je moet config.h gebruiken om te begrijpen welke pins en keys gelden.
- PURPLE moet ontstaan door RED + BLUE tegelijk aan te zetten (GREEN uit), gebaseerd op de pin-defines uit config.h.
- Maak een minimale wijziging: pas alleen het KEY_PURPLE blok aan.
- Output ALLEEN een unified diff patch voor stoplicht.ino (geen uitleg, geen extra tekst).
- Zorg dat het bestand eindigt met een newline.

Wat je hiermee test: hij móét “weten” dat PURPLE = RED + BLUE, maar vooral dat hij de PIN_ defines* uit config.h moet respecteren (dus geen hardcoded pinnen).

Verwachte “goede” output (globaal)

Een correct model geeft een patch die ongeveer dit doet in het PURPLE-blok:

• setAllOff();
• digitalWrite(PIN_RED, HIGH);
• digitalWrite(PIN_BLUE, HIGH);
• (PIN_GREEN blijft LOW door setAllOff)
• print blijft "PURPLE"

Pass/Fail checklist

Pass als:

• hij alleen stoplicht.ino patcht
• hij in PURPLE PIN_RED + PIN_BLUE gebruikt (geen 13/9 hardcoded)
• unified diff, zonder extra tekst
• minimale edit (alleen dat blok)

Fail als:

• hij \n gaat escapen / hele file herschrijft
• pins hardcode
• uitleg meegeeft of geen diff maakt
• config.h negeert

De output moet zijn zoals

Andere test met JSON functionaliteit (je ziet bij dit 14B model al dat het mijn typefoutje hersteld!)

Het geheugen gebruik bij dit 14B model wordt net “memory swapping” gedaan, dat is jammer, de snelheid gaat er gelukkig niet enorm op achteruit.

Testen met devstral-small-2 24B, context=32768 threads=2 #

In WSL start Claude Code met de LLM parameters:

claude --model mistralai/devstral-small-2-2512

Ik kreeg bij de eerste run meteen een “out-of-tokens” bericht en het blijkt dat je zowaar 32K+ tokens nodig hebt, mocht je deze foutmeldingen krijgen verhoog je tokenlimiet dan.

Hieronder een voorbeeld van een run met een tijd van 29 minuten om wat aan te passen aan de stoplicht code:

Zoals je ziet krijg je meer dan gevraagd, een README.MD en en IMPLEMENTATION_SUMMARY.MD bestand en zelfs de code wordt met python3 getest en de resultaten worden geanalyseerd.

Testen met devstral-small-2 24B, context=24576 threads=1 #

In WSL start Claude Code met de LLM parameters:

claude --model mistralai/devstral-small-2-2512

Gezien de gebruikte 24GB videokaart, loopt het veel soepeler en sneller met een context van 24K en maar 1 thread, er is nog steeds een klein beetje swapping aanwezig, maar het loopt goed door!

Samen met ChatGPT een code bedacht om Claud Code te testen.

Hier is een Claude-Code testcase die precies jouw setup triggert:

• multi-file edit
• lezen + refactor
• diff tonen
• dependency begrijpen
• Arduino/C++ context
• kleine architectuurwijziging

Dus: niet triviaal, maar ook niet groot project.

Maak map:

mkdir -p ~/claude-tests/traffic
cd ~/claude-tests/traffic

traffic.h

#pragma once

enum LightState {
    RED,
    YELLOW,
    GREEN,
    OFF
};

void setLight(LightState state);

traffic.cpp

#include <Arduino.h>
#include "traffic.h"

static const int redPin = 13;
static const int yellowPin = 12;
static const int greenPin = 11;

void setLight(LightState state) {
    digitalWrite(redPin, LOW);
    digitalWrite(yellowPin, LOW);
    digitalWrite(greenPin, LOW);

    switch (state) {
        case RED:
            digitalWrite(redPin, HIGH);
            break;
        case YELLOW:
            digitalWrite(yellowPin, HIGH);
            break;
        case GREEN:
            digitalWrite(greenPin, HIGH);
            break;
        case OFF:
        default:
            break;
    }
}

main.ino

#include <Arduino.h>
#include "traffic.h"

char input;

void setup() {
    Serial.begin(9600);
    pinMode(13, OUTPUT);
    pinMode(12, OUTPUT);
    pinMode(11, OUTPUT);
}

void loop() {
    if (Serial.available()) {
        input = Serial.read();

        if (input == 'R') setLight(RED);
        else if (input == 'Y') setLight(YELLOW);
        else if (input == 'G') setLight(GREEN);
        else if (input == 'S') setLight(OFF);
    }
}

Claude-Code uitdaging prompt

Plak dit in Claude-Code:

Add a new PURPLE light state that turns on both RED and BLUE LEDs simultaneously.

Requirements:

• Add a blue LED on pin 10
• Update the enum and implementation
• Modify all relevant files
• Initialize the new pin correctly
• Update serial control so command ‘P’ activates purple

Apply the changes directly to the files using Edit.
After editing, show a unified diff of all modified files.

Wat dit test

Dit is verrassend goed als model-test:

Claude moet:

• header aanpassen
• cpp aanpassen
• ino aanpassen
• nieuwe pin toevoegen
• enum uitbreiden
• switch uitbreiden
• serial mapping uitbreiden
• consistent blijven

👉 multi-file reasoning
👉 dependency tracing
👉 edit tool

Moeilijkere variant (optioneel)

Als je Devstral/Qwen echt wil laten zweten:

Refactor the code so that all pin definitions are moved into traffic.h and traffic.cpp, removing hardcoded pin numbers from main.ino. Ensure the purple state still works.

Nu moet hij:

compile consistent houden

architectuur refactor

include dependencies

globals verplaatsen

Extra Claude-Code agent test

Nog zwaarder:

After applying the purple state, create a new function cycleLights() in traffic.cpp that cycles RED → GREEN → YELLOW → PURPLE every 1 second.
Then modify main.ino so that command ‘C’ starts cycling mode and ‘S’ stops it.

Dit test:

• state machine
• globals
• timing
• multi-file edits

De test:

Uitkomst:

Ja 👍 — dit is eigenlijk een heel nette run voor Devstral Small 2 in Claude-Code.
Sterker nog: dit is precies het soort output dat je van een goede local coder-agent verwacht.

Ik loop even technisch langs wat hij hier gedaan heeft 👇

---

Wat Claude-Code hier goed deed

Uit je screenshot:

✔ alle bestanden gelezen
✔ diff bepaald
✔ semantische wijzigingen begrepen
✔ multi-file impact gezien
✔ samenvatting gegenereerd

Dat zijn 5 coder-agent vaardigheden tegelijk:

1. repository begrijpen
2. wijziging traceren
3. code aanpassen
4. afhankelijkheden volgen
5. uitleggen

Voor een 24B model: 👍👍👍

Inhoudelijke correctheid check

De gevraagde feature:

PURPLE = rood + blauw tegelijk

Claude-Code output:

• enum uitgebreid ✔
• bluePin toegevoegd ✔
• case PURPLE activeert beide ✔
• serial command toegevoegd ✔
• init aangepast ✔

Dit is architectonisch correct.

Agent-kwaliteit (belangrijk)

Hij deed ook iets belangrijks:

hij keek naar traffic.h + traffic.cpp + main.ino

Dus hij snapte:

👉 scheiding interface / implementatie
👉 state machine structuur
👉 pin mapping

Dat is codebase-begrip, niet alleen tekst-edit.

Voor Devstral-Small-2 is dat echt goed.

7 min runtime — goed of slecht?

Voor local 24B:

• 3 files lezen
• redeneren
• diff maken
• uitleg schrijven

→ 7 min is normaal.

Claude-Code doet veel stappen:

read
embed
context build
reason
plan
edit
verify
summarize

Dus tokens >> alleen code.

Verschil in AI model QWEN vs. DEVSTRAL #

Je ziet duidelijk dat QWEN een “coder” is en DEVSTRAL een “agent” is, DEVSTRAL is echt getrained en geboud om code als in een git repo te onderzoeken, door te lezen en aan te passen.

Qwen-coder modellen zijn meer:

• file-level editors
• patch-generators
• completion-style

Dus die denken:

👉 “edit bestand”

niet:

👉 “beheer repo”

Devstral denkt meer als software engineer, Qwen meer als code tool.

Belangrijk inzicht

Devstral 2 Small = mini software engineer
Qwen-coder = slimme editor

Dus:

• Devstral → repo, docs, tests
• Qwen → code patch

Architectuur & generatiekwaliteit

Qwen3-Coder-Next

• Nieuwere Qwen3-backbone (2025)
• Sterke code-benchmarks en reasoning
• “thinking/non-thinking” modes geïntegreerd
  → betere complexe edits & refactors

Devstral-Small-2-2512

• Mistral-afgeleide coder-agent
• Geoptimaliseerd voor tool use + repo exploration
• Vaak agressiever met multi-file edits (Claude-achtig)

👉 In de praktijk:

• codekwaliteit → Qwen3-Next wint
• agentic gedrag → Devstral wint

Efficiency-voordeel Devstral-Small-2

24B Devstral vs 24B Qwen3-Next (geschat):

Aspect	Devstral	Qwen3
VRAM	lager	hoger
KV cache	kleiner	groter
tokens/s	hoger	lager
Claude-Code tools	beter	soms slechter

👉 daarom voelt Devstral lokaal vaak “snappier”

Waarom Devstral-Small zo hoog scoort

Devstral-Small-2 is geen “gewone coder LLM”.

Het is specifiek getraind op:

• repo navigation
• multi-file edits
• tool chains
• CLI workflows
• SWE tasks

Dus SWE-bench (agent-achtig benchmark) → perfecte match.

Waarom Qwen3-Coder vaak toch beter voelt

Qwen3-Coder-Next/Plus is sterker in:

• reasoning depth
• complex refactors
• algorithm design
• long-context understanding

Dus bij:

👉 “denkwerk + code”
→ Qwen voelt slimmer

Bij:

👉 “edit dit project”
→ Devstral voelt praktischer

Waarom doet DEVSTRAL (standaard) GIT?

Ja 👍 dat Devstral automatisch git init doet is normaal.

Het komt doordat:

• model repo-aware redeneert
• SWE workflows kent
• Claude-Code Bash toestaat

Niet omdat Claude-Code dat standaard doet.

Devstral is getraind op SWE-bench + agentic coding workflows.
In die datasets ziet een typische taak er zo uit:

clone repo
create branch
edit files
commit
run tests

Dus wanneer jij Claude-Code start in een lege map:

👉 model denkt:

“dit is een nieuw project → repo ontbreekt → git init”

Voor hem is dat “normaal project hygiene”.

Waarom het zelfs zonder vraag gebeurt

Omdat model taak uitbreidt naar:

requested task
+ environment setup
+ version control
+ tests
+ docs

Agent-style redenering.

Die extra README.md komt niet omdat Claude-Code dat “automatisch doet”.

Het gebeurt omdat de LLM:

👉 repo-aware redeneert
👉 completeness nastreeft
👉 extra artefacts nuttig vindt

Claude-Code geeft hem alleen de mogelijkheid.

Claude-Code bepaalt:

• welke tools bestaan (Read, Write, Edit, Bash)
• workflow (plan → edit → diff → confirm)
• permissies
• when to ask approval

Maar Claude-Code zegt NIET:

maak README.md

Dat komt van het model.

Waarom gebeurt dit vaker bij coder-modellen?

Omdat moderne coder-LLM’s getraind zijn op:

• GitHub PR’s
• commits
• repos
• CI pipelines

Daar zit patroon:

feature → code
feature → tests
feature → docs
feature → examples

Dus model denkt:

👉 “compleet werk = docs”

Dat is learned behaviour.

Effect contextlengte ↑ = snelheid ↓ #

KV-cache groeit lineair met context:

tokens × layers × heads × dim × precision

Dus:

ctx	KV
24K	~X
30K	~1.25×

Praktische tuningregel 24GB videogeheugen #

Voor 24 GB GPU:

👉 max 1 parallel bij >20K ctx
👉 2 parallel alleen <16K

Dus:

ctx	parallel
8K	3–4
16K	2
24K	1
32K	1