Opus 4.7 is uit en kan beter programmeren tegen meer tokenverbruik

Anthropic heeft Claude Opus 4.7 uitgebracht. Dat nieuwe taalmodel is de opvolger van 4.6 en haalt onder andere een stuk hogere scores op benchmarks voor programmeertaken. Volgens Anthropic is het model ook beter in visuele herkenning.

Anthropic zegt dat Opus 4.7 algemeen beschikbaar is voor alle gebruikers. Versie 4.7 heeft in verschillende interfaces ook 4.6 als het standaardmodel vervangen, al blijft Opus 4.6 nog wel beschikbaar.

Opus is het krachtigste algemeen beschikbare model van Anthropic. Het nieuwe model scoort ten opzichte van Opus 4.6 met name hoger in benchmarks als SWE-bench, die vooral op programmeertaken gericht zijn.

Daarnaast maakt Opus 4.7 grote sprongen in visuele herkenning, zegt Anthropic. Het bedrijf zegt dat Opus 4.7 in CharXiv veel hogere scores haalt. Die benchmark is bedoeld om llm's te testen op beeldherkenning. Volgens Anthropic kan Opus voortaan afbeeldingen in een hogere resolutie bekijken. Het kan omgaan met afbeeldingen met een breedte van 2576 pixels. Ook krijgt het model een beter geheugen, zodat het meer informatie kan onthouden in langere gesprekken en tussen meer taken.

Volgens Anthropic blijven de kosten per token hetzelfde als Opus 4.6. Versie 4.7 kost nog steeds 5 dollar per miljoen inputtokens en 25 dollar per miljoen outputtokens. Maar, waarschuwt het bedrijf, door een nieuwe manier van tokens berekenen kan het aantal gebruikte tokens oplopen tot 1,35 keer het verbruik van wat het bestaande model had.

Reacties (46)

[Oon]

Ik merk zelf als Max gebruiker (omdat ik met Pro een paar keer per dag moest wachten om weer verder te kunnen) dat ik nu steeds dichter tegen m'n limieten aan kruip. Zal niet lang duren voordat ook Max niet meer geschikt is voor fulltime gebruik.

Daarnaast merk ik weinig verschil tussen dit nieuwe model of het vorige, het blijft een LLM.. Visueel dingen herkennen gaat nog altijd heel vaak fout, en de output is nog altijd even inconsistent. En dat terwijl Claude ver vooruit loopt op de concurrenten.

[ChiLLeR]

Ik ben echt flabbergasted wat deze AI modellen kunnen programmeren. Met de juiste prompts bouw je echt super goede apps , waar je vroeger echt diepe technische programmeer kennis moest hebben en wekenlang aan het coden en debuggen was. Ben je nu echt met een paar uur klaar, voor interne tools is dit echt een enorme game changer.

[Brandts]

Ik vraag me wel af, wat kost het nu om een beetje app te vibecoden. Er worden prijzen genoemd per miljoenen input en output tokens maar dit zegt mij helemaal niets. Neem nou bevoorbeeld deze apps die in deze video gemaakt worden: YouTube: Can I Vibecode a $250M App Better Than a Pro Developer? (With No Code). Wat kost het nou gemiddeld om op deze manier een app te maken?

[Oon]

Met een abonnementje van 10 euro red je dat wel, maar de payoff is gewoon niet te vergelijken. Je hebt een tool die niet te onderhouden is, vol security en performance issues, en je hebt zelf geen idee wat je nou eigenlijk hebt geproduceerd.
Leuk voor iets voor eigen gebruik, maar je wil echt geen bedrijf bouwen op zoiets.

[hatex]

Tja ..... waarom moeilijk als t makkelijk kan ........ om er later achter te komen dat je door de mand bent gevallen als men uitleg hoe t werkt of een aanpassing vraagt...

Op school niet anders.... stagieres hier (andere branches ook) .... alles door 'ai' heen lopen duwen , top..... als zelfs de basis er niet is waar moet je op bouwen...

[bzuidgeest]

Daar ben je zelf bij. Net als code kan ik de AI ook de testcases laten maken, performance profiling laten doen. Af en toe een beetje bijsturen. Scheelt mij een hoop RSI. Ik weet wat er in moet en wat er uit moet en ik heb vaak een idee van verwachte performance.

Ik kan gewoon zien of de AI zijn werk goed gedaan heeft en daar eisen aan stellen. Ik denk dat je er zeker een bedrijf op zou kunnen bouwen. De klant wil alleen dat het werkt en performed. Of jij daar twee of twintig servers voor nodig hebt maakt ze niet uit. En tot voor koort: hardware is cheap, het saas abbo van de klant niet.

[The Realone]

Jij weet of AI goed zijn werk doet, omdat je de kennis hebt. Al die geschetse doembeelden zijn vaak ook niet van toepassing op software developers die nu AI gebruiken als hulpmiddel. Maar dat is een kwestie van tijd. Hoe meer jij AI laat programmeren, hoe meer kennis jij verliest (of nieuwe kennis doe je niet op doet) en hoe minder jij in staat zult zijn te weten of AI zijn werk goed doet.

Ik ben van Windows sysadmin naar DevOps engineer gegaan en heb echt redelijk wat ervaring in mijn vorige rol, maar als ik nu GPOs moet maken of AD replicatie moet debuggen, moet ik er echt weer even voor gaan zitten, want die kennis is nu al veel minder paraat. Nog een paar jaar, en ik ben het echt grotendeels kwijt.

Dan hebben we het natuurlijk niet over junior-devs die al direct beginnen met vibe-coding, die hebben niet eens een fundament om op terug te vallen en te beoordelen of hun gegenereerde werk wel of niet goed is.

[bzuidgeest]

Ja dat is absoluut een probleem. Maar de reactie was op de stelling of de ai goed werk kan afleveren. En dat kan gewoon.

Hoe het moet met ervaring opbouwen in de toekomst geen idee. Maar ook voor de ai zag ik dat al somber in. Iedereen is eng specialistisch tegenwoordig. Ik was ooit beheer als jij nu ben ik al tientallen jaren programmeur. De ervaring helpt mij enorm en ik programmeer alles. Dat houd mijn kennis breed. Maar de meesten die zijn website maker, of app maker, of service bus maker. Allemaal van dit eng dunne straatjes. Daarbuiten kunnen ze niets want heb begrip alleen trucjes. Dat was voor ai al zo.

We zullen gewoon moeten hopen dat er uiteindelijk specialisten overblijven. Hand gemaakte code, of artisenal code.

[bzuidgeest]

Ligt er ook aan hoe ze afrekenen. Copilot is nog per request, maar de meeste rekenen af voor tokens of iets vaags.

Je zal gewoon moeten ervaren wat, wat kost. En dan delegeren. Je kan ook voor simpele taken goedkope oudere modellen gebruiken en voor spannende taken opschalen. Haiku kan nog heel veel best goed. En dan laat ik aan het einde opus de foutjes eruit halen. copilot eerst en augment code voor het echt ingewikkelde.

[Oon]

Voor interne tools helemaal prima ja, maar ik durf met een gerust hart te zeggen dat 80% van de code die Claude produceert niet door mijn code review zou komen en dan ben ik nog niet heel kritisch. De kwaliteit van de code en dan vooral van de architectuur is dermate slecht dat je er echt niet mee in productie wil.

[Utrecht25]

Dan durf ik met een gerust hart te zeggen dat jouw ontwikkelstraat niet deugt.

Ter illustratie: Netflix doet 1500 PR's per week waar geen mens meer aan te past komt (google: netflix minions) . Het vereist echt wel een andere manier van werken dan wat de meeste developers gewend zijn. Het vereist een extreem sterk process, bv op het gebied van spec driven development, TDD, LLM code reviews, heel veel end2end tests, etc.

Als je ontwikkelproces afhankelijk is van enkele senior developers om het op de rails te houden: forget it. Maar de meeste volwassen ontwikkelteams hebben al zo'n goede ontwikkel straat dat zelfs junior devs weinig fout kunnen doen, en dan is de overstap op LLM's een stuk makkelijker. Meer dan 80% van ontwikkeltijd gaat dan niet meer naar ontwikkelen (of ontwikkel agents) maar naar goede specs/arch/tests/etc.

[Oon]

Heel leuk allemaal en je kunt zeker e.e.a. afdekken door rigoreuze geautomatiseerde checks in je CI/CD te hebben, maar dat is natuurlijk helemaal niet te vergelijken met de context van iemand die ff een appje gaat vibe coden en zelf geen kennis van programmeren heeft.

Daarnaast zijn er heel veel bedrijven die al weer richting mensen gaan omdat AI niet-deterministisch is en extreem onbetrouwbaar, genoeg onderzoeken te vinden die hebben uitgewezen dat het inzetten van AI op termijn duurder is dan mensen inhuren voor hetzelfde, en dan heb je het nog over kosten obv deze extreem gesubsidiëerde API's. Als je alles in-house moet doen met je eigen infra of straks een factor 100 meer betaalt voor je tokens dan ga je toch anders nadenken over hoe je AI kunt inzetten.

[Llopigat]

Ja precies, er is een groot gevaar dat je jezelf afhankelijk maakt en dan later wordt afgekepen. Eigenlijk het Microsoft model, ze komen altijd met hele goede deals voor M365 maar als je er eenmaal aan vast zit met alles dan komen ze bij het volgende contract met de duimschroeven aan.

Ik zie het als consument al erg, in het begin was het prachtig maar nu wordt alles constant afgeknepen en heb je er niks meer aan. Meer dan 20 in de maand ga ik nooit betalen voor iets dat mij geen geld opbrengt.

[Reactie gewijzigd door Llopigat op 17 april 2026 15:43]

[Cybje]

Het blijft natuurlijk gewoon een tool. Als je er niet mee om kunt gaan, zoals veel vibe coders, krijg je er uiteraard code van lage kwaliteit uit. En je hoeft ook niet perse al je code ermee te schrijven. Het kan dan alsnog saai werk zoals het schrijven van tests voor jou doen. Dan gaat alsnog de kwaliteit van je project omhoog, want over het algemeen hebben developers de neiging wat lui te zijn qua tests schrijven.

[Oon]

Ik ben zelf ook zeker niet anti-AI (zie mijn eerste comment, ik betaal zelf iedere maand een flinke smak geld aan Anthropic om hun tools te gebruiken), maar ik denk wel dat de mensen die er blind positief over zijn vaak niet goed snappen wat de risico's zijn, en dat het pushen van AI alleen maar 'omdat AI' een hele ongezonde realiteit aan het produceren is.
Het vervelende is dat AI niks beter kan dan iemand met ervaring, maar wel álles een klein beetje kan.
Bijvoorbeeld: Ik heb zelf weinig ervaring met unit testen, maar Claude kan die wel voor me schrijven. Ik kan alleen totaal niet beoordelen of het de lading dekt, en tenzij ik zelf specifiek ga vragen om ook negatieve testen te schrijven krijg ik alleen maar bevestiging van de happy flow. Dat is leuk om te zien of je grote regressie hebt, en het heeft wel enige toegevoegde waarde in het geheel, maar het is totáál niet te vergelijken met een junior-medior test engineer die de diepte in gaat en gaat kijken welke testcases écht waardevol zijn.

[pietvelleman]

Ik ben zeer positief over AI en betaal ook een smak geld aan Anthropic.

Ik kan nu dingen programmeren die ik nooit zelf zou hebben gekund (of in 25% van de tijd).

Echterrrr...
Je kunt heel snel goed werkende apps maken, prachtige fornt-ends en goed werkende backends. Maar als je onder de kap kijkt, zie ik toch wel heel veel niet-efficiente code. Voorbeeld: vreemde joins bij db queries die volledig onnodig waren. De queries deden hun werk en gaven de juiste output... Maar via te veel onnodige omwegen.

En als je die code-review niet doet en blind vaart op wat Claude e.a. voor je maakt... dan zou je dat nooit gezien hebben. Het werkt immers prima (bij een paar gebruikers in een testomgeving). En daar zit toch best een gevaar, zou ik als niet-professionele programmeur zeggen.

[Reactie gewijzigd door pietvelleman op 17 april 2026 16:35]

[Defspace]

Je bepaalt de architectuur zelf he. Claude of codex en gemini doen gewoon wat je van hen vraagt en volgen je instructies. Ik ben met een uitbreidde applicatie bezig en ik durf wel te zeggen dat de code nagenoeg optimaal is, temeer omdat ik zelf ook om refactoring, optimalisaties en code reviews vraag.

[Moortn]

Je bepaalt de architectuur zelf he

Dat kan. Er zijn ook genoeg mensen die AI enkel functionele opdrachten geeft en geen idee hebben wat voor code AI heeft bedacht. Op LinkedIn zie ik genoeg berichten van mensen die zonder enige programmeerkennis een "AVG-proof" applicatie hebben "gemaakt" met AI. De architectuur en kwaliteit van de code kan dan alle kanten op gaan, zeker als features in een onlogische volgorde worden toegevoegd.

Voor een hobby projectje waar ik 2 jaar geleden aan was begonnen en behalve de basis niks aan heb gedaan, is de code van AI (mix van modellen, afhankelijk van m'n prompts) ook niks slechter dan wat ik zelf zou verzinnen. Hij bouwt verder op wat ik al had bedacht en de instructions worden continu bijgewerkt voor gevallen waar nog geen voorbeeld van was.

[bzuidgeest]

Ik ben het met de rest eens dat je dan gewoon slecht duidelijk hebt gemaakt wat je wil. Jij stelt de vraag, als je iets verwacht moet je dat melden.

Ondertussen hebben die dingen voor mij fpga designs gemaakt, code voor de pico, reverse engineering met ghidra van dos games, reverse engineering van microcontroller code, gewoon .net of c programmeren. Source code port van de ene taal in een taal die beter in mijn straat of eigen code past.

Je kan het zo gek niet bedenken, je moet beetje bijsturen, maar met het juiste gebruik zijn ze zo goed dat ze ook door jou review heen moeten kunnen komen. Tenzij je iets heel bizars eist dan tegen alle zinnigheid ingaat (of jij nou geloofd of het moet of niet )

[Llopigat]

Voor zakelijk wel ja omdat je er geld mee kan verdienen (en mensen kosten ook geld) maar voor prive/hobby wordt het steeds minder bruikbaar op deze manier.

[Reactie gewijzigd door Llopigat op 17 april 2026 15:36]

[ocf81]

Zou het niet zo zijn dat op een gegeven moment lokaal draaien toch een betere kosten/baten-plaat oplevert?

[Oon]

Lokale LLM's zijn vooralsnog totaal niet te vergelijken, want 99% van de kracht van deze tools zit in wat ze er omheen hebben gebouwd. Het LLM zelf is niet veel veranderd t.o.v. GPT-3 behalve dat er meer data in zit en meer resources achter zitten, maar dat het nu andere tools kan aanroepen e.d. is wel een groot verschil.
Dat totaalpakket terzijde zijn lokale LLM's zelfs op absurde hardware nog steeds traag en onbetrouwbaar, dus tenzij je 20.000 euro gaat uitgeven aan een LLM-server voor thuis blijft het lastig te vergelijken.

Uiteindelijk zullen we wel op een punt komen waar de bubbel knapt en diensten als Claude en ChatGPT niet meer het gebruik subsidiëren door enorme verliezen te draaien, en dan zul je als gebruiker véél meer moeten gaan betalen. Misschien dat dan de kosten van zo'n dienst zo hoog worden dat thuis hosten interessant kan worden.

[ZpAz]

Van de agentic coding systemen zijn ook open source varianten van zoals https://opencode.ai/ waar je elke tool-aanroepende LLM in kan haken. Wat bijvoorbeeld met een GPT 3.5 al wel kon, ga je zeker niet dezelfde resultaten halen als met de moderne systemen. Er zit echt wel een wereld van verschil in de verschillende levels.

Hier een pagina met een benchmark voor coding per verschillende modellen, als je helemaal rechts kijkt zie je GPT 4 in het lijstje staan. Drie zou nog wel een stuk lager scoren, maar ik weet niet eens of GPT 3 tool calling doet.

Er zijn wel open source modellen die je wel thuis zou kunnen draaien als je goede hardware hebt, welke agentic kunnen programmeren, maar vooralsnog wil je dan wel redelijk flinke hardware en zijn ze echt wel een stuk minder slim dan de top modellen.

[Reactie gewijzigd door ZpAz op 17 april 2026 15:19]

[batjes]

Met Ollama en andere tools kun je dit soort systemen zelf eromheen bouwen. Werkt verassend goed.

Het is de capaciteit, voor een beetje deftig model heb je al snel 100gb aan VRAM nodig. Dan wordt het al heel snel duur om het allemaal zelf te draaien.

[Utrecht25]

Kort antwoord: Normaliter niet.

Je moet echt bijna fulltime met Claude praten om aan het 200 Eur per maand abo te komen.

Daar tegenover is het beste open source model op dit moment geloof ik Minimax M2.7, wat een beetje achter blijft op claude opus, en bij voorkeur op ~460 GB VRAM draait... Google Gemma is ook een optie, maar dat is een zwakker model en wil ook liefst 32 GB.

Op korte termijn gaan we allemaal wel lokaal LLM's draaien op onze pc's en gsm's, maar meer voor bijvoorbeeld simpele taken zoals speech-to-text en zeer simpele zaken zoals iets aanpassen in je kalender, een mailtje sturen, etc.

[ocf81]

Tja, ik draai nu lokaal Ollama met twee W6800's. Dat is voor de gemiddelde taak wel oké. Voor auto-complete ook wel, als je de context goed meegeeft. Voor het opstellen van hele programma's schiet het inderdaad nog tekort.

[Sircuri]

Ik merk de laatste paar dagen hetzelfde. Ik heb ook het Max abonnement (108 EUR) en had zowaar begin deze week dat mijn CLI ineens de befaamde "you have used 98%" berichten begon te tonen en de boel tot een halt kwam. Door een 2-tal wijzigingen in het beleid van Anthropic had ik bij elkaar iets van 100 euro aan gratis "extra" credits gekregen over en die gaan er nu ook heel hard doorheen.

[Oon]

Ja die extra usage is een beetje als een UPS bij stroomuitval; tijd om je spul netjes af te sluiten, maar je kunt echt niet verder werken. Bij Pro was ik meer kwijt aan extra usage dan aan het abonnement zelf.

[Sircuri]

Die extra credits zijn inderdaad als de 10 EUR per MB dat je over je data-bundel heen gaat. Maar goed, dat is gratis gekregen.

[bzuidgeest]

Ik zit bij augment code en opus 4.7 is 50% off tot eind april. Dus even goed gebruik van maken.

[Yellow]

Leuk deze verbeteringen op "papier", maar na zo'n benchmark wordt de performance toch een stukje teruggeschroefd. Ik ben dus echt benieuwd naar Mythos.

[Bouwer21000]

Waar baseer je dat op?

[Stukfruit]

Zie deze GitHub issue van iemand bij AMD.

Eerst benchmarks, daarna terugschroeven.
Wel icm Claude Code.

[Reactie gewijzigd door Stukfruit op 17 april 2026 15:54]

[aiDisCus]

De kunst is ook om de juiste benchmark(s) te laten zien of niet te laten zien, zie ook dit commentaar: https://www.reddit.com/r/BetterOffline/comments/1snrb48/claude_opus_47_shows_a_significant_regression_on/

[The-Source]

Ik kreeg nu juist bij lovable.dev de melding dat door het uitbrengen credit kost tot het einde van de maand lager is dan normaal( op lovable). Maar in hoeverre lovable op de achtergrond Anthropic gebruikt weet ik natuurlijk niet.

[ZpAz]

Dan heb je iets gemist op dat bericht .

[The-Source]

Volgens mij is dat toch juist wat ik zeg, dat het minder credits kost. Maar dat bericht betekend niet direct dat ze het ook gebruiken. Beschikbaar vs gebruiken

[Stukfruit]

Wat in het artikel staat is een marketinguiting van Anthropic zelf, maar afgaande op dit, dit (blijkbaar iemand bij AMD, bevat veel testresultaten), dit en eigen ervaringen met 4.6 die sinds een paar maanden merkbaar verslechterd is zou ik eerst graag onafhankelijke resultaten willen zien.

In het kort: meer hallucinaties, minder goed prompts volgen, standaard minder "denken", minder duidelijkheid. En tussen de regels door met enige voorzichtigheid bevestigd door een werknemer bij Anthropic:

> Thinking depth had already dropped ~67% by late February

We landed two changes in Feb that would have impacted this. We evaluated both carefully:

1/ Opus 4.6 launch → adaptive thinking default (Feb 9)

Opus 4.6 supports adaptive thinking, which is different from thinking budgets that we used to support. In this mode, the model decides how long to think for, which tends to work better than fixed thinking budgets across the board. `CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING` to opt out.

2/ Medium effort (85) default on Opus 4.6 (Mar 3)

We found that effort=85 was a sweet spot on the intelligence-latency/cost curve for most users, improving token efficiency while reducing latency. On of our product principles is to avoid changing settings on users' behalf, and ideally we would have set effort=85 from the start. We felt this was an important setting to change, so our approach was to:

...

Deze wijzigingen voor 4.6 lijken niet meer te werken voor 4.7.

[Reactie gewijzigd door Stukfruit op 17 april 2026 15:28]

[i7x]

Wel goed om ook te vermelden dat de abonnementen nu ook meer tokens mogen gebruiken. Dus dat compenseert het wel wat. En als je de andere modellen gebruikt is dat al helemaal een voordeel.

[TheVivaldi]

Ben ik de enige die bij het lezen van de titel aan de codec dacht?

[michelr]

Tokenfactor in GitHub is 7.5. Joejoe!

[XC9]

Ja dit is wel bijzonder. Ik hoop dat dit nog gaat veranderen. Ik las op X dat ze de rate limits hebben aangepast zodat het in Claude Code niet veel meer verbruikt dan 4.6. Waarschijnlijk nog een truc om mensen Claude Code te laten gebruiken ipv het model te gebruiken in bijv. GitHub Copilot...

[Reactie gewijzigd door XC9 op 17 april 2026 16:47]

[Tom970G1]

Claude had hier wmb een flinke achterstand op codex. Claude max geprobeerd maar een refund genomen. Claude had veel meer bijsturing nodig en was veel chaotischer en risicovoller dan Codex

[zndrwrk]

Ik ben geen developer maar heb wel in het verleden wat gedaan. Dankzij Claude heb ik een heel leuk systeem kunnen uitwerken op basis van mijn huidige werkervaring. Maar ja, het blijft ook A.I. dat zit te zeggen dat het goed in elkaar zit maar ik heb niemand die het echt challenged. Ik zit er eigenlijk echt mee, uiteindelijk heb ik niets meer dan een werkende prototype dat ik liever aan een team echte devs wil geven.

Daar zie ik dan wel weer toekomst in, een echte domein expert heeft een visie van hoe iets moet werken. Functionaliteiten, edge cases, ... Een developer heeft zijn eigen sterkes maar gaat niet in hetzelfde hokje als een domein expert denken. Ziet bepaalde logica niet voor wat het is etc..

Om een interne tool te bouwen voor je bedrijf, al is het een redelijk simpele converter van data via python, moest eerst door een hele hoop loops gaan om goedgekeurd te worden. Project manager betrekken die je visie vertaalt. Backend devs, frontend devs.. Niet prioriteit, dus back of the line en "we zien wel wanneer er tijd voor is". Een jaar wachten.

Nu? Je komt met een idee en je weet vrij snel of het 1) haalbaar is en 2) effectief interessant is voor je werk.


In mijn geval: Ja. Ik wil het in productie. Maar durf ik te doen met de tool gemaakt door Claude? Kan ik geen antwoord op geven.

[jhnddy]

Als developer is mijn ervaring met domein experts dat ze heel knappe tooltjes kunnen ontwikkelen die het werk een stuk makkelijker maken, o.a. flink wat Excel macro's, maar vaak komt er dan een tool uit die:

• Perfect werkt voor degene die het verzonnen heeft, maar heeft een dusdanig complexe handleiding dat het nauwelijks over te dragen is
• Foutgevoelig is bij verkeerd gebruik
• Risico's hebben op het gebied van security
• Dusdanig zijn opgezet dat het nu werkt, maar niet schaalbaar

Met een beetje pech wordt zo'n tool al bij een paar klanten ingezet, die dan laaiend enthousiast zijn en aan Software Development vragen om er even een webtool van te maken die gelijk voor alle klanten gebruikt kan worden.

En dan gek opkijken dat een tool die data integriteit en veiligheid waarborgt en begrijpelijk is voor de gebruikers, langer dan 2 dagen prototypen kost om in elkaar te zetten