Claude Opus 4.6 en Sonnet 4.6: Wat er werkelijk veranderd is

Ik zat midden in een refactor van een klantproject -- 47 bestanden diep in een Laravel monolith-migratie -- toen Claude Code gewoon... doorging. Geen waarschuwing over afkapping. Geen ongemakkelijke onderbreking midden in een functie waarbij het model buiten adem raakt en je de output handmatig weer aan elkaar moet plakken. Het schreef gewoon. En schreef. En maakte de volledige service class af in een enkele response.

Dat was het moment waarop ik de versie controleerde. Opus 4.6. En de standaard output token-limiet was stilletjes verhoogd naar 64.000.

Ik had maandenlang met de vorige standaardinstellingen gewerkt en spiergeheugen ontwikkeld rond de beperkingen. Complexe generaties opbreken in kleinere stukken. Stapsgewijs prompten. Mentale steigers bouwen om het plafond heen te werken. En plotseling was het plafond drie verdiepingen hoger dan waar ik steeds met mijn hoofd tegenaan stootte.

Die ene verandering alleen al was genoeg geweest om over te schrijven. Maar Anthropic stopte daar niet. De Opus 4.6 en Sonnet 4.6 update is een van de meest uitgebreide releases die ik van het Claude Code-team heb gezien -- van token-capaciteit en session management tot beveiligingspatches, prestatieoptimalisatie, plugin-architectuur en een lange lijst terminal-fixes waardoor ik me afvroeg of iemand mijn persoonlijke bugtracker had gelezen.

Hier volgt mijn eerlijke uiteenzetting van alles wat er is uitgebracht, wat echt uitmaakt voor het dagelijks werk, en de twee veranderingen waarvan ik denk dat de meeste mensen ze volledig over het hoofd zullen zien.

Waarom deze update anders aanvoelt dan eerdere updates

De meeste modelupdates voelen incrementeel aan. Hier een benchmarkverbetering, daar een iets betere score op het volgen van instructies. Je leest de changelog, knikt, en gaat weer aan het werk zonder iets aan je workflow te veranderen.

Deze update dwong me om binnen de eerste 48 uur drie dingen te veranderen aan hoe ik Claude Code gebruik. Niet omdat de oude manier niet meer werkte -- maar omdat de nieuwe mogelijkheden mijn oude patronen deden aanvoelen alsof ik een sportwagen in de eerste versnelling reed.

Alleen al de token-uitbreiding veranderde hoe ik nadenk over prompt engineering voor agentic workflows. De sessieverbeteringen veranderden hoe ik langlopende projecten beheer. En een beveiligingsfix maakte me achteraf nerveus over een productie-setup die ik al weken draaide.

Ik heb zowel Opus 4.6 als Sonnet 4.6 getest op echte projecten sinds de update verscheen -- geen synthetische benchmarks, geen speelgoedvoorbeelden, maar daadwerkelijk klantwerk en persoonlijke builds. Wat volgt is alles wat ik geleerd heb, geordend op hoeveel het je dagelijkse workflow daadwerkelijk zal beinvloeden.

Laat me beginnen met de verandering die het meest uitmaakt.

Hoe verandert 128K token output Claude Code workflows?

Het kopgetal: Claude Opus 4.6 heeft nu standaard 64.000 output tokens per response. Zowel Opus 4.6 als Sonnet 4.6 ondersteunen een bovengrens van 128.000 tokens. En als je het Claude-abonnement hebt, kun je tot 1 miljoen tokens in context gebruiken.

Dat zijn grote getallen. Maar getallen zonder context zijn slechts marketing. Dit is wat ze in de praktijk daadwerkelijk betekenen.

De oude workflow (voor de 64K-standaard)

Met eerdere token-limieten vereiste elke complexe generatie choreografie. Ik brak een groot bestand op in secties, promptte voor elke sectie afzonderlijk en combineerde vervolgens handmatig de outputs. Database-migraties met meer dan 30 tabellen? Drie of vier aparte prompts. Een volledige test suite voor een API met 15 endpoints? Ik groepeerde ze in batches van vijf.

De overhead zat niet in het prompten zelf -- het was het contextverlies tussen prompts. Elke nieuwe prompt begon enigszins losgekoppeld van de vorige. Naamconventies gingen afwijken. Import-statements werden gedupliceerd of vergeten. Het model kon het totaalplaatje niet zien omdat ik het door een sleutelgat voerde.

De nieuwe realiteit

Met 64K als standaard en 128K als plafond genereer ik complete service-lagen in enkele passes. Vorige week gaf ik Claude Code de opdracht om een compleet notificatiesysteem te bouwen -- de model class, de migratie, de service class, de event listeners, de queue job, de API controller, de form request-validatie en de PHPUnit-tests. Een prompt. Een response. Alles intern consistent omdat het model de volledige context kon vasthouden zonder dat ik het in stukken hoefde te knippen.

Het kwaliteitsverschil is merkbaar. Wanneer het model alles kan zien wat het genereert in een enkele pass, is de code samenhangender. Variabelenamen blijven consistent. Helper methods worden hergebruikt in plaats van opnieuw uitgevonden. Foutafhandeling volgt een enkel patroon door het geheel. Het is het verschil tussen een architect die een gebouw ontwerpt en vijf verschillende aannemers die elk een verdieping bouwen zonder met elkaar te praten.

Wanneer 128K echt uitmaakt

Je zult het plafond van 128K niet bereiken bij normaal conversationeel gebruik. Waar het cruciaal wordt, zijn agentic workflows -- wanneer Claude Code meerdere bestanden leest, een codebase analyseert en output genereert, allemaal binnen een enkel context window. Grote monorepo-refactors. Full-stack feature-implementaties die tegelijkertijd frontend, backend en databaselagen raken. Documentatiegeneratie die tientallen bronbestanden moet raadplegen.

Ik deed vorige week een test: ik richtte Claude Code op een Laravel-project van 340 bestanden en vroeg het om een volledige API-documentatiesite te genereren. Met de oude limieten zou dit een aangepaste pipeline van opgedeelde bewerkingen hebben vereist. Met 128K output tokens beschikbaar las de agent de route-bestanden, analyseerde de controllers, inspecteerde de form requests en genereerde gestructureerde documentatie die elk endpoint dekte -- in een enkele sessie zonder tegen de muur aan te lopen.

Het context window van 1 miljoen tokens voor Claude-abonnementsgebruikers tilt dit nog verder. Je kunt complete codebases in context laden en er als geheel mee werken. Ik verken nog steeds de grenzen van wat praktisch is op die schaal, maar de eerste resultaten zijn veelbelovend voor grootschalige code-analyse en refactoring-taken.

Maar de token-uitbreiding is slechts de helft van het verhaal. De sessieverbeteringen zijn wat me mijn projectmanagement-workflow volledig deed heroverwegen.

Session management: 45% sneller hervatten en automatische sessienamen

Hier is een workflow-irritatie die ik gewoon als normaal had geaccepteerd: ik zat diep in een Claude Code-sessie, ging lunchen, kwam terug, en het hervatten van de sessie duurde lang genoeg dat ik een nieuw terminal-tabblad opende en begon met e-mail checken terwijl ik wachtte. Bij grote sessies met aanzienlijke context voelde het hervatten traag aan.

Opus 4.6 verlaagt de hervattingssnelheid van sessies met 45% en vermindert het piekgeheugengebruik tijdens het hervatten met tot 150 MB. De cijfers klinken abstract totdat je het ervaart. Mijn grote projectsessies hervatten nu in de tijd die het me vroeger kostte om te besluiten of ik zou wachten of een nieuwe sessie zou starten. De beslissing wordt voor me genomen -- het is al terug.

Automatische sessienamen veranderden hoe ik mijn werk organiseer

Dit is subtiel, maar het hervormt mijn dagelijkse workflow. Sessies geven zichzelf nu automatisch een naam op basis van de inhoud van het geaccepteerde plan. In plaats van een lijst sessies te zien met timestamps of generieke aanduidingen, zie ik beschrijvende namen die me precies vertellen wat elke sessie aan het doen was.

Voor deze update had ik vier of vijf gelijktijdige sessies open en raakte ik constant het overzicht kwijt over welke sessie de authenticatie-refactor behandelde, de API-integratie, of de deployment-configuratie. Ik gluurde in elk ervan, scande de context en orienteerde mezelf. Tien tot vijftien seconden wrijving, tientallen keren per dag herhaald.

Nu werp ik een blik op de sessielijst en weet ik meteen waar alles staat. Het is het soort verbetering dat geen koppen haalt maar echte cognitieve overhead bespaart over een volledige werkdag.

Het hernoemde /branch commando

Het /slashwalk-commando is hernoemd naar /slash branch, wat semantisch veel logischer is. Je vertakt je conversatie, je wandelt er niet doorheen. De oude naam is behouden als alias zodat niets breekt, maar als je spiergeheugen aan het opbouwen bent, begin dan nu met het gebruik van /branch.

Het /copy-commando kreeg ook een stille upgrade -- het accepteert nu een optionele index om de Nde meest recente assistant-response op te halen in plaats van altijd de meest recente te pakken. Kleine feature, maar ik heb het deze week al drie keer gebruikt toen ik een eerder codeblok nodig had dat door vervolgconversatie omhoog was geduwd.

Deze sessieverbeteringen werken cumulatief. Sneller hervatten betekent minder wrijving bij het wisselen van context. Automatische sessienamen betekenen minder cognitieve overhead. Betere copy-commando's betekenen minder handmatig scrollen. Afzonderlijk bespaart elk ervan seconden. Samen, over een volledige dag van intensief Claude Code-gebruik, besparen ze me betekenisvolle stukken geconcentreerde tijd.

Nu -- hier is het deel van deze update dat me tot na middernacht wakker hield terwijl ik een productieomgeving opnieuw doorlichtte.

De beveiligingsfix die je nu moet begrijpen

Verstopt in de changelog, tussen de opvallende token-aantallen en de kwaliteitsverbeteringen, zit een beveiligingspatch die meer aandacht verdient dan hij krijgt.

De fix betreft een kwetsbaarheid waarbij pre-tool-use hooks deny-permissieregels konden omzeilen. Inclusief door het bedrijf beheerde instellingen. Laat me uitleggen waarom die zin je ongemakkelijk zou moeten maken als je Claude Code draait in een omgeving met toegangscontroles.

Wat was er daadwerkelijk kwetsbaar

Het permissiesysteem van Claude Code laat je definieren wat de agent wel en niet mag doen. Deny-regels horen harde grenzen te zijn -- als je de toegang tot een directory ontzegt, zou de agent daar niet moeten kunnen lezen of schrijven. Punt.

De kwetsbaarheid betekende dat pre-tool-use hooks -- code die wordt uitgevoerd voordat een tool draait -- die deny-regels konden omzeilen. In bedrijfsomgevingen waar permissieregels centraal worden beheerd, betekende dit dat de beveiligingsgrens niet zo solide was als beheerders dachten.

Was het waarschijnlijk dat dit per ongeluk werd misbruikt? Waarschijnlijk niet. Maar in een gericht scenario -- zeg, een kwaadaardige plugin of een crafted prompt ontworpen om data uit een beperkte directory te exfiltreren -- had de bypass benut kunnen worden. Het aanvalsoppervlak bestond, en in beveiliging is dat wat telt.

De nieuwe allowed sandbox-instelling

Naast de fix introduceerde Anthropic een nieuwe allowed sandbox-instelling die leestoegang binnen deny-regio's herstelt met meer gedetailleerde controle. Dit is een slimme ontwerpbeslissing. In plaats van het binaire allow/deny-model heb je nu een tussenvorm: "blokkeer schrijven maar sta lezen toe" voor specifieke regio's.

Dit is belangrijk voor workflows waar Claude Code configuratiebestanden moet lezen of code moet raadplegen in directories waar het absoluut geen wijzigingen zou moeten aanbrengen. Voorheen gaf je ofwel volledige toegang (riskant) ofwel ontzegde je alle toegang (beperkend). De sandbox-instelling geeft je de precisie die productieomgevingen daadwerkelijk nodig hebben.

De CRLF-regeleindefix

Nog een beveiligingsgerelateerde fix die het vermelden waard is: de write tool converteert niet langer stilzwijgend regeleindes bij het overschrijven van CRLF-bestanden. Dit klinkt triviaal totdat je ermee te maken hebt gehad. Als je werkt in een gemixte omgeving -- bestanden afkomstig van Windows in een project dat ook Unix-stijl bestanden heeft -- kan stille regeleindeconversie shell scripts breken, binair-achtige bestanden corrumperen en subtiele bugs creeren die uren kosten om te traceren.

Het feit dat de tool stilzwijgend conversie uitvoerde zonder de gebruiker te informeren is het echte probleem. Stille datawijziging, zelfs goedbedoeld, ondermijnt het vertrouwen in tooling. Deze fix herstelt het principe dat de tool precies moet doen wat je vroeg en niets meer.

Als je liever hebt dat iemand je Claude Code-beveiligingsconfiguratie en permissiegrenzen doorlicht voor een productieomgeving, neem ik security review-opdrachten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

Goed, dat was het gedeelte dat serieuze aandacht vereiste. Wat volgt is een reeks verbeteringen die minder urgent zijn maar je dagelijkse ervaring merkbaar soepeler zullen maken.

Prestatieverbeteringen: de dood door duizend milliseconden

Ik heb een theorie over developer-tooling: de tools die op de lange termijn winnen zijn niet degene met de meest opvallende features. Het zijn de tools die microwrijving zo consistent elimineren dat je vergeet dat wrijving ooit bestond. Deze update spijkert die filosofie vast.

macOS startup: 60 milliseconden sneller

Zestig milliseconden klinkt onbeduidend. Dat is het niet. Claude Code op macOS leest nu keychain-credentials parallel in plaats van sequentieel tijdens het opstarten. Die 60ms-verbetering vindt plaats elke keer dat je de tool opstart. Als je Claude Code 20 keer per dag opstart -- wat ik makkelijk doe tussen verschillende projecten, terminal-sessies en tests -- is dat meer dan een seconde dagelijkse wrijving verwijderd.

Belangrijker nog, het is een signaal van engineering-prioriteiten. Het team profileert opstartpaden en optimaliseert hot loops. Die discipline cumuleert over releases heen.

Geheugengroeifix voor lange sessies

Deze raakte een gevoelige snaar. Ik had gemerkt dat Claude Code-sessies van meerdere uren geleidelijk meer geheugen gingen verbruiken, waardoor uiteindelijk mijn laptopventilator begon te draaien en andere applicaties vertraagden. Ik gaf macOS-geheugenbeheer de schuld. Het bleek een bug te zijn in de sessieafhandeling van Claude Code -- geheugen werd niet correct vrijgegeven tijdens langlopende sessies.

De fix betekent dat ik nu sessies van een hele dag kan draaien zonder de sluipende prestatievermindering waar ik onbewust omheen werkte door periodiek sessies te killen en opnieuw te starten. Nog een onzichtbaar wrijvingspunt, geëlimineerd.

Voortgangsberichten overleven compactie

Wanneer Claude Code een conversatie compact om binnen de contextlimieten te blijven, verdwenen voortgangsberichten. Dit betekende dat je tijdens lange agentic operaties -- meerstaps-bestandswijzigingen, complexe buildprocessen -- het zicht verloor op wat de agent had bereikt als compactie midden in een operatie plaatsvond.

Voortgangsberichten blijven nu behouden door compactie heen. Je behoudt volledig zicht op het werk van de agent, ongeacht hoe lang de sessie duurt. Voor iedereen die complexe, meerstaps agentic workflows draait, is dit het verschil tussen vertrouwen en ongerustheid over wat er onder de motorkap gebeurt.

Correctie van kostentracking

Een stillere fix: kosten- en token-gebruiktracking is nu correct voor API-fallback wanneer de non-streaming modus wordt gebruikt. Als je je API-uitgaven hebt bijgehouden en de cijfers leken iets af te wijken, is dit waarschijnlijk de reden. Geen dramatische bug, maar accurate kostentracking is belangrijk wanneer je API-budgetten beheert over meerdere projecten.

Deze prestatieverbeteringen zullen niemands Twitter-hoogtepunten halen. Maar gestapeld vertegenwoordigen ze een merkbaar betere dagelijkse ervaring. De tool start sneller op, is stabieler over lange sessies, transparanter tijdens operaties en nauwkeuriger in rapportages.

Over transparantie gesproken -- de plugin-toolingveranderingen verdienen hun eigen sectie.

Plugin-tooling: de veranderingen die plugin-ontwikkelaars raken

Als je Claude Code-plugins bouwt of onderhoudt, is deze sectie belangrijk. Als je alleen plugins gebruikt, is de korte versie: dingen zouden minder moeten breken en beter gevalideerd worden. Je kunt doorscrollen naar de bash-fixes als je wilt. Maar ik zou aanraden om te blijven -- begrijpen hoe plugin-tooling werkt maakt je een betere gebruiker van het ecosysteem.

Betere validatie met plugin validate

Het plugin validate-commando is aanzienlijk slimmer geworden. Het controleert nu skill agent- en command front matter, scant hooks.json op YAML-parsefouten en vangt schemaschendingen op. Voorheen kon je een plugin uitbrengen met misvormd front matter en ontdekte je het probleem pas wanneer een gebruiker vreemd gedrag rapporteerde. De validatie vangt deze problemen nu op voor deployment.

Ik heb de bijgewerkte validator gedraaid tegen mijn eigen plugins en het vond twee problemen waarvan ik niet wist dat ze bestonden -- een ontbrekend veld in de front matter van een skill en een hooks.json die een subtiele YAML-inspringingsfout had. Beide werkten "prima" in de praktijk maar waren technisch misvormd. Het soort stille technische schuld dat uiteindelijk problemen veroorzaakt op het slechtst mogelijke moment.

Gedragsverandering van de agent tool

Deze vereist aandacht als je programmatisch met agent tools werkt. De agent tool accepteert niet langer een resume-parameter. In plaats daarvan stuur je, om een gestopte agent voort te zetten, een bericht met de agent-ID. De agent hervat dan automatisch in plaats van een foutmelding te geven.

Het oude gedrag was frustrerend: als een agent stopte en je probeerde hem te hervatten met het verkeerde parameterformaat, kreeg je een foutmelding in plaats van dat de agent gewoon verder ging waar hij gebleven was. De nieuwe aanpak is vergevingsgezinder en intuïtiever. Agents die stoppen kunnen worden voortgezet door ze simpelweg aan te spreken, wat overeenkomt met hoe je de interactie natuurlijk zou verwachten.

Monorepo plugin-cachefix

Voor teams die werken in monorepo's met meerdere plugins in verschillende subdirectories was er een collision-probleem in de plugin-cache. Twee plugins in naburige directories konden elkaars gecachete staat verstoren. Dit is nu opgelost -- elke plugin krijgt zijn eigen cache-scope ongeacht de directorystructuur.

Dit is een nichefix, maar als je erdoor getroffen werd, ken je de pijn. Intermitterend plugin-gedrag dat afhangt van welke plugin als eerste laadde, cache-invalidatie die verkeerd cascadeert -- het debuggen van deze problemen is ellendig. De fix elimineert een hele categorie "werkt op mijn machine"-problemen in monorepo-setups.

Het plugin-ecosysteem wordt volwassener. Betere validatie, vergevingsgezinder agent-gedrag en cache-isolatie zijn allemaal tekenen dat de tooling wordt gebouwd voor serieus productiegebruik, niet alleen voor demo's en experimenten.

Laten we het nu hebben over de fixes die het dichtst bij je vingers op het toetsenbord leven.

Bash- en terminalfixes: het onopvallende werk dat het meest uitmaakt

Ik ga meer tijd besteden aan deze sectie dan je misschien verwacht, omdat terminalgedrag is waar ik mijn daadwerkelijke werkuren doorbreng. Een model kan briljant zijn, maar als de terminallaag tussen mij en het model wrijving heeft, lijdt elke interactie eronder.

Samengestelde commando's werken eindelijk goed

Deze fix adresseert iets dat me al weken stilletjes irriteerde. Wanneer je commando's achter elkaar zette -- zoals cd gevolgd door npm test -- sloeg Claude Code soms de permissieregel op voor de volledige gecombineerde string in plaats van elk commando onafhankelijk te behandelen. Dit betekende dat je cd /project && npm test een keer goedkeurde, en later wanneer je alleen npm test apart uitvoerde, de opgeslagen permissie niet van toepassing was omdat die was opgeslagen tegen de samengestelde string.

Nu wordt elk commando in een keten onafhankelijk geëvalueerd. Keur npm test een keer goed, en het blijft goedgekeurd of je het alleen uitvoert of als onderdeel van een keten. Dit komt overeen met hoe je intuïtief zou verwachten dat permissies werken en elimineert een bron van "waarom vraagt het me dit opnieuw?"-wrijving.

De 5 GB kill voor achtergrondtaken

Achtergrond bash-taken die meer dan 5 GB aan output produceren, worden nu correct beëindigd. Ik zal eerlijk zijn -- ik wist niet dat dit een probleem was totdat ik de changelog las en terugdacht aan een sessie twee weken geleden waarin mijn terminal niet meer reageerde tijdens een bijzonder praatgraag buildproces. Accumulatie van achtergrondoutput was waarschijnlijk de boosdoener.

De drempel van 5 GB is ruim genoeg dat geen legitiem proces het zou moeten triggeren, maar strak genoeg om te voorkomen dat een op hol geslagen taak al het beschikbare geheugen opeet. Goede standaardwaarde.

Spaties in paden van tijdelijke directories

Bash rapporteert niet langer valse fouten voor succesvolle commando's wanneer paden van tijdelijke directories spaties bevatten. Dit is een klassieke Unix-valkuil -- paden met spaties breken aannames in shell scripts overal, en de interne tijdelijke directories van Claude Code veroorzaakten hetzelfde probleem. Als je ooit een foutmelding hebt gezien na een commando dat duidelijk geslaagd was, verklaart deze fix het misschien.

Plakbehoud

Geplakte inhoud blijft nu behouden wanneer je direct na het plakken begint te typen. Voor deze fix kon je, als je een blok tekst plakte en begon te typen voordat het plakken volledig geregistreerd was, een deel van de geplakte inhoud verliezen. De fix gaat over de afhandeling van de invoerbuffer -- ervoor zorgen dat plakgebeurtenissen voltooid zijn voordat toetsenbordgebeurtenissen worden verwerkt.

Kleine fix. Maar het verliezen van klembordinhoud midden in een workflow is het soort ding dat je je eigen verstand doet betwijfelen voordat je de tool in twijfel trekt.

Fixes voor visual mode in de terminal

Backspace en delete werken nu correct in visual normal mode (vnormal). De statusregel wordt correct bijgewerkt wanneer visual mode wisselt. Genummerde lijsten worden correct weergegeven. CJK-tekens bloeden niet langer door naar aangrenzende UI-elementen aan de rechterrand.

Dit zijn polijstfixes, maar ze zijn belangrijk voor iedereen die voornamelijk in de terminal werkt. CJK-tekenweergave raakt in het bijzonder een enorm aantal ontwikkelaars wereldwijd -- wanneer tekens in naburige UI-elementen knippen, is dat niet alleen lelijk, het maakt de interface visueel moeilijker te parsen.

Tmux- en SSH-verbeteringen

De tmux-fixes verdienen een vermelding omdat veel ontwikkelaars -- ikzelf incluis -- in tmux-sessies leven. Achtergrondkleuren worden nu correct weergegeven met de standaard tmux-configuratie. Geen crashes meer bij het selecteren van tekst in tmux via SSH. Clipboard copy toont een behulpzame toast-notificatie over of je moet plakken met Cmd-Y of het tmux-prefix. IDE-integratie maakt automatisch verbinding wanneer Claude Code start binnen tmux of screen.

Die laatste is bijzonder welkom. Ik had de IDE-integratie handmatig opnieuw verbonden elke keer dat ik Claude Code startte vanuit tmux. De autoconnect elimineert een stap die ik zo gewoontegetrouw uitvoerde dat ik de wrijving niet meer opmerkte -- totdat het verdween.

IDE-integratie: kleine fixes, grote kwaliteitsverbetering

Een paar IDE-verbeteringen ronden de update af. Tabbladdtitels voor planvoorbeelden gebruiken nu de werkelijke koptekst van het plan in plaats van een generiek "Claude plan"-label. Dit is dezelfde filosofie als automatische sessienamen -- geef de gebruiker informatie in een oogopslag in plaats van te vereisen dat ze doorklikken om zich te orienteren.

Hyperlinks openen niet langer dubbel bij Cmd-klik in VS Code, Cursor en andere op xterm.js gebaseerde terminals. Als je hebt moeten dealen met dubbele browsertabbladen elke keer dat je op een link in de terminal klikte, dat was een bekende bug, en die is nu opgelost.

De footer linkt nu naar de macOS-instelling om selectie te forceren met Option-klik wanneer native selectie niet wordt geactiveerd. Een klein UX-detail, maar het laat zien dat het team nadenkt over de volledige gebruikersreis -- inclusief de momenten waarop iemand in de war raakt door macOS-invoergedrag en de juiste systeeminstelling moet vinden.

Wat ik denk dat de meeste mensen zullen missen aan deze update

Hier is mijn eerlijke kijk na twee weken dagelijks gebruik met deze veranderingen.

De meeste berichtgeving over deze update zal zich richten op de token-aantallen. 64K standaard. 128K plafond. 1 miljoen context. Dat zijn indrukwekkende cijfers en ze veranderen oprecht wat er mogelijk is. Maar het zijn ook de makkelijkst te begrijpen verbeteringen en de moeilijkst te misbruiken -- meer tokens is eenvoudigweg beter.

De veranderingen waarvan ik denk dat ze de grootste langetermijnimpact zullen hebben, zijn degene die het moeilijkst in een kop te vatten zijn.

De beveiligingsfix is belangrijker dan de token-uitbreiding voor iedereen die Claude Code in een team- of productieomgeving draait. Permissie-bypasses zijn het soort kwetsbaarheid dat het vertrouwen in tooling ondermijnt, en vertrouwen is het fundament waarop al het andere gebouwd is. Als je Claude Code-implementaties beheert, controleer dan je deny-regels en bevestig dat de patch is toegepast.

De sessiemanagementverbeteringen -- automatische sessienamen, sneller hervatten, persistente voortgangsberichten -- cumuleren tot een fundamenteel andere werkervaring over weken en maanden. Ze verminderen de cognitieve belasting van het gebruik van de tool, wat betekent dat meer van je mentale energie naar het daadwerkelijke probleem gaat dat je oplost in plaats van naar het beheren van de tool zelf.

En de bash- en terminalfixes vertegenwoordigen iets wat ik diep waardeer in engineering-teams: de bereidheid om het saaie werk te fixen. Plakbufferafhandeling. Padspaties. CJK-weergave. Opslag van permissieregels voor samengestelde commando's. Niets hiervan zal trending zijn op Twitter. Alles maakt de tool betrouwbaarder voor dagelijks professioneel gebruik.

Hoe je nu het meeste uit Opus 4.6 haalt

Als je al een tijdje met Claude Code werkt, is dit wat ik zou aanraden om deze week te doen om van de update te profiteren.

Ten eerste, herbekijk elke workflow waar je prompts in stukken brak vanwege output-limieten. Probeer ze nu als enkele prompts uit te voeren. Je zult waarschijnlijk merken dat de 64K-standaard bewerkingen aankan die je handmatig aan het splitsen was, en de outputkwaliteit verbetert door de uniforme context.

Ten tweede, controleer je permissieconfiguratie. Vooral als je in een bedrijfsomgeving zit of aangepaste deny-regels hebt. Zorg ervoor dat de beveiligingspatch is toegepast en test je grenzen. De nieuwe sandbox-instelling geeft je meer gedetailleerde controle -- gebruik het om te brede allow/deny-regels te vervangen door precieze scoping.

Ten derde, laat automatische sessienamen voor je werken. Als je sessies handmatig hebt georganiseerd of op timestamps hebt vertrouwd om bij te houden welke sessie welk project behandelt, stop daarmee. Laat de autonaam-feature het afhandelen en richt die organisatie-energie op het werk zelf.

Ten vierde, als je in tmux werkt, test het autoconnect-gedrag. Als je de IDE-integratie handmatig hebt verbonden, verifieer dan dat de automatische verbinding werkt in jouw setup. Verschillende tmux-configuraties kunnen anders reageren op de autoconnect -- beter om eventuele randgevallen nu te ontdekken dan tijdens een deadline.

Ten vijfde, draai plugin validate tegen alle plugins die je onderhoudt. De uitgebreide validatie vangt problemen op die de oude validator miste. Los ze op voordat je gebruikers ze in productie ontdekken.

De Opus 4.6 en Sonnet 4.6 update is niet een enkele vlaggenschip-feature verpakt in marketing. Het zijn honderd kleine tot middelgrote verbeteringen die, gecombineerd, Claude Code een merkbaar betere tool maken dan het twee weken geleden was.

En eerlijk gezegd? De verbeteringen waar ik het meest enthousiast over ben, zijn degene die wrijving verwijderden waarvan ik was opgehouden het op te merken. De hervattingssnelheid van sessies die ik als normaal had geaccepteerd. Het plakbufferprobleem dat ik op mijn toetsenbord had afgeschoven. De tmux-herverbindingsstap die ik in mijn hoofd had geautomatiseerd. Wanneer een tool wrijving verwijdert waar je je aan had aangepast, wordt het niet alleen beter -- het laat je beseffen hoeveel cognitieve overhead je stilletjes meedroeg.

Dat is het soort update dat het waard is om over te schrijven.

Wat is het eerste dat je gaat proberen met 128K output tokens? Ik heb een paar experimenten in de wachtrij staan die ik deel zodra de resultaten binnen zijn. Mijn gok is dat de sweet spot voor de meeste ontwikkelaars niet het maximale token-aantal is -- maar ergens rond de 40-50K waar je uniforme context krijgt zonder de latency van een werkelijk enorme generatie. Maar ik heb het eerder mis gehad, en ik kijk ernaar uit om erachter te komen.

Veelgestelde vragen

Wat is de standaard output token-limiet voor Claude Opus 4.6?

Claude Opus 4.6 heeft standaard 64.000 output tokens per response, met een bovengrens van 128.000 tokens. Claude-abonnementsgebruikers hebben toegang tot maximaal 1 miljoen tokens in context. Voor een volledig overzicht van hoe dit echte workflows verandert, zie de sectie over token output hierboven.

Krijgt Sonnet 4.6 dezelfde tokenverbeteringen als Opus 4.6?

Zowel Sonnet 4.6 als Opus 4.6 ondersteunen de bovengrens van 128.000 tokens voor output. De sessiemanagementverbeteringen, beveiligingspatches en terminalfixes gelden gelijkelijk voor beide modellen. Het belangrijkste verschil blijft de sterkere prestaties van Opus bij complexe redeneer-taken.

Hoeveel sneller is het hervatten van Claude Code-sessies na deze update?

De hervattingssnelheid van sessies is verbeterd met 45%, met tot 150 MB minder piekgeheugengebruik tijdens het hervatten. Sessies geven zichzelf ook automatisch een naam op basis van de planinhoud, waardoor het sneller is om de juiste sessie te vinden en te hervatten.

Is de beveiligingskwetsbaarheid in pre-tool-use hooks ernstig?

De kwetsbaarheid stond pre-tool-use hooks toe om deny-permissieregels te omzeilen, inclusief door het bedrijf beheerde instellingen. Hoewel het onwaarschijnlijk is dat dit per ongeluk wordt getriggerd, creeerde het een reeel aanvalsoppervlak in omgevingen met toegangscontroles. De patch moet onmiddellijk worden toegepast in elke team- of productie-implementatie.

Wat is er veranderd aan Claude Code plugin-validatie?

Het plugin validate-commando controleert nu skill agent- en command front matter, hooks.json op YAML-parsefouten en schemaschendingen. Agent tools hervatten ook automatisch in plaats van een foutmelding te geven bij voortzetting. Voor de volledige plugin-wijzigingen, zie de sectie over plugin-tooling hierboven.

Laten we samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? 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