Anthropic releasde Opus 4.7 op 16 april. Ik vormde sindsdien geen onderbuikmening, ik las mijn eigen logs uit. 11.184 session-jsonl files, 1.224 sessies met 4.6 en 555 sessies met 4.7. Hier is wat de data zegt.
Wat ik concreet meet
Iedere Claude Code sessie schrijft naar ~/.claude/projects/ een jsonl-file met elke assistant-turn, de gebruikte model-string, token-usage en tool-calls. User-replies daarop kun je scannen op correction-patronen.
Dat is dus niet "ik vond 4.7 sneller voelen". Dat is geteld: hoe vaak typte ik "nee dat klopt niet" tegen 4.6 versus tegen 4.7, als percentage van mijn user-replies.
Mijn setup: ik gebruik Opus alleen voor mijn orchestrator-rol (T0 in VNX) en voor zwaar denkwerk. Daily code-werk gaat naar Sonnet-pinned worker-terminals. Dus de impact van Opus-keuze op mijn dagelijkse output is begrensd. Maar als 4.7 wel of niet beter is op orchestrator-taken, dat is precies wat ik wil weten.
Volume eerst
In april verving 4.7 binnen vier weken vrijwel het complete Opus-volume. In mei tot vandaag: 314 sessies 4.7 tegen 4 sessies 4.6. De cutover was scherp en compleet.
Maar dat is alleen het aantal sessies. De compute is dramatischer.
Per assistant-turn produceert 4.7 gemiddeld 1.101 output-tokens. 4.6 deed 294. Dat is 3,7x meer output per stap. Cache-reads cumulatief: 4.6 deed 1,7 miljard tokens over drie maanden, 4.7 deed 19 miljard in zes weken. Listprijs-equivalent van mijn Opus-gebruik april + mei: $42.399. Subscription redt dit. De richting is duidelijk: 4.7 doet meer per stap en meer stappen per sessie.
Sessies in mijn T0-orchestrator zijn ook langer. 4.6 zat op gemiddeld 29 turns per sessie. 4.7 zit op 356. Dat is geen typo. Twaalf keer langer.
versus 4.7 (1.101 tokens). Turns per sessie 4.6 (29) versus 4.7 (356). De compute-richting is structureel hoger met 4.7.")
Het opmerkelijke punt over correcties
Mijn aanname vooraf: langere sessies betekenen meer ruimte voor mismatches, dus meer "nee, doe het anders"-momenten. Maar voor mijn T0-rol klopt dat niet.
T0 op 4.6: 2.063 user-replies, 1 correction. Rate: 0,05%. T0 op 4.7: 20.425 user-replies, 4 corrections. Rate: 0,02%.
Op orchestrator-taken corrigeer ik 4.7 dus de helft zo vaak als 4.6, ondanks dat sessies twaalf keer langer zijn. Voor de rol waar ik Opus überhaupt voor inzet, is 4.7 netto winst.
Dat is een belangrijke nuance om vooraf op te slaan voor de rest van het verhaal.
Waar 4.7 wel slechter scoort
Over al mijn Opus-gebruik samen (orchestrator plus content plus mission-control plus alles): correction-rate stijgt van 0,93% naar 1,51%. 1,6x slechter. En "zoals ik al zei" of "doe wat ik vroeg" stijgt van 0,14% naar 0,76%. 5,5x slechter.
Vijfenhalf keer vaker moet ik instructies herhalen. Dat is geen ruis.
Waar zit het verschil? Vooral in content-sessies (blogs, LinkedIn-drafts) waar ik 4.7 inzet voor langere iteraties op toon en stijl. Daar wil 4.7 meer "afwerken": extra paragrafen, extra context, soms scope-uitbreiding die ik niet vroeg. Op een PR-review of een dispatch-decision werkt dat niet door. Daar telt de structurele uitkomst, en daar levert 4.7.
Voor mij praktisch: 4.7 op T0 blijft staan. Voor content-werk waar precisie boven volume gaat, is 4.6 op een Sonnet-fallback een valide keuze.
Wat de coding-benchmark zegt
Naast deze logfile-analyse heb ik dit weekend ook een gecontroleerde benchmark gedraaid. 7 coding-tasks, identieke prompts, Opus 4.7 als rechter. Beide Opus-versies stonden gewoon in het deelnemersveld.
Resultaat:
| Model | Avg quality | Correctness | Sample |
|---|---|---|---|
| Opus 4.6 | 4,43 / 10 | 71% | 7 tasks |
| Opus 4.7 | 4,29 / 10 | 71% | 7 tasks |
4.7 scoort 0,14 punten lager dan 4.6 op exact dezelfde coding-tasks. Beide vallen in het onderste segment van het deelnemersveld (Kimi K2.6 OpenRouter wint met 8,71, GLM-5.1 zit op 7,86). Dat past bij wat ik in mijn dagelijkse usage zie: voor focused coding-dispatches is geen van beide Opus-versies de juiste keuze. Voor diepe T0-orchestratie of strategische audits is dat een ander verhaal.
De volledige benchmark over alle 9 modellen staat in een aparte blog over routing-keuzes voor mijn workflow.
Tool-gebruik vertelt het echte verhaal
In 4.6-tijd dominant: Bash, Read, WebSearch, mcp-perplexity, sequential-thinking. In 4.7-tijd dominant: Bash (5,8x meer), Edit (3,4x meer), Write (5,3x meer), plus nieuwe primitieven die er voor 4.7 niet waren: TaskCreate, TaskUpdate, ScheduleWakeup, AskUserQuestion.
WebSearch en WebFetch dalen 50-80%. De externe-research-calls die 4.6 vaak triggerde, worden in 4.7 vervangen door interne planning-stappen via TodoWrite en TaskCreate.
Conclusie: een groot deel van het "4.7 doet meer"-effect komt van de Claude Code 2.x harness die tegelijk met 4.7 uitkwam. Wat ik aan model toeschrijf, is deels harness-evolutie. Dat is een belangrijke caveat die in vergelijkbare benchmark-discussies vrijwel altijd verzwegen wordt.
horen bij de Claude Code 2.x harness, niet alleen het model.")
📖 Lees ook: Architecture Beats Models: lessen uit 2400+ dispatches: waarom modelkeuze minder uitmaakt dan orchestratie-architectuur.
Wat dit voor jou betekent
Als je Claude alleen via de webapp gebruikt: je hebt deze data niet en je kunt deze vergelijking niet doen. Je oordeel over modelkwaliteit is een onderbuik-gemiddelde van enkele gesprekken.
Als je Claude Code (CLI) gebruikt: jouw ~/.claude/projects/ is dezelfde goudmijn. Iedere assistant-turn met model-string, iedere tool-call, iedere user-reply. Een avond Python is genoeg om je eigen rapport te maken.
Drie concrete patronen die ik na deze analyse toepas:
Eerst, ik stop met algemene "is X beter dan Y"-claims te accepteren zonder dat ze gekoppeld zijn aan een specifieke rol. 4.7 is voor mijn orchestrator-rol beter. 4.7 is voor mijn content-iteratie soms slechter. Het antwoord is altijd rol-specifiek.
Tweede, ik monitor compute-volume per maand. Mijn 4.7-verbruik is structureel hoger dan 4.6. Subscription dekt het nu, maar als deze trend doorzet ben ik over een jaar bij een ander prijsmodel. Goed om vroeg te zien.
Derde, ik herken dat harness-evoluties en model-releases tegelijk komen. "Het nieuwe model is beter of slechter" is bijna altijd "het nieuwe model in de nieuwe harness is anders". Wie deze twee niet uit elkaar trekt, meet ruis.
📖 Lees ook: Opus 4.7 als orchestrator: wat de beste coding AI betekent voor agent teams: hoe 4.7 zich gedraagt op T0-niveau in de praktijk.
Tot slot
Anthropic heeft tussen 4.6 en 4.7 een aantal echte verbeteringen geleverd op lange-context-coherentie en multi-step tool-use. Dat zie ik terug in mijn T0-data. Tegelijk is de instruction-following voor middel-lange content-taken een stap teruggegaan, of in elk geval anders. Dat zie ik ook terug. En op gecontroleerde coding-tasks scoort 4.7 niet boven 4.6. Daar laat de benchmark geen ruimte voor twijfel.
De kosten zijn substantieel hoger per sessie. Maar de sessies leveren ook meer af. Of dat een goede deal is, hangt af van waar je Opus voor inzet.
Wat ik niet weet, en wat geen logfile mij kan vertellen, is hoe deze trends zich verder ontwikkelen. Ik draai dit rapport opnieuw eind juni, met dan twee volle maanden 4.7-data. Dan weten we of de patronen stabiel zijn of dat ze met gebruiks-evolutie veranderen.
Als jij ook Claude Code gebruikt en je eigen versie van deze analyse hebt gedraaid: ik ben benieuwd of jouw correction-rates dezelfde of andere patronen tonen. Dat is waar deze metingen pas echt waardevol worden, als er een paar van ons zijn die hetzelfde meten en de resultaten naast elkaar leggen.
Mijn complete benchmark-suite en log-parser staan open-source op VNX op GitHub. Reageer met je eigen rapport op advies@vincentvandeth.nl.
Wil je weten hoe ik AI-architectuur toepas in de praktijk? Zie mijn werkwijze.