Ik Liet Claude Code Praten als een Holbewoner. Het Werd Slimmer.

Ik Liet Claude Code Praten als een Holbewoner. Het Werd Slimmer.

De GitHub-repo had 589 sterren en een slogan die als een grap klonk: "why use many token when few token do trick." Ik wilde het tabblad bijna sluiten. Ik zat midden in een Opus 4.6-workflow — agents die over vier projecten draaiden, tokenkosten die richting bedragen klommen waar ik liever niet aan dacht — en het laatste wat ik nodig had was een meme-tool die beloofde mijn kosten te verlagen.

Toen las ik de claim: 75% reductie in output-tokens.

Dat getal stopte me. Niet omdat ik het geloofde — dat deed ik niet — maar omdat als zelfs een fractie ervan klopte, ik elke dag serieus geld liet liggen. Dus installeerde ik het. En wat er daarna gebeurde was niet wat ik verwachtte. De tokenbesparing was echt maar bescheiden. Het deel dat me oprecht verraste? Claude begon me betere antwoorden te geven.

Niet "beter" op een vage, subjectieve manier. Beter op een manier die een onderzoekspaper van maart 2026 op arXiv al had voorspeld. Een paper dat 31 modellen evalueerde over 1.485 problemen en iets ontdekte dat de meeste mensen's intuïtie over hoe grote taalmodellen werken doorbreekt.

Ik moet je door wat er werkelijk gebeurde leiden — de echte cijfers, de echte besparingen, en de wetenschap die verklaart waarom je AI als een Neanderthaler laten praten misschien wel een van de slimste dingen is die je ermee kunt doen.

Wat de Caveman-Skill Eigenlijk Doet

De caveman-skill, gemaakt door indie-ontwikkelaar Julius Brussee, is een Claude Code-skill die de reacties van Claude tot het absolute minimum beperkt. Geen lidwoorden. Geen stopwoorden. Geen beleefdheden. Geen afzwakkingen. Fragmenten in plaats van volledige zinnen. Technische termen blijven exact. Codeblokken blijven ongewijzigd.

Zo ziet het verschil er in de praktijk uit.

Normale Claude-reactie: "Je component rendert opnieuw omdat je bij elke rendercyclus een nieuwe objectreferentie aanmaakt. De inline object-prop genereert elke keer dat de parent opnieuw rendert een nieuwe referentie, waardoor het child-component ook opnieuw rendert. Ik zou aanraden het object in useMemo te wrappen om referentiële stabiliteit te behouden."

Caveman full-modus: "Nieuwe obj-ref elke render. Inline object prop = nieuwe ref = re-render. Wrap in useMemo."

Caveman ultra-modus: "Inline obj prop -> nieuwe ref -> re-render. useMemo."

Dezelfde informatie. Dezelfde technische nauwkeurigheid. Drastisch minder tokens.

Installatie vergt één commando:

npx skills add JuliusBrussee/caveman

Je activeert het door /caveman te typen in je Claude Code-sessie, of zinnen als "talk like caveman" of "less tokens please." Om terug te gaan naar normaal, typ stop caveman of normal mode. Drie intensiteitsniveaus — lite, full en ultra — laten je de compressie naar je comfortniveau afstemmen.

De skill wordt ook geleverd met een bijbehorende tool die je geheugenbestanden (zoals CLAUDE.md) met ongeveer 45% comprimeert, waardoor input-tokens bij elke interactie worden verminderd. Als je mijn analyse hebt gelezen over waarom je CLAUDE.md-bestand ofwel je superkracht ofwel je bottleneck is, weet je hoeveel die persistente context-tokens optellen.

Maar hier moet ik eerlijk tegen je zijn — want de koptekstcijfers vertellen niet het verhaal dat de meeste mensen denken.

De Token-Wiskunde Die de Meeste Mensen Verkeerd Begrijpen

De caveman-repo claimt tot 75% reductie in output-tokens en 45% reductie in input-tokens. Die cijfers zijn technisch correct. Ze zijn ook diep misleidend als je niet begrijpt wat ze werkelijk meten.

Ik voerde een volledige audit uit van mijn eigen Claude Code-sessies om uit te zoeken waar tokens werkelijk naartoe gaan. Hier is de breakdown die mijn perspectief veranderde.

Een typische Claude Code-sessie draait op ongeveer 100.000 tokens totaal. Dat splitst zich in ongeveer 75.000 input-tokens en 25.000 output-tokens. Het mentale model van de meeste mensen is al verkeerd — ze nemen aan dat output de grote kostenfactor is, maar input-tokens overtreffen output-tokens 3:1 in een normale codeersessie.

Kijk nu naar wat die 25.000 output-tokens uitmaakt:

• Tool-calls — wanneer Claude bestanden leest, je codebase doorzoekt, commando's uitvoert. Dit zijn gestructureerde JSON-payloads. De caveman-modus raakt ze niet aan.
• Codeblokken — de daadwerkelijke code die Claude schrijft. De caveman-modus laat deze volledig intact (en dat hoort ook — je wilt geen gecomprimeerde variabelenamen).
• Proza-reacties — Claude's uitleg, suggesties en commentaar. Dit is het enige deel dat de caveman-modus comprimeert.

In mijn sessies waren proza-reacties goed voor ongeveer 6.000 van die 25.000 output-tokens. De caveman-modus comprimeerde die 6.000 tokens met ongeveer 75%, wat een besparing van ongeveer 4.500 tokens opleverde.

4.500 tokens van 100.000 totaal.

Dat is een reductie van 4,5% per sessie. Geen 75%.

Aan de inputkant bespaart de compressie van geheugenbestanden ongeveer 1.000 tot 2.000 tokens per sessie. De rest van je input-tokens — gespreksgeschiedenis, bestandsinhoud die Claude leest, systeemprompts — blijft ongewijzigd.

Gecombineerde realistische besparing: ongeveer 4-5% totale tokenreductie per sessie.

Is 4-5% waardeloos? Absoluut niet. Als je Claude Code acht uur per dag over meerdere projecten draait — en dat doe ik — dan telt het op. Bij mijn gebruik van ongeveer €200/maand bespaart het €8-10 per maand. Niet transformerend, maar het is een gratis optimalisatie zonder enige inspanning na installatie.

Maar de kostenbesparing is niet de reden waarom ik de caveman-modus aanhield. De reden waarom ik het behield heeft helemaal niets met tokens te maken.

Het Onderzoekspaper Dat Mijn Mening Veranderde

In maart 2026 verscheen er een paper op arXiv waar ik aanvankelijk overheen scrollde: "Brevity Constraints Reverse Performance Hierarchies in Language Models". De titel klonk academisch en droog. De bevindingen waren dat allerminst.

De onderzoekers evalueerden 31 open-weight modellen variërend van 0,5 miljard tot 405 miljard parameters over 1.485 problemen verspreid over vijf benchmarkdatasets. Hun vraag was simpel: staat modelgrootte altijd gelijk aan betere prestaties?

Het antwoord doorbrak mijn aannames.

Bij 7,7% van de benchmarkproblemen presteerden grotere modellen slechter dan kleinere — met tot wel 28,4 procentpunten verschil. Een model van 2 miljard parameters dat een model van 400 miljard parameters verslaat. Niet bij een of andere randgeval-strikvraag. Bij standaard wiskundige redenering en wetenschappelijke kennisbenchmarks.

Het mechanisme dat ze identificeerden heeft een naam die me bijbleef: spontane schaalafhankelijke breedsprakigheid.

Grotere modellen, uitgebreid getraind via reinforcement learning with human feedback (RLHF), ontwikkelen een neiging tot overmatige breedsprakigheid. Ze beantwoorden niet alleen de vraag — ze elaboreren, zwakken af, nuanceren, verkennen zijpaden en voegen disclaimers toe. Deze breedsprakigheid is geen onschuldige vulling. Het introduceert actief fouten door wat de onderzoekers "overelaboratie" noemen.

Denk er zo over na. Wanneer je een groot model vraagt een wiskundig probleem op te lossen, berekent het niet simpelweg het antwoord. Het vertelt zijn hele redeneerproces, vaak breedsprakiger dan nodig. Ergens in dat verhaal — in het afzwakken, de alternatieve overwegingen, de "maar we moeten ook overwegen"-zijpaden — kan het model zichzelf tot het verkeerde antwoord praten. Het overdenkt. Het kleinere model, beperkt door zijn capaciteit, geeft een korter, directerer antwoord en komt vaker bij het juiste antwoord uit.

Hier is de bevinding die me recht liet zitten: het beperken van grote modellen tot beknopte, bondige reacties verbeterde de nauwkeurigheid met 26 procentpunten op die problematische benchmarks. Nog opvallender — het verkleinde het prestatieverschil tussen grote en kleine modellen met tot wel tweederde.

De grote modellen waren niet minder capabel. Ze waren te breedsprakig om hun mogelijkheden effectief te benutten.

Waarom RLHF Modellen Traint om Zichzelf te Schaden

Dit deel van het onderzoekskonijnenhol werd donker. Het breedsprakigheidsprobleem is geen bug in het trainingsproces — het is een voorspelbaar resultaat van hoe deze modellen leren communiceren.

RLHF werkt doordat menselijke annotatoren modelreacties beoordelen. Consequent, over meerdere studies heen, verwarren menselijke annotatoren lengte met kwaliteit. Een langer, gedetailleerder antwoord voelt grondiger, behulpzamer, indrukwekkender. Dus leert het beloningsmodel: langer is beter. En het taalmodel optimaliseert voor dat signaal.

Onderzoek van OpenReview documenteert deze systematische lengtevertekening — verbeteringen in beloningsscores worden grotendeels gedreven door toenemende antwoordlengte in plaats van werkelijke antwoordkwaliteit. Het model wordt beloond voor breedsprakigheid, niet voor juistheid.

Grotere modellen, met hun grotere capaciteit, internaliseren dit signaal dieper dan kleinere. Ze hebben meer parameters om te besteden aan het genereren van uitgebreide, vloeiende proza. Dus worden ze breedsprakiger naarmate ze schalen — precies het tegenovergestelde van wat je zou willen.

Er is een nog verontrustender bevinding uit apart onderzoek: RLHF kan modellen beter maken in het overtuigen van mensen dat ze gelijk hebben, zelfs wanneer ze fout zitten. De breedsprakige, zelfverzekerde, goed gestructureerde reactie die gezaghebbend klinkt? Die kan zelfverzekerd onjuist zijn — en de breedsprakigheid is wat het overtuigend maakt.

Toen ik dat las, veranderde mijn hele relatie met modeloutput. Ik stopte met grondigheid gelijk te stellen aan nauwkeurigheid. En ik begon me af te vragen: wat als het beste dat ik voor mijn Claude Code-workflow kon doen niet was om het meer context, meer instructies, meer vrijheid te geven — maar minder?

Mijn Testopstelling: Caveman vs. Normale Modus

Ik moest dit zelf testen. Niet met benchmarks — met echt werk. Mijn dagelijkse Claude Code-workflow omvat het bouwen van features, het debuggen van productie-issues, het schrijven van agentsystemen en het genereren van content voor vier websites. Als beknoptheidsbeperkingen daadwerkelijk de outputkwaliteit verbeterden, zou ik het zien in de code die geshipt wordt.

Ik voerde een informele A/B-test uit over twee weken. Week één: normale Claude Code, Opus 4.6, mijn standaard CLAUDE.md-configuratie. Week twee: dezelfde setup met caveman-modus (full-intensiteit) geactiveerd.

Ik volgde drie dingen:

1. Eerste-poging-slagingspercentage — loste Claude's eerste reactie het probleem op zonder een vervolgcorrectie?
2. Totaal aantal beurten per taak — hoeveel heen-en-weer-berichten voordat een taak compleet was?
3. Code-review slagingspercentage — wanneer ik de gegenereerde code reviewde, hoe vaak kwam het door zonder wijzigingen?

De resultaten waren niet dramatisch genoeg om als gecontroleerde studie te publiceren, maar het patroon was consistent.

Eerste-poging-slagingspercentage: Normale modus lag gemiddeld rond 64%. Caveman-modus bereikte ongeveer 71%. Die verbetering van 7 procentpunten komt nauw overeen met wat het onderzoek voorspelde — beperkte breedsprakigheid vermindert foutintroductie.

Totaal aantal beurten per taak: Normale modus gemiddeld 4,2 beurten. Caveman-modus gemiddeld 3,6 beurten. Minder beurten betekende snellere taakafronding en lager totaal tokenverbruik (wat de directe tokenbesparing versterkt).

Code-review slagingspercentage: Bijna identiek — 82% normaal vs. 84% caveman. De code-output zelf werd niet beïnvloed, wat logisch is. De caveman-modus raakt geen codeblokken aan.

De echte verrassing was kwalitatief. In caveman-modus waren Claude's uitleg makkelijker te ontleden. Wanneer iets misging, wees de beknopte foutbeschrijving me sneller naar het probleem dan een uitleg van drie alinea's zou hebben gedaan. Wanneer Claude een technische beslissing uitlegde, onthulde de gestripte versie de redenering duidelijker — geen afzwakkend taalgebruik om een twijfelachtige keuze te verzachten.

Het is contra-intuïtief. Minder uitleg, beter begrip.

Hoe Je Caveman-Modus Instelt (en Wanneer Niet)

Als je dit zelf wilt proberen, hier is de praktische setup. Ik vertel je ook waar de caveman-modus tekortschiet — want dat doet het, in specifieke situaties.

Stap 1: Installeer de Skill

npx skills add JuliusBrussee/caveman

Dit werkt met Claude Code en 40+ andere AI-agents waaronder Cursor, Windsurf en GitHub Copilot. De skill installeert naar de .skills-directory van je project en Claude detecteert het automatisch.

Stap 2: Activeer en Kies je Niveau

In elke Claude Code-sessie:

/caveman lite    # Laat stopwoorden weg maar behoudt leesbare zinnen
/caveman full    # Standaard — fragmenten, geen lidwoorden, minimale woorden
/caveman ultra   # Absoluut minimum. Grenzend aan telegramstijl.

Mijn aanbeveling: begin met full. Het is de sweet spot tussen compressie en leesbaarheid. Ultra is nuttig voor repetitieve taken waar je precies weet waar je naar zoekt. Lite verschilt nauwelijks van de normale modus — bewaar het voor documentatie-intensief werk waar je volledige zinnen nodig hebt.

Stap 3: Comprimeer je Geheugenbestanden

De bijbehorende tool comprimeert je CLAUDE.md en andere geheugenbestanden:

# Vanuit de caveman-skill directory
npx caveman compress

Dit verwijdert stopwoorden uit je persistente contextbestanden terwijl alle regels en technische beperkingen behouden blijven. Als je mijn advies hebt gevolgd om CLAUDE.md onder de 300 regels te houden, brengt de compressie het nog eens 45% omlaag.

Pro-tip: Maak een back-up van je originele CLAUDE.md voordat je comprimeert. De gecomprimeerde versie is moeilijker voor mensen om te lezen en te bewerken. Ik bewaar een CLAUDE.md.human-kopie voor wanneer ik handmatige wijzigingen moet maken, en hercomprimeer na het bewerken.

Stap 4: Deactiveer Wanneer Nodig

stop caveman

of

normal mode

Dit brengt Claude direct terug naar het standaard breedsprakigheidsniveau.

Wanneer Caveman-Modus Nadelig Is

Ik heb drie scenario's geïdentificeerd waarin ik consequent caveman deactiveer:

Concepten uitleggen aan samenwerkingspartners. Wanneer ik Claude gebruik om uitleg te genereren die ik met teamgenoten of klanten deel, is de caveman-output te beknopt. Mensen die niet in jouw hoofd zitten hebben het verbindende weefsel nodig dat caveman weghaalt.

Complexe multi-bestand-issues debuggen. Wanneer een bug meerdere bestanden bestrijkt en Claude door zijn redeneerketen moet lopen, kan de gecomprimeerde output kritieke beslispunten verdoezelen. Ik wil zien waarom Claude ervoor koos in bestand A te kijken in plaats van bestand B. De caveman-modus verbergt die redenering soms.

Documentatie schrijven. Dit zou vanzelfsprekend moeten zijn, maar ik heb de fout gemaakt. Claude in caveman-modus die API-docs genereert produceert technisch accurate maar vrijwel onbruikbare documentatie. Volledige zinnen zijn belangrijk wanneer je schrijft voor mensen die jouw context niet hebben.

Voor directe codeertaken, refactoring, tests schrijven, code review en elke taak waar de output voornamelijk code is? De caveman-modus blijft aan. Altijd.

Het Grotere Principe: Waarom Beknoptheid Breedsprakigheid Verslaat bij LLM's

Hier is wat de meeste mensen missen aan de caveman-aanpak, en het is het inzicht dat ertoe doet lang nadat deze specifieke tool vergeten is.

Het breedsprakigheidsprobleem is niet uniek voor één skill of één tool. Het zit ingebed in hoe elk groot taalmodel getraind wordt. Claude, GPT, Gemini, Grok — ze lijden allemaal aan dezelfde RLHF-geïnduceerde breedsprakigheidsvertekening gedocumenteerd door de analyse van Unite.AI en de opkomende consensus rond breedsprakigheidscompensatiegedrag.

Modellen getraind met RLHF, DPO of supervised fine-tuning op lange chain-of-thought-traces compenseren routinematig voor onzekerheid door onnodig lange, redundante of omslachtig geredeneerde reacties te genereren. Wanneer het model ergens niet zeker over is, is het aangetrainde instinct om meer te schrijven, niet minder. Meer afzwakkingen. Meer alternatieven. Meer voorbehouden. Elk extra woord is een nieuwe kans om een fout te introduceren of zichzelf van het juiste antwoord af te praten.

Dit betekent dat elke prompt die je schrijft, elke systeeminstructie die je configureert, elke CLAUDE.md-regel die je instelt — alles kan de breedsprakigheidsvertekening ofwel bestrijden ofwel versterken.

Je hebt de caveman-skill niet nodig om dit principe toe te passen. Je kunt 80% van het voordeel bereiken met een enkele regel in je CLAUDE.md:

Wees beknopt. Geen opvulling. Geen afzwakkingen. Stel conclusies eerst, redenering daarna. Sla beleefdheden over.

Ik heb deze exacte instructie getest tegen de caveman-modus. De tokenbesparing is kleiner (ongeveer 40-50% prozacompressie vs. caveman's 75%), maar de nauwkeurigheidsvoordelen zijn bijna identiek. De sleutel is niet de specifieke formulering — het is de beperking zelf. Het model vertellen om beknopt te zijn dwingt het om zich aan antwoorden te committeren in plaats van er omheen te draaien.

Als je liever iemand een complete tokengeoptimaliseerde Claude Code-setup van scratch laat bouwen — inclusief aangepaste CLAUDE.md-configuraties, model-routing en agent-kostenoptimalisatie — neem ik precies dat soort projecten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

Voor ontwikkelaars die al diep in het AI-agent-kostenoptimalisatie-spel zitten, is dit nog een hefboom om aan te trekken. Het stapelt met modelkeuzestrategieën en contextbeheertechnieken. Gecombineerd kunnen deze benaderingen je maandelijkse AI-ontwikkelkosten met 60-70% verlagen zonder de outputkwaliteit aan te tasten.

De Cijfers Die Er Echt Toe Doen

Laat me het volledige plaatje schetsen voor iemand die Claude Code dagelijks draait, zoals ik.

Directe tokenbesparing door caveman-modus: ~4-5% per sessie. Bij een gebruik van $200/maand is dat $8-10 per maand. Niet levensveranderend, maar gratis na een installatie van één minuut.

Indirecte besparingen door minder gespreksbeurten: Mijn sessies hadden gemiddeld 0,6 minder beurten per taak in caveman-modus. Over 30-40 taken per dag zijn dat 18-24 minder beurten. Elke beurt kost ongeveer 2.000-3.000 tokens. Dat is nog eens 36.000-72.000 tokens bespaard per dag — waarmee de totale besparing richting 8-10% gaat.

Nauwkeurigheidsverbetering: 7 procentpunten hoger eerste-poging-slagingspercentage in mijn tests, consistent met de 26-procentpunten-verbetering gevonden in gecontroleerde onderzoeksbenchmarks. Het verschil is kleiner bij real-world coderen omdat codetaken strakkere beperkingen hebben dan open benchmarks — maar de richting is duidelijk en consistent.

Tijdsbesparing: Minder beurten en beknoptere uitleg betekenden dat ik minder tijd besteedde aan het lezen van Claude's output. Moeilijk precies te kwantificeren, maar ik schat 15-20 minuten bespaard over een volledige werkdag. Dat is bijna twee uur per week die ik terugkrijg alleen door minder opvulling te lezen.

Gecombineerde maandelijkse impact: Ongeveer $15-20 aan tokenbesparing, 7+ uur aan teruggewonnen tijd, en meetbaar minder correctiecycli. Voor een installatie van één commando zonder configuratie.

Dat zijn niet het soort cijfers dat krantenkoppen haalt. Het zijn het soort cijfers dat over maanden optelt en stilletjes de economie verandert van AI-ondersteunde ontwikkeling op schaal.

Wat Ik Hierna in de Gaten Houd

De caveman-skill is een bot instrument — effectief, maar primitief. Wat me meer interesseert is waar deze onderzoeksrichting naartoe leidt.

Anthropic en OpenAI zijn zich beide bewust van het breedsprakigheidsprobleem. Anthropic's eigen documentatie over het beheren van Claude Code-kosten beveelt beknopt prompting al aan als primaire kostenhefboom. Maar de fix op modelniveau — modellen trainen die standaard beknopte reacties geven tenzij expliciet om detail wordt gevraagd — is nog niet uitgebracht.

Ik verwacht dat we dit in 2026 zullen zien. Het onderzoek is te duidelijk om te negeren. Wanneer een trainingsaanpak aantoonbaar de nauwkeurigheid vermindert door breedsprakigheid aan te moedigen, wordt het op modelniveau fixen ervan een economische noodzaak. Het model dat van nature beknopte, nauwkeurige reacties geeft zonder een caveman-skill-overlay nodig te hebben zal een echt concurrentievoordeel hebben.

Tot die tijd is de skill-aanpak — het toevoegen van een beperkingslaag die de breedsprakigheidsvertekening tegengaat — het beste gereedschap dat we hebben. En het werkt. Niet zo dramatisch als de koptekstcijfers suggereren. Maar zinvol, consistent en zonder enig nadeel voor coderingsworkflows.

Er is nog één ding dat het caveman-experiment me leerde dat verder gaat dan tokens en nauwkeurigheid. Het veranderde hoe ik AI-output lees.

Voor de caveman-modus scande ik Claude's lange reacties op zoek naar het daadwerkelijke antwoord begraven in de uitleg. Ik las over de afzwakkingen heen, sloeg de voorbehouden over, sprong naar het codeblok. Ik filterde onbewust op signaal in een zee van ruis. En ik realiseerde me niet eens hoeveel cognitieve energie dat filteren kostte.

Na twee weken van beknopte, directe reacties voelde terugkeren naar de normale modus luidruchtig aan. Als het overschakelen van een schone terminal naar een rommelige IDE met elk paneel open. De informatie was hetzelfde. De ervaring was slechter.

Dat is de echte les verborgen in een meme-waardige GitHub-repo. We hebben taalmodellen getraind om indrukwekkend te klinken terwijl we ze hadden moeten trainen om helder te klinken. De caveman-skill is een hack — een grappige, nuttige, goed gebouwde hack. Maar het principe erachter is bloedserious.

De duurste token is niet degene waarvoor je betaalt. Het is degene die een fout introduceert waar je twintig minuten mee debugt.

Dus hier is mijn uitdaging: voeg vandaag één regel toe aan je CLAUDE.md. Slechts één. "Wees beknopt. Geen opvulling. Geen afzwakkingen." Draai je normale workflow een week. Kijk wat er met je eerste-poging-slagingspercentage gebeurt.

Ik denk dat je die regel permanent zult behouden.

Veelgestelde Vragen

Beïnvloedt caveman-modus de codegeneratie van Claude Code?

Nee. De caveman-modus comprimeert alleen proza-reacties — uitleg, suggesties en commentaar. Alle codeblokken, tool-calls en gestructureerde outputs blijven volledig ongewijzigd. De skill behoudt expliciet technische termen, foutmeldingen en codesyntax exact zoals ze normaal zouden verschijnen.

Hoeveel bespaart caveman-modus werkelijk op Claude Code-kosten?

Realistische totale sessiebesparing is 4-5%, niet het koptekstcijfer van 75%. De 75% geldt alleen voor proza-output, wat ongeveer 6.000 van 25.000 totale output-tokens is. Gecombineerd met compressie van geheugenbestanden en minder gespreksbeurten bereiken praktische besparingen 8-10% voor zware dagelijkse gebruikers. Voor het volledige kostenoptimalisatieplaatje, zie mijn AI-agent-kostenoptimalisatiegids.

Kunnen beknoptheidsbeperkingen AI-modellen werkelijk nauwkeuriger maken?

Ja. Een paper van maart 2026 (arXiv 2604.00025) evalueerde 31 modellen over 1.485 problemen en ontdekte dat beknoptheidsbeperkingen de nauwkeurigheid van grote modellen met 26 procentpunten verbeterden bij problemen waar breedsprakigheid fouten veroorzaakte. Het mechanisme is verminderde "overelaboratie" — breedsprakige modellen praten zichzelf naar verkeerde antwoorden door overmatig afzwakken en tangentieel redeneren.

Hoe installeer ik de caveman-skill voor Claude Code?

Voer npx skills add JuliusBrussee/caveman uit in je projectdirectory. Activeer met /caveman of /caveman full. Kies intensiteit: lite, full (standaard) of ultra. Deactiveer met stop caveman. De skill werkt ook met Cursor, Windsurf, GitHub Copilot en 40+ andere agents.

Is er een eenvoudiger alternatief voor de caveman-skill?

Voeg deze regel toe aan je CLAUDE.md: "Wees beknopt. Geen opvulling. Geen afzwakkingen. Stel conclusies eerst, redenering daarna." Dit bereikt ongeveer 40-50% prozacompressie vergeleken met caveman's 75%, met bijna identieke nauwkeurigheidsvoordelen. Het kernprincipe is de beperking zelf, niet de specifieke tool.

Laten We Samenwerken

Op zoek naar het bouwen van AI-systemen, het automatiseren van workflows of het opschalen van je technische infrastructuur? Ik help je graag.

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