Cursus
De geruchten over de volgende release van Anthropic gonzen al een paar dagen rond. Terwijl velen Claude Sonnet 5 verwachtten, komt de eerste release van het jaar in de vorm van Claude Opus 4.6.
Met een contextvenster van 1 miljoen tokens, adaptief denken, gesprekscompactie en een reeks toonaangevende benchmarks is Claude Opus 4.6 een verbetering ten opzichte van Opus 4.5. Zoals Anthropic het noemt: ze hebben hun slimste model geüpgraded. Naast het model lanceerde Anthropic ook agentteams in Claude Code en Claude in PowerPoint.
In dit artikel bespreken we alles wat nieuw is in Claude Opus 4.6: we bekijken de nieuwe functies, verkennen de benchmarks en onderwerpen het model aan de nodige praktijktests met meerdere hands-on voorbeelden.
Wil je meer weten over enkele van de nieuwste Claude-functies, bekijk dan onze gidsen voor Claude Cowork en Claude Code, evenals onze OpenClaw-tutorial. Voor een vergelijking met andere concurrenten, lees onze gidsen over Muse Spark vs Claude Opus 4.6 en GPT-5.4 vs Claude Opus 4.6.
Wat is Claude Opus 4.6?
Claude Opus 4.6 is het nieuwste large language model van Anthropic. Het volgt op Opus 4.5 en vormt een aanzienlijke upgrade van de ‘slimste’ modelcategorie van het bedrijf.
Volgens de releaseblog legt Anthropic meer nadruk op agentisch coderen, diepgaande redenering en zelfcorrectie. Dit betekent een verschuiving van actie naar volgehouden actie.
Opus 4.6 is ontworpen om zorgvuldiger te plannen, heeft betere samenhang over langere periodes en herkent fouten in zijn eigen werking. Dit alles zorgt ervoor dat Claude Opus 4.6 verschillende benchmarks aanvoert, waaronder de hoogste score op de Terminal-Bench 2.0-codevaluatie, en het verslaat alle andere grensmodellen op Humanity’s Last Exam.
Wat mij het meest opvalt, is het verbeterde contextvenster in Claude Opus 4.6. Met 1 miljoen tokens in de bèta komt het nieuwe model op gelijke hoogte met Gemini 3, wat betekent dat het meer informatie kan verwerken zonder de context uit het oog te verliezen.
Ondertussen heeft Anthropic de opvolger van Opus gepubliceerd. Ik raad aan om onze gids over Claude Opus 4.7 te lezen om up-to-date te blijven.
Wat is er nieuw in Claude Opus 4.6?
Er zijn verschillende opvallende nieuwe functies in Claude Opus 4.6, waarvan veel gericht zijn op agentische workflows. Laten we enkele kernpunten bekijken:
Agentteams
Agentteams zijn een verbetering ten opzichte van de ‘subagents’ die we in eerdere versies van Claude zagen. Met agentteams kun je meerdere, volledig onafhankelijke Claude-instanties opstarten die parallel kunnen werken. Eén sessie is de ‘lead’-agent die coördineert, terwijl ‘teamgenoten’ de daadwerkelijke uitvoering verzorgen.
Wat ik het interessantst vind, is dat elk teamlid zijn eigen contextvenster heeft, wat grondigere uitvoering mogelijk maakt. Elk teamlid kan ook rechtstreeks met anderen in het team communiceren.
Natuurlijk heeft deze functie een mogelijk nadeel: de kosten. Omdat elke agent een eigen contextvenster heeft, verbruik je al snel veel tokens. Daarom raadt Anthropic aan om dit in te zetten bij scenario’s met hogere complexiteit.
Gesprekscompactie
Een handige functie van Claude Opus 4.6 is contextcompactie. Deze kwaliteitsverbetering helpt problemen te voorkomen wanneer je lange workflows draait die het contextvenster vullen. Normaal loop je dan tegen een contextmuur aan waarbij de prestaties achteruitgaan.
Met gesprekscompactie kan Claude Opus 4.6 automatisch detecteren wanneer een gesprek een tokendrempel nadert en het bestaande gesprek samenvatten in een beknopt blok (een compactieblok).
Deze functie zou moeten helpen om de essentie van je interacties te bewaren en tegelijk ruimte vrij te maken om verder te werken. Als je van plan bent taakgerichte agents te gebruiken die lang moeten blijven draaien, kan dit ze op koers houden met een sterk verbeterd geheugen.
Adaptief denken en inspanning
Er zijn twee functies in Claude Opus 4.6 die bepalen of uitgebreid denken nodig is en hoe veel moeite het model daarin steekt.
Adaptief denken laat het model bepalen hoe complex je prompt is. Op basis van de eenvoud of complexiteit beslist het of uitgebreid denken nodig is. In plaats van een handmatige instelling voor het aantal tokens dat het daarvoor gebruikt, past Claude zijn budget aan op basis van de complexiteit van elke aanvraag.
Met de parameter ‘effort’ kun je instellen hoe gretig of terughoudend Claude is met het uitgeven van tokens. Hiermee kun je dus balanceren tussen tokenefficiëntie en hoe grondig de antwoorden zijn.
Wanneer je Claude Opus 4.6 in de API gebruikt, kun je deze parameters handmatig instellen. Bijvoorbeeld:
- Max effort: Claude gebruikt altijd uitgebreid denken, zonder beperkingen op de diepte.
- High effort: Met deze standaardinstelling denkt Claude altijd na en geeft het diepgaande redeneringen.
- Medium effort: Activeert matig denken en kan het denken overslaan bij de simpelste vragen.
- Low effort: Claude slaat denken over bij eenvoudige taken en minimaliseert nadenken ten gunste van snelheid.
Claude in PowerPoint
Onlangs bespraken we Claude in Excel, waarin we lieten zien hoe de add-on je kan helpen met uiteenlopende taken in een zijpaneel van je Excel-spreadsheet. Naast het verbeteren van de functionaliteit van deze tool kondigde Anthropic ook Claude in PowerPoint aan.
Deze integratie respecteert je diamodellen, lettertypen en lay-outs. Je kunt er een bedrijfsjabloon aan voeren en vragen om een specifieke sectie te bouwen, of een dia selecteren en vragen om dense tekst om te zetten in een native, bewerkbaar diagram.
De nadruk op het genereren van bewerkbare PowerPoint-objecten in plaats van alleen "plaatjes van dia’s" maakt dit een echte productiviteitstool en niet slechts een conceptgenerator.
Claude in PowerPoint is momenteel in research preview voor Max- en Enterprise-gebruikers.
Claude Opus 4.6 testen: hands-on voorbeelden
Veel van de hoofdclaims van Opus 4.6 draaien om zwaardere coderingstaken en diepere redenering. Deze vaardigheden rusten op een bepaald fundament: het vermogen om meerdere randvoorwaarden tegelijkertijd te houden, over veel stappen te redeneren en fouten te herkennen.
Met dat in gedachten hebben we Opus 4.6 onderworpen aan een reeks meerstaps logica-, wiskunde- en programmeeruitdagingen. We wilden kijken of we enkele bekende en veelvoorkomende zwaktes van LLM’s konden blootleggen – dingen als cascadefouten in berekeningen, ruimtelijk redeneren (altijd lastig) en vragen met randvoorwaarden. We hebben ook een specifieke debuggingtaak opgenomen omdat Anthropic in de aankondiging opschepte over hoe goed Opus 4.6 is met root cause analysis en andere debugproblemen.
Test 1: Hex-naar-decimaal-logica
Onze eerste test combineert priemgetallen, hexadecimaal en tellen:
Step 1: Find the 6th prime number. Let this be P.
Step 2: Convert the square of P into hexadecimal.
Step 3: Count the letters (A–F) and digits (0–9) in that hex string. Let these be A and B.
Step 4: Multiply A × B. Let this be N.
Step 5: Find the Nth prime number.
Het klinkt wat complex, maar deze test is voor ons mensen vrij makkelijk te controleren. Het juiste antwoord weten we: 2, want de 6e priem is 13; 13 in het kwadraat is 169, wat in hex "A9" is. Dit heeft 1 letter × 1 cijfer, wat 1 is als we ze vermenigvuldigen, en de eerste priem is 2.
De zorg is dat een model kan struikelen bij de hexconversie, wat doorwerkt naar een volledig fout eindantwoord. Zoals je ziet had Opus 4.6 hier geen moeite mee:

Test 2: Een matrix roteren
Onze tweede test toetst ruimtelijk redeneren en omgaan met negatieve getallen:
Step 1: Create a 2×2 matrix M with top row [4, 2] and bottom row [1, 5].
Step 2: Rotate M 90 degrees clockwise.
Step 3: Calculate the determinant of the rotated matrix.
Step 4: Cube that determinant.
Step 5: Subtract the 13th Fibonacci number from the result.
Deze kostte aan onze kant wat meer werk om te verifiëren. Het juiste antwoord is -6.065. We weten dit omdat de geroteerde matrix [[1, 4], [5, 2]] is; we kunnen dan met Python de determinant vinden, die -18 is, en als we dit getal tot de derde macht verheffen, krijgen we -5.832; tot slot trekken we er 233 van af en komen we uit op -6.065.
We vonden deze test interessant omdat we weten dat modellen vaak matrixelementen verkeerd om wisselen of halverwege het minteken kwijtraken. Opnieuw had Opus 4.6 geen moeite:

Test 3: Een stoelopstelling-quiz
Voor onze derde test probeerden we een constraint satisfaction-probleem dat backtracking vereist:
Five people (Alex, Josef, Matt, Thalia, Tom) sit in chairs 1–5.
Thalia is in an even-numbered chair.Alex is immediately to Thalia’s right.Tom is at one end.Josef is not next to Tom.Who is in chair 3?
Het juiste antwoord op deze test is Josef. (Alex-1, Matt-2, Josef-3, Thalia-4, Tom-5.) Je kunt dit met wat moeite op papier uitwerken.
De voornaamste reden dat een model dit soort vraag fout kan hebben, is dat modellen historisch sequentieel oplosten, niet holistisch. Ze lezen "Thalia zit op een even stoel" en kiezen er een (bijv. stoel 2) zonder te checken of die keuze klopt met alle andere randvoorwaarden. Dan leggen ze zich daarop vast, vullen meer stoelen in en lopen uiteindelijk tegen een conflict aan, maar tegen die tijd hebben ze zich vastgeschreven en gaan ze niet terug om Thalia op stoel 4 te proberen.
Opus 4.6 had dit ook goed:

Test 4: Een klokpuzzel
Onze vierde test beoordeelt ruimtelijke visualisatie en fysieke intuïtie:
Step 1: Imagine a clock currently showing 3:15 PM.
Step 2: Rotate the clock 90 degrees counter-clockwise (physically turning the whole clock face). After the rotation, what time does the minute hand appear to be pointing at?
Step 3: Take that new "apparent" minute value and add it to the original time (3:15 PM).
Step 4: Subtract 45 minutes from that result.
Step 5: What is the final time?
Om deze te verifiëren heb ik letterlijk mijn horloge afgedaan en het rondgedraaid.
Het juiste antwoord is 14:30. Om 3:15 wijst de minutenwijzer naar de "3". Toen ik de 12 naar het raam links van mij draaide, schoof de "3" naar waar de "12" stond. Ik telde toen 0 op bij 3:15, trok 45 minuten af, en kwam uit op 14:30.
Bij het ontwerpen van de test verwachtten we dat modellen het draaien van de klokplaat zouden verwarren met het verplaatsen van de wijzer. We hebben ook gehoord dat modellen geneigd zijn optellen met 0 verdacht te vinden en daarom een ander getal proberen af te dwingen.
Toch wist Opus 4.6 dit probleem op te lossen; het gaf ook hier het juiste antwoord:

Test 5: Een getaltheoriepuzzel
Onze vijfde test combineert modulaire rekenkunde met priemfiltering:
Find a two-digit number S that satisfies all of the following:
* When S is squared, the last two digits of the result are 21.
* S must be a prime number.
* The sum of the digits of S must also be a prime number.
What is the largest possible value of S?
Zo weten we dat het juiste getal 89 is: Getallen waarvan het kwadraat eindigt op 21 zijn onder andere 11, 39, 61 en 89. Hiervan is 39 geen priem, dus houden we 11, 61 en 89 over. Alle drie hebben een cijftersom die priem is (respectievelijk 2, 7 en 17), dus de grootste is 89.
Opus 4.6 gaf weer het juiste antwoord, en voegde dit keer ook een behulpzame visual toe:

Test 6: Cijfers omkeren
De volgende test schakelt factorials, stringmanipulatie en priemgetallen aan elkaar:
Step 1: Calculate 5! (5 factorial). Let this result be X.
Step 2: Take X, subtract 1, and reverse the digits of the result. Let this new number be Y.
Step 3: Identify all prime numbers (p) such that 10 ≤ p ≤ Y.
Step 4: Calculate the sum of these primes and divide it by the total count of primes found in that range.
Step 5: Provide the final average, rounded to the nearest whole number.
Zo verifieerden wij 425 als het juiste antwoord: 5! = 120; min 1 is 119; cijfers omkeren geeft 911. Vervolgens zagen we met wat R-code (hieronder) dat er 152 priemgetallen tussen 10 en 911 zijn, en hun som is 64.598. Ten slotte delen en afronden met R: 64.598 ÷ 152 ≈ 425.

Hier is het R-script dat we gebruikten:
# Step 1: Calculate 5!
X <- factorial(5)
cat("Step 1: X =", X, "\n")
# Step 2: Subtract 1 and reverse digits
result <- X - 1
Y <- as.numeric(paste0(rev(strsplit(as.character(result), "")[[1]]), collapse = ""))
cat("Step 2:", X, "- 1 =", result, "-> reversed ->", Y, "\n")
# Step 3: Find all primes between 10 and Y
is_prime <- function(n) {
if (n < 2) return(FALSE)
if (n == 2) return(TRUE)
if (n %% 2 == 0) return(FALSE)
for (i in 3:floor(sqrt(n))) {
if (n %% i == 0) return(FALSE)
}
return(TRUE)
}
primes <- Filter(is_prime, 10:Y)
cat("Step 3: Found", length(primes), "primes between 10 and", Y, "\n")
# Step 4: Sum and average
total <- sum(primes)
count <- length(primes)
avg <- total / count
cat("Step 4: Sum =", total, ", Count =", count, ", Average =", avg, "\n")
# Step 5: Round
cat("Step 5: Rounded =", round(avg), "\n")
Test 7: Code debuggen
Onze volgende test richt zich op een van de grote claims van Opus 4.6: bugs in code diagnosticeren. We weten dat modellen vaak regel-voor-regel correct door code traceren maar er niet in slagen om die trace terug te koppelen aan het onderliggende probleem.
A developer wrote this Python function to compute a running average:
def running_average(data, window=3):
result = []
for i in range(len(data)):
start = max(0, i - window + 1)
chunk = data[start:i + 1]
result.append(round(sum(chunk) / window, 2))
return result
When called with running_average([10, 20, 30, 40, 50]), the first two values in the output seem wrong. Why? Please help me fix what is wrong!
Hier is het antwoord en waarom dit een goede test is: de functie deelt altijd door window (3), zelfs wanneer het deel aan het begin minder dan 3 elementen bevat. De foutieve output is [3.33, 10.0, 20.0, 30.0, 40.0], maar de eerste twee waarden zouden 10.0 en 15.0 moeten zijn, omdat die delen respectievelijk slechts 1 en 2 elementen bevatten. De oplossing is / window veranderen in / len(chunk).
We vinden deze test goed omdat modellen vaak perfect door de lus traceren, maar dan rapporteren dat de "output klopt" — ze zien de rekenstappen en signaleren niet dat een enkel element door 3 delen fout is. Het vereist dat het model intentie (wat een voortschrijdend gemiddelde hoort te doen) naast uitvoering (wat de code daadwerkelijk doet) kan houden en het gat ertussen spot.
Test 8: Een gedachtenexperiment in de natuurkunde
Onze laatste test bevat geen wiskunde, alleen contrafeitelijk redeneren.
In a world where gravity repels objects instead of attracting them, what shape would rivers take?
Toegegeven, er is hier geen enkel juist antwoord, en het is lastig om ons dat voor te stellen. Maar we zoeken ernaar dat het model in elk geval de implicaties doorredeneert, en we vinden dat het antwoord van Claude Opus 4.6 redelijk genoeg lijkt.
Kortom: Opus 4.6 haalde een perfecte score, al zat er, zoals je zag, één vraag tussen waarbij het antwoord wat subjectiever is, dus jij mag de eindjury zijn.

Claude Opus 4.6-benchmarks
Opus 4.6 is de onbetwiste leider op minstens vier belangrijke benchmarks:
- Terminal-Bench 2.0
- Humanity’s Last Exam
- GDPval-AA
- BrowseComp
Terminal-Bench 2.0 is een benchmark voor agentisch coderen; Humanity’s Last Exam is een test van complexe redenering; GDPval-AA test de prestaties op kenniswerk; BrowseComp meet het vermogen van een model om moeilijk te vinden info online op te sporen.
Terminal-Bench 2.0
De Claude-modellen hebben terecht de reputatie tot de beste coders te behoren. Laten we dus beginnen met de resultaten van de Terminal-Bench 2.0-benchmark.

Als de grafiek hierboven Opus 4.6 lijkt uit te lichten ten opzichte van GPT-5.2-codex – dat is vast geen toeval. Anthropic daagt OpenAI de laatste tijd rechtstreeks uit op meerdere fronten en pleit voor enterprise-gebruik.
Humanity’s Last Exam
Humanity’s Last Exam is een van de bekendste benchmarks, en het is er een die we allemaal nauwlettend volgen. Het meet het vermogen van een model om algemeen te redeneren.
De volgende grafiek toont het succes van verschillende grensmodellen op de HLE-benchmark, zowel met als zonder tools. (‘Met tools’ betekent dat het model externe mogelijkheden mocht gebruiken, zoals zoeken op het web en code uitvoeren.)
Misschien was dit beter als twee grafieken. Die kleinigheid terzijde, de conclusie is duidelijk: Opus 4.6 is de koploper in zowel de categorie ‘met tools’ als ‘zonder tools’.

GDPval-AA
GDPval-AA (zoals de naam suggereert) is een test van wat wordt beschouwd als economisch waardevol kenniswerk. Denk aan zaken als financiële modellen draaien of onderzoek doen.
GDPval-AA en andere, vergelijkbare benchmarks worden alleen maar belangrijker, omdat ze echt het soort werk meten waar bedrijven daadwerkelijk voor betalen. Het succes van Opus 4.6 op GDPval-AA is ook weer een directe uitdaging voor de GPT-reeks, omdat OpenAI en Anthropic strijden om veel van dezelfde klanten.

BrowseComp
BrowseComp is de laatste benchmark uit de release die het vermelden waard is. Het meet het vermogen van een model om moeilijk te vinden info online op te sporen. Even wat geschiedenis: OpenAI ontwikkelde BrowseComp oorspronkelijk om de zoekcapaciteiten van hun eigen modellen te tonen.
In een puntige zet linkte Anthropic in deze release rechtstreeks naar OpenAI’s aankondiging van april 2025 over de ontwikkeling van BrowseComp toen ze benadrukten dat Opus 4.6 daar bovenaan staat. Het was een tikje schamper om zo naar OpenAI’s eigen benchmark te verwijzen.
Claude 4.6: prijs en beschikbaarheid
Opus 4.6 is op het moment van schrijven breed beschikbaar. Je kunt Opus 4.6 echter niet gebruiken zonder te upgraden naar een pro-account, dat ook andere voordelen biedt, zoals Claude in Excel kunnen gebruiken.
Ben je ontwikkelaar, gebruik dan claude-opus-4-6 in de Claude API. De prijs is niet veranderd: nog steeds $5/$25 per miljoen tokens. Als je in de war bent door de twee getallen: het eerste bedrag betaal je voor de tokens die je naar het model stuurt (je prompts dus), en het tweede voor de tokens die het model terug genereert (de antwoorden).
Tot slot
Claude Opus 4.6 voert de ranglijsten aan op belangrijke benchmarks zoals GPDVal-AA, die meet hoe goed een model het doet op economisch belangrijke taken, waar grote zakelijke klanten om geven. OpenAI is hier mogelijk door geschud, want slechts enkele uren vóór de release van Opus 4.6 kondigden ze OpenAI Frontier aan, een nieuw enterpriseplatform voor het bouwen, deployen en beheren van AI-agents in productie.
Met andere woorden, in plaats van te concurreren op modelbenchmarks, laat Frontier zien dat OpenAI zich richt op de infrastructuur rond zijn modelreeks, specifiek door AI-agents gedeelde bedrijfscontext, rechten en het vermogen om feedback in de tijd te ontvangen en daarvan te leren te geven. Nu het terrein verliest op benchmarks, geeft OpenAI het signaal af dat zijn platform beter gepositioneerd is om agents daadwerkelijk nuttig te maken binnen een bedrijf.
Of dat een strategische koerswijziging is of een stilzwijgende erkenning dat ze de modelrace verliezen, mag je zelf bepalen.
Al met al zijn we onder de indruk van wat Anthropic met Claude Opus 4.6 te bieden heeft, en we kijken ernaar uit om met de agentteams aan de slag te gaan. Wil je meer leren over de Claude-familie, bekijk dan zeker de cursus Introduction to Claude Models.
Senior redacteur in AI en edtech. Toegewijd aan het verkennen van data- en AI-trends.

Ik ben een schrijver en editor op het gebied van data science en heb bijgedragen aan onderzoeksartikelen in wetenschappelijke tijdschriften. Ik ben vooral geïnteresseerd in lineaire algebra, statistiek, R en dergelijke. Ik speel ook best wat schaak!




