Als je de basis onder de knie hebt, zit het verschil tussen een redelijk en een goed antwoord meestal niet in een betere prompt-zin. Het zit in de knoppen eromheen. Sonnet 5 geeft je een paar instellingen die de meeste mensen nooit aanraken, en juist daar valt winst te halen. Dit deel gaat over die knoppen.
Effort levels: hoe hard werkt het model
Sonnet 5 heeft vijf standen voor hoeveel moeite het in een taak steekt: low, medium, high, xhigh en max. High is de standaard. Het idee is dat je per taak kiest hoeveel rekenkracht en tijd je erin wilt steken.
In de praktijk komt het hierop neer. Low is voor simpel, herhalend werk waar je snelheid wilt: een lijstje opmaken, een korte tekst herschrijven, een bestand omzetten. Medium tot high is je dagelijkse werkpaard, goed voor vrijwel alles. Xhigh en max bewaar je voor de echte hoofdbrekers, een lastig stuk code of een analyse waar je geen denkfout in kunt gebruiken en die best even mag duren.
Een handig ijkpunt: Sonnet 5 op medium presteert ongeveer als de vorige versie op high, en Sonnet 5 op high als de vorige op zijn allerhoogste stand. Je krijgt dus meer denkdiepte voor dezelfde of een lagere instelling dan je gewend was. Zet niet alles standaard op max. Dat kost tijd en geld zonder dat je er voor de meeste taken iets voor terugkrijgt.
Sturen op lengte
Sonnet 5 bepaalt zelf hoe lang een antwoord wordt. Een simpele vraag krijgt een kort antwoord, een open vraagstuk een uitgebreider. Meestal klopt die inschatting, en dan hoef je niets te doen.
Maar soms wijkt je behoefte af van wat het model verwacht. Dan moet je het expliciet zeggen, en wel concreet. “Wees beknopt” is vaag. “Antwoord in maximaal drie zinnen” of “geef me een volledige uitwerking van minstens 800 woorden” is duidelijk. Omdat Sonnet 5 letterlijker luistert, werkt zo’n concrete instructie ook echt. Vraag je om drie zinnen, dan krijg je drie zinnen.
Een veelgemaakte fout: mensen klagen dat antwoorden te lang of te kort zijn, maar zeggen nergens wat ze wel willen. Benoem het. De lengte zit nu in jouw handen, dus gebruik die.
Verificatieloops: laat het zijn eigen werk nakijken
Dit is de techniek met het grootste effect, en de minst gebruikte. Het idee: geef Claude een manier om te controleren of zijn eigen output klopt, en de kwaliteit gaat merkbaar omhoog.
Een voorbeeld. Vraag je om een berekening, voeg dan toe: “Controleer je antwoord daarna door de som om te keren en te kijken of je weer op de begingetallen uitkomt.” Of bij een tekst: “Loop na of elke claim in dit stuk klopt met de bron die ik je gaf, en markeer wat je niet kunt verifiëren.” Bij code: “Schrijf eerst een paar tests die zouden falen als de oplossing fout is, draai ze, en pas je code aan tot ze slagen.”
Wat je in feite doet, is het model een meetlat geven waarlangs het zichzelf kan leggen. Zonder die meetlat levert het iets op dat plausibel klinkt. Mét die meetlat levert het iets op dat het ook echt heeft getoetst. Het verschil is groot, en het kost je één extra zin in je prompt.
Context management: stop met jezelf herhalen
Als je merkt dat je in elk gesprek dezelfde achtergrond opnieuw uitlegt, ben je tijd aan het verspillen. Wie je bent, hoe je schrijft, welke afspraken er gelden, dat hoeft het model maar één keer te weten.
In Claude Code doe je dat met een bestand dat CLAUDE.md heet: je zet je context, voorkeuren en regels erin, en het model leest dat automatisch mee bij elke opdracht. In de gewone Claude-app kun je hetzelfde bereiken met projectinstructies of een vaste tekst die je vooraan plakt. Het principe is hetzelfde: schrijf de context één keer op, op een plek die meereist, in plaats van hem telkens te herhalen.
Behandel zo’n bestand als een levend document. Merk je dat het model steeds dezelfde fout maakt of een voorkeur van je negeert? Zet de correctie erin. De volgende keer weet het het al. Na een paar weken heb je een instructie die jouw manier van werken kent, en dat scheelt in elk gesprek.
Je oude prompts bijwerken
Je prompts van de vorige versie blijven werken, maar een paar dingen kun je nu schrappen of aanscherpen.
Schrap de handmatige denk-instructies. Vroeg je het model expliciet om “eerst goed na te denken” via de oude extended-thinking-instelling? Dat is niet meer nodig en geeft via de API zelfs een foutmelding. Het denkt nu zelf.
Haal de temperatuur-instellingen weg. Werkte je via de API met instellingen als temperature of top_p om de output meer of minder voorspelbaar te maken? Sonnet 5 accepteert die niet meer en geeft een foutmelding als je ze meestuurt.
Maak je vage prompts concreter. Plekken waar je vroeger leunde op het invullingsvermogen van het model, vraag je nu beter expliciet uit. Het raadt minder, dus zeg meer.
En als je via de API werkt: hou er rekening mee dat dezelfde tekst nu in ongeveer dertig procent meer tokens wordt geteld door een nieuwe tokenizer. Dat heeft gevolgen voor je kosten en hoeveel je in één keer meegeeft. Daarover meer in het volgende deel.
Wat het kost, en niet alleen in geld
Een hoge effort-stand laat het model langer en harder rekenen. Dat kost meer geld, en het kost ook meer energie. Voor één vraag merk je dat niet, maar als je standaard alles op de zwaarste stand zet, telt het op, voor je rekening en voor het stroomverbruik erachter. Dezelfde gedachte bij de nieuwe tokenizer: dezelfde tekst telt nu zwaarder, dus een gewoonte als “ik gooi voor de zekerheid de hele map er maar in” is duurder en verspillender dan het lijkt. De middenstand is niet alleen goedkoper, het is ook de zuinigere keuze. Pak de zware stand waar hij echt nodig is, niet uit gemak.
De volgende stap
Met effort levels, sturen op lengte en verificatieloops haal je er al merkbaar meer uit. Met een goed contextbestand stop je met jezelf herhalen. Dat is voor de meeste gevorderde gebruikers ruim voldoende.
Wil je echt tot de bodem? In het laatste deel ga ik naar de power-user-aanpak, met de tips van de maker van Claude Code, parallelle sessies, en hoe je kiest tussen Sonnet 5 en het zwaarste model.
Lees verder in deel 4: expert prompting met Claude Sonnet 5.