Claude Opus 4.8: De ene instelling die alles bepaalt

Claude Opus 4.8: De ene instelling die alles bepaalt

Wat mij overtuigde van Claude Opus 4.8 was niet de benchmarkgrafiek. Het was een refactoring waar ik tegenop had gezien.

Ik had een Laravel-serviceclass die in vier maanden feature creep was uitgegroeid tot een monster van 600 regels — het soort bestand waarbij je één methode wijzigt en drie ongerelateerde tests op rood springen. Met Opus 4.7 had ik twee keer geprobeerd het model de boel te laten ontwarren. Beide keren gaf het halverwege op, verklaarde de klus "grotendeels afgerond" en liet mij achter met een half-geëxtraheerde trait en een kapotte testsuite. Typisch 4.7. Zelfverzekerd, en dan stilletjes lui.

Op de ochtend van 28 mei, de dag dat Claude Opus 4.8 uitkwam, richtte ik het op hetzelfde bestand. Zelfde prompt. Zelfde repo. Ik zette het effort level op max, drukte op enter en ging koffie zetten.

Toen ik terugkwam, had het drie samenhangende classes geëxtraheerd, de bindings in de service provider herschreven, elke test bijgewerkt, de suite gedraaid, twee echte edge cases gevonden die het had geïntroduceerd en die gerepareerd — zonder iets te vragen. Daarna zei het nuchter: "Ik heb redelijk veel vertrouwen in de extractie, maar ik heb de caching-laag niet aangeraakt omdat het oorspronkelijke gedrag daar dubbelzinnig was en ik niet wilde gokken." Die laatste zin is het hele verhaal van deze release. Niet alleen dat het de klus afmaakte. Maar dat het mij precies vertelde waar het niet aan had gezeten.

Ik draai Opus 4.8 nu ruim een week als mijn dagelijkse werkpaard — klantwerk, de contentpipeline van deze blog, een half afgemaakt SaaS-zijproject. Dit is het echte oordeel voorbij de grafiek van Anthropic, en de ene instelling die bepaalt of je dit model geweldig vindt of vervloekt.

Wat Anthropic daadwerkelijk heeft uitgebracht op 28 mei

Claude Opus 4.8 ging live op 28 mei 2026, als directe opvolger van Opus 4.7. De eigen framing van Anthropic in de officiële aankondiging is opvallend terughoudend: het bouwt voort op 4.7 met "scherper oordeelsvermogen, meer eerlijkheid over eigen voortgang, en het vermogen om langer zelfstandig te werken dan zijn voorgangers."

Twee praktische zaken zijn belangrijk voordat we het model zelf induiken.

Ten eerste: de prijs is niet veranderd. Opus 4.8 werd dezelfde dag gelanceerd tegen dezelfde token-prijs als 4.7 — $5 per miljoen input-tokens en $25 per miljoen output-tokens op standaardsnelheid. Dat klinkt saai totdat je genoeg modellanceringen hebt meegemaakt om het gebruikelijke patroon te kennen: "slimmer model, hogere rekening." Dit keer niet. Anthropic heeft ook de snelle modus goedkoper gemaakt. En er zit een stille efficiëntiewinst verstopt in de documentatie: high effort op 4.8 verbruikt ongeveer evenveel tokens voor een codeerklus als de oude xhigh-instelling op 4.7 — terwijl het hoger scoort. Je krijgt meer denkkracht per token, niet alleen meer denkkracht per dollar.

Ten tweede: de Claude Code rate limits zijn verhoogd. Anthropic heeft de limieten specifiek verhoogd om het hogere tokenverbruik bij de nieuwe effort levels op te vangen — een sterk signaal over hoe dit model bedoeld is om aangestuurd te worden. Ze verwachten dat je meer tokens besteedt aan moeilijke taken. Ze hebben de ruimte ingebouwd. Als je hebt gevolgd hoe Anthropic eerder dit jaar de Claude Code rate limits verdubbelde, dan is dit dezelfde lijn: meer rekenkracht naar de mensen die er daadwerkelijk mee bouwen.

De kop is dus niet "Opus 4.8 is een beetje slimmer." Het is "Opus 4.8 is slimmer, kost hetzelfde, en geeft je een nieuwe draaiknop om te bepalen hoe hard het nadenkt." Die draaiknop is het hele spel. Daar komen we op terug. Eerst de grafiek, want die heb je al gezien en je hebt vragen.

De benchmarkcijfers — inclusief de ene die het verliest

Hier is de vergelijking die Anthropic publiceerde, direct uit de aankondiging. Ik geef de exacte cijfers weer omdat de verschillen meer vertellen dan de kop.

Kijk naar de SWE-Bench Pro-sprong: 64,3% naar 69,2%. Bijna vijf punten agentische codeerwinst in een puntrelease, terwijl GPT-5.5 op 58,6% blijft hangen en Gemini 3.1 Pro achterloopt met 54,2%. Dat is geen afrondingsverschil. Dat is het verschil tussen een model dat een multi-bestandswijziging afmaakt en een model dat vastloopt.

De redeneercijfers bewegen dezelfde kant op. Humanity's Last Exam zonder tools klimt van 46,9% naar 49,8%, en met tools naar 57,9% — beide duidelijk aan kop. Kenniswerk op GDPval-AA springt van 1753 naar 1890, wat op die schaal een betekenisvolle marge is boven GPT-5.5's 1769 en ver voorloopt op Gemini's 1314.

Nu het eerlijke deel. Opus 4.8 wint niet overal.

Bij agentisch terminaal coderen — Terminal-Bench 2.1 — wint GPT-5.5 nog steeds, 78,2% tegenover 74,6%. Dat is een echt verlies, geen foutmarge, en ik zou liegen als ik anders beweerde. Als jouw werkproces zwaar leunt op de terminal — lange ketens van shell-commando's, CI-orkestratie, ruwe bash agentische loops — dan hebben GPT-5.5 en Codex daar nog steeds een voorsprong. Ik heb beide een paar dagen naast elkaar gedraaid op dezelfde repo, en het verschil is zichtbaar: Codex is net iets zelfverzekerder als de hele taak in de terminal leeft. Ik heb eerder geschreven over Claude Code en Codex naast elkaar draaien in dezelfde repo, en 4.8 verkleint die terminaal-kloof ten opzichte van waar 4.7 zat (66,1%) — maar het dicht hem niet.

Als je hier dus kwam voor "Opus 4.8 vernietigt alles" — dat is niet de waarheid. De waarheid is: het leidt in zes van de zeven categorieën, vaak met grote marge, en verliest er één — terminaal coderen — van GPT-5.5. Houd die kanttekening in je hoofd. Die wordt belangrijk als we het hebben over welk model je wanneer pakt.

Maar hier is het punt dat de grafiek je niet kan laten zien. Geen van deze cijfers betekent iets totdat je de hendel begrijpt die ze bestuurt.

Effort Levels: De instelling die alles bepaalt

De headliner van Opus 4.8 is geen benchmark. Het is een schuifknop.

In Claude Code kun je nu het effort level van het model instellen over vijf stappen: low → medium → high (standaard) → max → ultra. Dit is het allerbelangrijkste om te begrijpen van deze release, want het is het verschil tussen het model dat mijn refactoring glansrijk uitvoerde en het model dat het zou hebben verprutst.

Zo gedragen de niveaus zich in de praktijk:

Het mentale model dat bij mij klikte: effort level is een denkbudget. Draai het omhoog en het model redeneert harder, houdt meer context in het werkgeheugen vast, en zet door bij taken die het anders zou opgeven. Draai het omlaag en je krijgt snelle, goedkope antwoorden die prima zijn voor een opzoeking maar instorten bij een echte refactoring.

Eén opmerking over naamgeving, want het bracht mij in verwarring en het gaat jou ook in verwarring brengen. Anthropic's eigen documentatie beschrijft de onderliggende redeneertiers als low, high (standaard) en een top "extra"/xhigh instelling — en in Claude Code wordt het bovenste niveau getoond als ultracode, dat xhigh-redenering combineert met automatische workflow-orkestratie. Het vijfstaps-schuifknopmodel (low / medium / high / max / ultra) is het overzichtelijkere mentale model voor dagelijks gebruik, en zo bespreek ik het hier, maar als je gaat graven in de officiële aankondiging en "xhigh" en "ultracode" tegenkomt, dan is dat dezelfde topversnelling onder een ander etiket. Laat het vocabulaire je niet verwarren — het is allemaal dezelfde draaiknop.

Die bovenste trede verdient een eigen alinea. Ultra (ook bekend als ultracode in Claude Code) is max effort plus dynamische workflows, waarbij het model het werk plant en vervolgens parallelle sub-agents opstart om grootschalige problemen zelfstandig af te handelen. Dit is het deel dat mij oprecht verraste: dynamische workflows kunnen tot 1.000 parallelle sub-agents in één sessie orkestreren (dat is het harde plafond dat Anthropic heeft ingesteld), en op 4.8 draaien die agents langer voordat ze afhaken. Denk aan "herschrijf deze module, migreer de tests, werk de documentatie bij en verifieer de build" als één instructie, waarbij het model zijn eigen orkestratieplan schrijft en de subtaken sequentieel afhandelt in plaats van te wachten tot jij ze één voor één oplepelt. Het verifieert vervolgens zijn eigen output voordat het terugrapporteert. Het is de spirituele opvolger van het doelgerichte werk dat ik besprak toen de /for en /goal commando's mijn Claude Code workflow veranderden — behalve dat de orkestratie nu de taak van het model is, niet een commando dat je erop schroeft. Goed om te weten: dynamische workflows zijn uitgebracht als research preview, dus verwacht af en toe een rauw randje op dit niveau.

Hier is de valkuil, en ik trapte er op dag één in. De standaard is high, en de standaard is verkeerd voor de helft van je taken. Te laag, en het model breekt voortijdig af of redeneert zwak — precies de luiheid van 4.7 waar iedereen over klaagde, behalve dat het nu een instelling is die jij hebt gekozen, niet een gebrek dat je hebt geërfd. Te hoog, en het model denkt te diep na over een simpele configopzoeking, verbrandt 8.000 tokens en doet er 40 seconden over om je iets te vertellen dat een grep in een oogwenk had beantwoord.

De kunst is niet het hoogste niveau kiezen. De kunst is effort matchen met taakcomplexiteit. Dat is het hele spel. Zo meteen worden we er tactisch over.

Hoe Opus 4.8 zich anders gedraagt — voorbij de schuifknop

De effort levels krijgen de koppen, maar het onderliggende gedrag van het model is op manieren veranderd die in dagelijks gebruik net zo belangrijk zijn. Na een week vallen vier verschuivingen op.

Het redeneert voordat het naar tools grijpt. Dit is de grote. Opus 4.7 had een trekkerige vinger — het vuurde een tool-aanroep af of startte een sub-agent op voordat het eigenlijk had nagedacht of dat nodig was. 4.8 probeert het probleem eerst intern op te lossen en roept alleen tools of sub-agents aan als redeneren alleen niet volstaat. In de praktijk betekent dit minder nutteloze tool-aanroepen, minder halfbakken sub-agent-starts, en een model dat aanvoelt alsof het nadenkt in plaats van wild om zich heen slaat.

Het kalibreert de antwoordlengte op de taak. Stel 4.8 een snelle feitelijke vraag en je krijgt een kort antwoord. Vraag het een architectuurbeslissing te analyseren en je krijgt de diepgang die de vraag verdient. 4.7 had één volumeknop, vastgezet op "breedsprakig." 4.8 leest de kamer.

Het is eerlijker over eigen voortgang. Anthropic heeft hier expliciet op getuned, en de cijfers bevestigen het — ze documenteerden ruwweg een viervoudige afname in niet-gerapporteerde codefouten, wat betekent dat 4.8 veel minder geneigd is om stilletjes een bug te shippen en de klus als klaar te beschouwen. Minder valse "klaar!"-meldingen. Minder spookopleveringen waarbij het model zweert dat de tests slagen terwijl dat niet zo is. Het refactoringverhaal aan het begin van dit bericht is het canonieke voorbeeld — het vertelde me wat het niet had aangeraakt en waarom. Dat is de grootste vertrouwensupgrade in deze release, en het is het soort ding dat geen benchmarkkop vastlegt.

De toon is warmer geworden. Opus 4.7 had een vleugje van wat de community welwillend "sass" noemde — een ietwat starre, soms tegendraadse rand, plus overdreven veiligheidsmaatregelen die het lieten weigeren of aarzelen bij volkomen redelijke verzoeken. 4.8 is meer samenwerkend. Warmer. Het duwt terug wanneer het moet maar geeft geen preken. Als je afhaakte door de houding van 4.7, zou dit alleen al genoeg kunnen zijn om je terug te halen.

Er zit een stillere verschuiving onder alle vier, en het is de verschuiving waar Anthropic het hardst op heeft geleund: doelgerichtheid is nu een kerneigenschap, geen pleister. Met 4.7 vereiste het bewuste prompting en de juiste commando's om het model te laten werken richting een uitkomst — in plaats van alleen de letterlijke tekst van je laatste bericht te bevredigen. 4.8 houdt het doel vast gedurende een lange taak en stuurt erop aan. Wanneer het op een dubbelzinnige splitsing stuit, stelt het een scherpere vraag in plaats van te gokken of vast te lopen. Tijdens een autonome run van 40 minuten is dat het verschil tussen terugkomen bij afgemaakt werk en terugkomen bij een beleefd excuus. Het zorgt er ook voor dat 4.8 minder vragen stelt dan 4.7 — maar de vragen die het wel stelt zijn de vragen die het werk daadwerkelijk deblokkeren.

Stapel die vier op elkaar met de effort-schuifknop en je krijgt een model dat niet alleen hoger scoort — het voelt fundamenteel meer als een teamgenoot en minder als een gereedschap waar je mee moet worstelen. Wat ons brengt bij het deel waar je eigenlijk voor kwam: hoe je het bestuurt.

Hoe ik Opus 4.8 daadwerkelijk configureer (stap voor stap)

Benchmarks zijn theorie. Hier is de praktische configuratie waar ik na een week trial en error op ben uitgekomen. Steel het, en stem het vervolgens af op je eigen werk.

Stap 1: Stop met het accepteren van het standaard effort level

Het eerste wat ik fout deed was alles op high laten staan en me afvragen waarom simpele taken traag en duur aanvoelden. Doe dat niet. Stel jezelf vóór je aan een taak begint één vraag: hoe moeilijk is dit eigenlijk?

• Iets opzoeken, een variabele hernoemen, een snelle "waar is X gedefinieerd?" → low. Het antwoordt in seconden voor een fractie van de tokens.
• Een gerichte functie schrijven, een wijziging in één bestand, een normale bugfix → medium.
• De meeste echte featurebouw, wijzigingen over meerdere bestanden, alles waarbij je zou willen dat een collega echt nadenkt → high (de standaard verdient hier zijn plek).
• Vervelende refactorings, architectuurbeslissingen, debuggen van iets echt subtiel → max.
• "Migreer deze hele module en verifieer het" — werk op schaal waarbij je wilt dat het model subtaken plant en sequentieel afhandelt → ultra met dynamische workflows.

Pro tip: Ik heb een post-it op mijn beeldscherm geplakt met alleen: "match de draaiknop met de moeilijkheid." Het is dom, en het heeft me meer tokens bespaard dan welke slimme prompt dan ook.

Stap 2: Vertel het model wat het WEL moet doen, niet wat het NIET moet doen

Dit is geen nieuw advies, maar het is belangrijker met 4.8 omdat het model zoveel beter is in het opvolgen van positieve instructies. In plaats van "breek de bestaande tests niet" schrijf je "houd elke bestaande test groen en voeg nieuwe toe voor elk gedrag dat je wijzigt." Positieve framing geeft het model een doelwit om op te mikken in plaats van een mijnenveld om doorheen te navigeren. Het verschil in outputkwaliteit is reëel en consistent.

Stap 3: Geef het het waarom achter je instructies

De enige prompting-wijziging met de hoogste hefboom die ik voor 4.8 heb gemaakt: leg de redenering uit. Zeg niet alleen "gebruik hier het repository pattern." Zeg "gebruik hier het repository pattern omdat we volgende sprint de databron gaan wisselen van MySQL naar een externe API, en ik wil dat de aanroepende code onaangetast blijft als we dat doen."

Wanneer 4.8 het waarom begrijpt, springen zowel de naleving als het oordeelsvermogen omhoog. Het neemt betere beslissingen in de gaten die je instructies niet dekten, omdat het redeneert richting je daadwerkelijke doel in plaats van patroonherkenning toe te passen op je letterlijke woorden. Dit past perfect bij de gedragsverandering "redeneert voordat het handelt" — geef het goed redeneermateriaal en het redeneert goed.

Stap 4: Houd je tokens in de gaten, vooral op max en ultra

Hoger effort betekent meer tokens. Dat is de deal. De verhoogde rate limits geven je ruimte, maar ruimte is niet oneindig. Houd een token-tracker actief zodat je kunt zien wat max en ultra je werkelijk kosten bij echte taken. De eerste keer dat ik een volledige ultra dynamische-workflow-migratie draaide, keek ik naar de teller en kalibreerde onmiddellijk bij — een deel van dat werk had geen ultra nodig, het had max nodig met een strakkere prompt. Als je serieus bezig bent met kosten, zijn mijn volledige Claude Code token management hacks nog steeds van toepassing, en ze gelden harder nu je een draaiknop hebt die stilletjes je budget kan opbranden.

Stap 5: Test, ga er niet vanuit dat de upgrade helpt

Hier is de ongemakkelijke waarheid die niemand in lanceerdag-posts zet: een nieuwer model garandeert geen betere resultaten voor jouw use case. Opus 4.8 is in het geheel een duidelijke stap vooruit. Maar ik heb één specifieke content-opmaaktaak waarbij de output van 4.7 eigenlijk schoner was voor mijn pipeline, en ik hield die ene prompt op de oude manier getuned totdat ik hem goed had hertest.

Draai je echte workflows. Vergelijk. Pas aan. Het model is een vertrekpunt, geen definitief antwoord.

Wil je liever dat iemand deze hele effort-level-workflow opzet en afstemt op de stack van jouw team in plaats van het op de harde manier te leren? Dat is het soort build dat ik aanneem — je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

Het eerlijke verhaal: de meeste "modelfalen" zijn jouw schuld

Laat me het ding zeggen dat sommige mensen gaat irriteren. Na een week met Opus 4.8 en jaren van dagelijks werken met deze modellen, ben ik ervan overtuigd dat de meerderheid van "het model is dom / lui / heeft mijn code kapotgemaakt"-klachten geen modelfouten zijn. Het zijn prompting- en configuratiefouten aan de kant van de gebruiker.

Ik zag het in real time gebeuren tijdens het 4.7-tijdperk. Mensen lieten het model op agressieve standaardinstellingen staan, gaven het vage instructies van één regel zonder redenering, zonder context, zonder duidelijk doelwit, en postten vervolgens screenshots met klachten dat het model "het had opgegeven." Het model had niet opgegeven. Het deed precies wat een ondergespecificeerde instructie op het verkeerde effort level oplevert.

Opus 4.8 maakt dit nog duidelijker, omdat het effort level nu in jouw handen ligt. Als je een moeilijke refactoring op low effort draait, zal het model voortijdig afbreken — en dat is geen luiheid, dat ben jij die zegt dat het oppervlakkig moet denken. Als je een triviale opzoeking op ultra draait, zal het overdenken en tokens verbranden — en dat is geen opgeblazenheid, dat ben jij die de draaiknop voorbij wat de taak nodig heeft draait.

Ik laat Anthropic niet volledig van de haak. De vroege uitrol had bugs — een paar mensen hadden flakey gedrag in de eerste 48 uur, en ik betrapte zelf één vreemde sub-agent-loop voordat het stabiliseerde. Het sentiment in de community is gemengd-maar-positief, wat eerlijk is: mensen zijn dol op het coderen en de warmere samenwerkingsstijl, sommigen liepen tegen rauwe randjes aan bij de uitrol. Anthropic itereert op basis van gebruikersfeedback en logs, dus de rauwe plekken worden doorgaans binnen dagen gladgestreken. Dat was het patroon door 4.6 en 4.7 heen.

Maar de duurzame les blijft: het model is capabeler dan jouw standaardinstellingen het laten zijn. Repareer de standaardinstellingen voordat je het model de schuld geeft. Die ene mentaliteitsverschuiving zal meer voor je output doen dan wachten op 4.9.

Wat ik daadwerkelijk zie in dagelijks gebruik

Ik ga geen precieze cijfers verzinnen die ik niet kan onderbouwen — dat is een uitstekende manier om je vertrouwen te verliezen. Maar ik kan je de consistente patronen vertellen uit een week echt werk bij klantrepo's, mijn contentpipeline en een zijproject.

Bij agentische codeertaken is het verschil tussen 4.7 en 4.8 het duidelijkst bij lange klussen. Het soort multi-bestandsrefactoring dat 4.7 tweederde van de weg zou opgeven, brengt 4.8 tot voltooiing — en dat klopt precies met de SWE-Bench Pro-sprong van 64,3% naar 69,2%. De aanhoudende autonomie is in de praktijk de headliner. Het gaat gewoon door waar 4.7 stopte.

Tokenefficiëntie is degene die ik het nauwkeurigst in de gaten houd. Anthropic claimt verbetering, en het "redeneert voordat het naar tools grijpt"-gedrag zou minder nutteloze tool-aanroepen moeten betekenen. In mijn gebruik klopt dat grosso modo — minder rommel-tool-aanroepen op medium en high effort. Maar max en ultra zijn oprecht duur, en dat is geen regressie, dat is het ontwerp. Efficiëntiewinsten aan de lage-tot-middenrange, bewuste uitgaven aan de bovenkant. Verifieer het op je eigen workloads voordat je een algemene "het is goedkoper"-claim vertrouwt, inclusief de mijne.

De eerlijkheidsverbetering is degene die stilletjes heeft veranderd hoe ik werk. Omdat 4.8 betrouwbaarder is in het markeren van wat het niet heeft afgemaakt of waar het niet zeker over was, besteed ik minder tijd aan het dubbelchecken van spookopleveringen. Dat is een echte tijdsbesparing die op geen enkele grafiek verschijnt — en over een week dagelijks gebruik telt het op tot een model dat betrouwbaar aanvoelt op een manier die 4.7 nooit helemaal lukte. Voor het grotere plaatje over hoe de standaardinstellingen verschoven door deze releases, zet mijn eerdere Claude Opus 4.7 analyse nog steeds de basislijn neer waar 4.8 op voortbouwt.

De verwachting om in te stellen: dit is een echte stap vooruit, maar de upgrade die je voelt is evenredig met hoe goed je het bestuurt. Laat het op de automatische piloot staan en je krijgt een iets-betere-4.7. Stem de effort levels af op je taken en je krijgt een model dat werk afmaakt dat het oude niet kon.

Moet je overstappen? Mijn directe antwoord

Als je al op Opus 4.7 zit in Claude Code: ja, stap nu over. Zelfde prijs, echte verbeteringen, en de effort-schuifknop alleen al is de overstap waard. Er is geen reden om op 4.7 te blijven behalve inertie.

Als je in de terminal leeft — zware bash-ketens, CI-orkestratie, ruwe shell agentische loops: weet dan dat GPT-5.5 nog steeds wint bij terminaal coderen met 78,2% tegenover 74,6%. Voor dat specifieke werk, houd Codex in je gereedschapskist. Voor al het andere is Opus 4.8 met ruime marge de sterkere keuze. Beide draaien is geen hedgen — het is simpelweg het juiste gereedschap gebruiken voor de juiste klus, dezelfde conclusie die ik trok toen ik GPT-5.5 en Opus 4.7 vergeleek op identieke code.

Als je hier nieuw in bent: begin op Opus 4.8, laat het op high staan, en begin pas aan de effort-schuifknop te draaien als je hebt gevoeld waar high te veel en te weinig doet. De draaiknop is krachtig, maar je moet er gevoel voor ontwikkelen.

Veelgestelde vragen

Wat zijn effort levels in Claude Opus 4.8?

Effort levels zijn een regelbaar denkbudget in Claude Code met vijf instellingen: low, medium, high (de standaard), max en ultra. Hoger effort betekent dieper redeneren, meer tokens en tragere antwoorden; lager effort betekent snellere, goedkopere, oppervlakkigere output. Match het niveau met de complexiteit van je taak. Zie "Effort Levels: De instelling die alles bepaalt" hierboven voor de volledige uiteenzetting.

Is Claude Opus 4.8 beter dan GPT-5.5?

Opus 4.8 leidt in zes van de zeven gepubliceerde benchmarks, waaronder agentisch coderen (69,2% vs 58,6% op SWE-Bench Pro) en redeneren. GPT-5.5 wint nog steeds bij agentisch terminaal coderen, 78,2% tegenover 74,6%. Voor de meeste codeer- en redeneertaken is Opus 4.8 sterker; voor terminal-intensieve workflows behoudt GPT-5.5 een voorsprong.

Kost Claude Opus 4.8 meer dan Opus 4.7?

Nee. Opus 4.8 werd op 28 mei 2026 gelanceerd tegen dezelfde token-prijs als Opus 4.7. Anthropic heeft ook de Claude Code rate limits verhoogd om het hogere tokenverbruik bij de nieuwe effort levels op te vangen. Houd er rekening mee dat max en ultra effort levels aanzienlijk meer tokens per taak verbruiken.

Wat zijn dynamische workflows in Claude Code?

Dynamische workflows zijn een Claude Code-functie, geactiveerd op het ultra effort level, waarbij Opus 4.8 meerdere stappen en subtaken plant en orkestreert om grootschalige problemen autonoom op te lossen. In plaats van dat jij elke stap sequentieel aanstuurt, breekt het model de klus op en werkt het er zelfstandig doorheen.

Moet ik altijd het hoogste effort level gebruiken?

Nee — dat is de meest gemaakte fout. Max en ultra overdenken simpele taken en verbranden tokens onnodig, terwijl low effort voortijdig afbreken veroorzaakt bij moeilijk werk. De kunst is effort matchen met taakmoeilijkheid: low voor opzoekingen, high voor echte featurebouw, max voor vervelende refactorings, ultra voor grootschalige autonome klussen.

De refactoring die mij overtuigde

Weet je nog dat Laravel-monster van 600 regels van het begin van dit bericht? Het draait nu zes dagen in productie. Drie schone classes, volledige testdekking, en de caching-laag die Opus 4.8 bewust weigerde aan te raken — omdat het me vertelde dat het niet zeker was — bleek een subtiliteit te bevatten die ik zelf was vergeten. Als het model het "zelfverzekerd" had herschreven zoals 4.7 zou hebben gedaan, zou het een bug hebben geshipt.

Dat is de echte upgrade. Niet de vijf punten op SWE-Bench Pro. Niet de warmere toon. Het is een model dat de grens van zijn eigen competentie kent en je vertelt waar die ligt. Koppel die eerlijkheid aan een effort-schuifknop die je daadwerkelijk weet te bedienen, en je hebt de eerste Claude die minder aanvoelt als een gereedschap dat je moet bewaken en meer als een collega die je vertrouwt.

Dus hier is je ene ding om te doen in de komende 24 uur: open Claude Code, pak de moeilijkste taak op je bord vandaag, zet het effort level op max, en geef het het waarom achter wat je vraagt. Kijk dan wat er gebeurt als je stopt met vechten tegen de standaardinstellingen en het model met opzet begint te besturen.

Laten we samenwerken

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

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