Anthropic brengt Claude Opus 5.5 uit, goedkoper dan voorganger

Anthropic heeft Claude Opus 5.5 uitgebracht. De nieuwe versie moet vooral goedkoper zijn dan zijn voorganger, Opus 5.0, zo claimt het bedrijf. De prijs van input- en outputtokens is 20 procent lager dan bij Opus 5.0.

De besparingen moeten vooral merkbaar zijn in Claude Code, zegt Anthropic. Opus 5.5 denkt bovendien altijd na voordat het antwoordt, wat meer tokens kan kosten. "We verwachten dat mensen meer gedaan krijgen met Opus 5.5, maar dit verschilt per taak. Meet het dus aan de hand van je eigen werk", aldus het bedrijf.

Opus 5.5 kost 4 dollar per miljoen inputtokens en 20 dollar per miljoen outputtokens. Dat is 20 procent minder dan Opus 5. De prijs voor het lezen uit de cache daalt van 50 dollarcent naar 20 dollarcent per miljoen tokens.

Opus 5.5 heeft daarnaast antwoorden die volgens het bedrijf beter te scannen zijn, wat vooral handig is bij lange sessies. Opus 5.5 zou helderder schrijven dan voorgaande modellen. Ook zou het model minder snel geneigd zijn om regels te breken dan eerdere modellen.

Reacties (73)

[jared9]

Ik ben sinds kort aan het experimenteren met een andere aanpak in Claude Code: niet één model voor alles, maar verschillende modellen als subagents.

Mijn huidige setup:

• Sonnet als main agent: planning, beslissingen en orkestratie
• Haiku als scout: codebase doorzoeken, inventories en read-only analyse
• Sonnet als builder: normale implementatie en bugfixes
• Opus 5.5 als reviewer: lastige bugs, architectuur en correctness reviews

De gedachte is dus niet "Opus is beter, dus alles op Opus", maar het juiste model voor het juiste soort werk. De main agent bepaalt wanneer een subagent nodig is.

Vooral interessant vind ik dat een complexe taak dan bijvoorbeeld zo kan verlopen:

Sonnet → Haiku (onderzoek) → Sonnet (implementatie) → Opus (review)

In plaats van de hele taak continu op Opus te draaien.

Ik ben benieuwd hoe anderen dit aanpakken. Gebruikt iemand Claude Code ook op deze manier met verschillende modellen/subagents, of houden jullie het gewoon bij één model per sessie?

[LesCacques]

Ik zie hier veel reacties in de trant van "ik zweer bij Fable" of "ik zweer bij Opus 4.8". Maar als je altijd één model gebruikt, haal je 100% niet alles uit je tokens. Welk model je kiest, zegt weinig over wat eruit komt. Hoe je ze inricht en orchestreert wel.

Ik gebruik zelf een iets andere aanpak. Haiku zet ik eigenlijk alleen in voor triviale classificatietaken, zoals bepalen of iets een vraag of een formulier is. Sonnet is bij mij de main agent én de orchestrator. Afhankelijk van de complexiteit zet ik Opus of heel af en toe Fable in voor planning, exploratie of complexe ontwerpkeuzes. Het bouwen zelf gebeurt vrijwel altijd met Sonnet. Met een goed plan is het meestal gewoon doewerk, en Sonnet is daar een stuk sneller in.

Ik heb een graph opgezet die niet-sequentieel werkt. Er is één orchestrator die voortdurend kijkt naar de status van een taak en bepaalt wat de volgende stap moet zijn. Die graph haalt via MCP bijvoorbeeld een release op basis van een ID uit ons planningssysteem, exploret vervolgens de codebase en deelt de release op basis van vooraf ingestelde businesslogica in naar impact: small, medium, large of te groot. Dat gaat dus niet alleen over hoeveel code er geschreven moet worden, maar vooral over hoeveel bestanden, systemen en businesslogica geraakt worden. Een te grote release wordt eerst verder opgesplitst.

De planning gebeurt grotendeels met Sonnet. Bij complexe releases kan Opus de planning overnemen. Ik zit tijdens die fase meestal in de loop: de agent stelt vragen totdat de requirements en de oplossing voldoende duidelijk zijn. Front-enddesign is daarbij een verplicht onderdeel van het plan en loopt via een eigen /frontend-design skill. Zonder goedgekeurd design mag Sonnet alleen de backend aanpassen. Dat soort guardrails heb ik op meerdere plekken ingebouwd.

Na de planning gaat de implementatie van start. Ook daar bepaalt de graph op basis van de complexiteit, het aantal betrokken bestanden, eerdere fouten en benodigde interventies welk model eventueel nodig is. In de praktijk is dat bijna altijd Sonnet.

Daarna volgt een review, gaan de wijzigingen naar GitHub CI en worden de tests uitgevoerd. Als iets faalt, kan Haiku bijvoorbeeld de status van de CI-run monitoren. Sonnet analyseert vervolgens het probleem en voert de fix uit. De graph kan daarna opnieuw door de relevante stappen lopen. Het is dus geen lineaire pipeline, maar een systeem waarin taken terug kunnen springen naar eerdere stappen en waarin de orchestrator steeds de actuele status bepaalt.

Overdag maak ik meestal de plannen samen met de agent en ben ik actief betrokken bij de besluitvorming. Daarna start ik een release-loop die onbewaakt draait. Die haalt alle goedgekeurde, nog niet uitgevoerde plannen uit ons planningssysteem en werkt ze af. Als ik er weer bij kom, liggen er doorgaans complete PR's klaar, inclusief een end-to-end rapportage. De agent controleert de functionaliteit ook zelf, in een aparte browsersessie.

Ik loop de PR's en de code uiteraard nog zelf na. Niet omdat de graph niets kan, maar omdat je uiteindelijk een manier nodig hebt om de kwaliteit van de output goed te kunnen beoordelen. Binnen vaste kaders mag de agent zelf beslissingen nemen op basis van bestaande conventies, maar er wordt niets gemerged zonder mijn akkoord.

Na iedere release doet de graph een retrospectief en stelt hij verbeteringen aan de workflow voor. Zelf typ ik nog maar weinig code. De meeste tijd gaat naar het ontwerpen van de graphs, het aanscherpen van de guardrails en vooral het verbeteren van de rapportages en evaluaties.

Sinds de laatste ombouw van de loop ging de mediane tijd van goedgekeurd plan tot de eerste merge van ruim 14 uur naar 4 uur. Het aantal opgeleverde wijzigingen ging van zo'n 11 naar 38 per week, verspreid over ruim 120 PR's in backend, frontend en design system. In augustus draaide nog zo'n 85 procent van de tokens op Opus. Nu is dat zo'n 60 procent Sonnet en een kleine 40 procent Opus, en Fable en Haiku zijn samen nog geen 2 procent.

Het zijn indicaties, maar ze laten wel zien waar het om draait. Een lichter model als standaard maakte het niet slechter. De inrichting maakte het sneller.

Wat níet verbeterde: het aantal bugs dat erdoorheen glipt en pas later boven komt. Dat blijft rond de 15 à 18 per 100 PR's. Sneller en meer bouwen lukt dus prima. Beter bouwen gaat niet vanzelf mee.

Dat vind ik eigenlijk ook het belangrijkste onderdeel. Het bouwen van een agent is niet zo moeilijk. De uitdaging zit in het ontwerpen van een systeem waarbij je betrouwbaar kunt vaststellen of de opgeleverde software daadwerkelijk goed genoeg is. Daar besteed ik waarschijnlijk meer aandacht aan dan aan de modelkeuze zelf..

[donviktor]

Thanks voor de inzichten!

[devastator83]

Kan je wat meer uitleggen over je 'graph' ?
Wat is het precies ?

[LesCacques]

Het is geen framework of library, eerder een manier van inrichten. Ik heb het gebouwd met gewone Claude Code-commands en subagents.

Bij mij bestaat het uit een handvol agents die elk één ding goed doen: eentje verkent de codebase, eentje plant, design/UX, er zijn builders voor backend en frontend, een tester, een PR-reviewer, eentje die alleen checkt of frontend en backend op elkaar aansluiten, en een fixer. Ze hebben elk hun eigen instructies, tools en model.

Daarboven zit een orchestrator. Die houdt de status van een taak bij in ons planningssysteem en kijkt na elke stap wat er op dat moment nodig is. Het verschil met een vaste loop is dat de volgorde niet vastligt. Een taak kan terug naar een eerdere stap, en een agent wordt alleen ingezet als de situatie daarom vraagt.

Een voorbeeld: een CSV-export toevoegen aan een overzicht. De scout ziet dat er elders al een export bestaat, dus het wordt hergebruik in plaats van nieuwbouw. De planner maakt een plan, en omdat het design voor de knop nog niet is goedgekeurd, begint alleen de backend-builder. De tester draait de export met 50.000 regels en loopt tegen een timeout aan. Dan gaat de taak niet door naar review, maar terug naar de planner, want de export moet gestreamd worden. Als het design er is, bouwt de frontend-builder de knop. Omdat de wijziging nu frontend en backend raakt, komt de reviewer voor de aansluiting erbij. De PR-reviewer ziet dat de export niet op klant filtert, dus terug naar de fixer. Faalt daarna de CI, dan houdt Haiku de run in de gaten en lost de fixer het op.

Een simpele tekstwijziging gaat daarentegen van planner naar builder naar review en is klaar. Voor mij zit daar de grootste winst: de zware en specialistische stappen kosten alleen tokens als ze echt nodig zijn.

[henkjobse]

Heb je dit op een of andere manier geautomatiseerd via Claude.md of hooks oid?

[jared9]

Dit staat in CLAUDE.md

## Model routing (subagents)

Use the cheapest model capable of completing the task correctly. Keep simple work with the main agent — only delegate when a subtask is independent and delegation provides a meaningful benefit (parallelizable, or a different model tier genuinely fits better). Subagents in `.claude/agents/`:
- `scout` (Haiku) — searches, codebase exploration, inventories, summaries.
- `builder` (Sonnet) — routine implementation, bugfixes, mechanical refactors.
- `reviewer` (Opus) — complex debugging, architecture/design decisions, correctness-critical review — especially after a cheaper model already tried, or for changes where getting it wrong is costly.

Avoid duplicate work and overlapping file ownership between parallel subagents — split by file/directory, never assign the same file twice. The main agent always integrates and verifies delegated work (build, typecheck, tests) before considering it done — check the actual diff/output, not just the subagent's summary.

[machiel]

Op welke manier in Sonnet beter als builder dan Opus?

[Creesch]

De gedachte is dus niet "Opus is beter, dus alles op Opus", maar het juiste model voor het juiste soort werk.

Zoals ik het lees is Sonnet in de ogen van jared meer dan voldoende voor de standaard builder taken. Wat weer in de kosten zal schelen aangezien Sonnet tokens goedkoper zijn dan Opus tokens.

[jared9]

Niet per se. Mijn gedachte was dat Sonnet voor goed afgebakende implementatietaken waarschijnlijk voldoende is, terwijl Opus vooral meerwaarde heeft bij complexere analyse, architectuur en review. Maar dat is precies het soort verdeling dat ik met deze setup probeer uit te zoeken.

[PdeBie]

Wij hanteren een soortgelijke methode. Sonnet voor codeklop werk wat al uitgedacht is. Opus voor het diepere denkwerk. Haiku gebruik ik zelf zelden. Alleen als het echt heel basaal werk is.

Opus in combinatie met de superpowers plugin als het echt heel diepgaand denkwerk vereist.

[Reactie gewijzigd door PdeBie op 23 september 2026 07:36]

[Nozzit]

Ik gebruik zelf fable bijna altijd om mee te praten en om subagents aan te sturen. Ik heb Claude ook verboden om sonnet te gebruiken omdat het voor veel werk duurder is dan opus, ik gebruik zelf liever opus op lagere effort levels als bouw agents.

Als jij goede resultaten haalt met jouw huidige oplossing dan raad ik je echt aan om over te stappen op codex, hun opus/sonnet achtige middelen zijn kwalitatief beter én een stuk goedkoper en enorm tokens efficiënt.

[jared9]

Interessant. Gebruik je Codex hiervoor via de API, of is er een vergelijkbaar abonnement als Claude Pro waarbij dit gewoon binnen je abonnement valt?

[Nozzit]

je kunt gewoon een chatgpt plus of pro abbo nemen. werkt perfect. is ongeveer hetzelfde idee als de claude abbonementen

[KennethDC]

Ik neem Opus voor het plannen ook trouwens.

[Extraxyz]

Gewoon model opusplan gebruiken, pakt uit zichzelf Opus om te plannen, Sonnet om te bouwen.

[Davidshadow13]

Ik merk m.b.t gebruik in Cursor hetzelfde. Composer 2.5 op low effort scoort vaak beter en sneller op simpele implementatietaken t.o.v. Grok 4.7 of Antrophic modellen. Ik heb dus ook low effort sub agents ingestelds voor simpele tickets en gebruik de grote modellen alleen voor uitgebreidde nieuwe features in Plan modus waarna de losse implementaties met de kleinere modellen weer naar sub agents gaan.

[ZpAz]

Haiku loopt echt zo ver achter op alles. Zo’n drie schaal setup zou ik wel met Luna, terra, sol doen van gpt. Bij Claude doe ik dan ook gewoon sonnet voor het zoeken naar met minder reasoning tokens.

[M14]

Hoe doe je dat? Is dat te automatiseren?

[jared9]

Dit staat in CLAUDE.md

## Model routing (subagents)

Use the cheapest model capable of completing the task correctly. Keep simple work with the main agent — only delegate when a subtask is independent and delegation provides a meaningful benefit (parallelizable, or a different model tier genuinely fits better). Subagents in `.claude/agents/`:
- `scout` (Haiku) — searches, codebase exploration, inventories, summaries.
- `builder` (Sonnet) — routine implementation, bugfixes, mechanical refactors.
- `reviewer` (Opus) — complex debugging, architecture/design decisions, correctness-critical review — especially after a cheaper model already tried, or for changes where getting it wrong is costly.

Avoid duplicate work and overlapping file ownership between parallel subagents — split by file/directory, never assign the same file twice. The main agent always integrates and verifies delegated work (build, typecheck, tests) before considering it done — check the actual diff/output, not just the subagent's summary.

[dragoon2000]

Mag ik vragen wat jouw ervaring is met het vermogen van een model om in te schatten of iets "simple work" is/zal gaan zijn? Is dat iets wat in de 'plan' fase afdoende in kaart wordt/kan worden gebracht?

Mijn instinct is hier dat je een model vraagt om 1) zelf in te schatten wat binnen diens vaardigheden valt en 2) wat gebeurt er als een model zonder voorafgaande planning een vraag gesteld krijgt waarvan het gedurende een 'turn' duidelijk wordt dat het toch dermate complex lijkt dat het beter aan een groter model had kunnen worden uitbesteed.

Of praat ik onzin? Ik heb er niet zo veel verstand van zeg ik erbij

[jared9]

De reactie gaat nog uit van mijn oude workflow. Die heb ik inmiddels aangepast. De huidige workflow is:

Sonnet bepaalt eerst de route. Een simpele, bekende wijziging gaat rechtstreeks naar de builder. Een meerstapstaak waarbij de oplossing al duidelijk is ook. Alleen als er daadwerkelijk een complexe/open ontwerpvraag is, wordt eerst Opus als planner ingezet. Die levert onderzoek en ontwerpinput, waarna Sonnet het ontwerp verder verwerkt en toetst.

Daarna kan er tijdens de uitvoering alsnog worden opgeschaald. Als de builder vastloopt of iets onduidelijk blijkt, gaat alleen die stap naar planner of reviewer, niet de hele taak opnieuw. En als de reviewer een defect vindt, worden alleen de gefaalde stap en eventuele afhankelijke stappen opnieuw gedaan.

Daarmee blijft je oorspronkelijke vraag overigens wel interessant: hoe betrouwbaar is Sonnet in het vooraf herkennen dat iets buiten de categorie "simple work" valt? De workflow gaat er in ieder geval niet vanuit dat die eerste inschatting altijd goed is.

[cmegens]

Ik doe een soortgelijk iets in combinatie met lokale kleine modellen. Alleen het lokale model mag dan ook mijn computer doorzoeken.

[Mittchel]

Ik doe vrijwel hetzelfde, heb daar een workflow voor geschreven maar mijn model indeling is iets anders.

Mijn huidige setup:

• Opus 5.5 voor planning, merkte dat kwaliteit van plan beter is
• Haiku/sonnet: orchestration (recent naar sonnet geswitcht, ben wat testjes aan het doen)
• Sonnet als builder
• Opus 5.5 als reviewer: reviewed de geimplementeerde code en daarna ook fixen

Werkt tot nu zeer goed, vindt ook echt wel dingen tijdens het reviewen en fixen. Verder gebruik ik graph memory om makkelijker door de code te gaan. Scheelt tokens en speed.

[slijkie]

Idem hier, alleen bij mij net iets anders, ik ben overgestapt volgende;

- Lokaal LLM, Qwen 3.8 voor bulk werk

- Grok Build voor snel code werk, ook bulk

- Opus 5.5 voor code-review

- Fable 5.1 voor planning

- GPT6-Astra voor Design en mockups

Bonus: Grok Bots voor heel veel taken los van de coding, werkt echt fantastisch.

[Reactie gewijzigd door slijkie op 23 september 2026 14:21]

[Gamebuster]

Ik doe gewoon Opus/Fable voor alles en gebruik meerdere Max accounts, maar als ik wil besparen zou ik de spec + plan door top modellen laten schrijven en implementatie door Sonnet, met wat extra prompts dat als-ie tegen onvoorziene zaken loopt, dat-ie opus/fable moet oppakken. Die moeite heb ik nog niet genomen, met 2 accounts red ik me prima.

[Reactie gewijzigd door Gamebuster op 24 september 2026 07:58]

[Luchtbakker]

Sinds Fable er is denk ik er niet meer aan om Opus te gebruiken. Vorige week heb ik Opus 5 eens gebruikt in plaats van Fable 5.1. Ik heb dit gelijk afgeleerd, want zelfs bij wat simpelere taken (een button hiden onder bepaalde situaties) zorgde voor een fout en crash in react.

Fable 5.1 met effort op low is nagenoeg foutloos. Ik ga daarom echt geen poging meer doen Opus te gebruiken. De verschillen zijn gewoon veel te groot.

[Zenomyscus]

Sinds Fable er is denk ik er niet meer aan om Opus te gebruiken. Vorige week heb ik Opus 5 eens gebruikt in plaats van Fable 5.1. Ik heb dit gelijk afgeleerd, want zelfs bij wat simpelere taken (een button hiden onder bepaalde situaties) zorgde voor een fout en crash in react.

Fable 5.1 met effort op low is nagenoeg foutloos. Ik ga daarom echt geen poging meer doen Opus te gebruiken. De verschillen zijn gewoon veel te groot.

Ondertussen stamp ik hier feature na feature eruit met Opus 5, terwijl ik met Fable heel snel aan het limiet zat. Misschien heeft je eigen setup ook invloed op hoe goed een model werkt, maar ik verbaas me soms over de haat op Opus 5. Ik ben benieuwd morgen naar 5.5 en ga er gelijk mee aan de slag.

[Luchtbakker]

Het tokengebruik van Fable valt mee als je effort op low zet, en heeft naar mijn idee betere resultaten dan als je Opus 5 op High of Max zet. Maar dat is mijn persoonlijke ervaring.

En mijn bovenstaande fout was zelfs ontstaan nadat ik codeultra gebruikte, en hem zijn eigen werk nog heb laten controleren op bugs.

Vervolgens was de bug met Fable op low binnen 2 minuten gevonden zonder toelichting.

[Zenomyscus]

Ik denk er eigenlijk nooit aan om op medium of low te testen, altijd high. Dan was Fable vrij duur. Maar los daarvan liep ik ook sneller tegen beveiligingslimieten aan. Security gerelateerde vragen werden vrij snel geblokkeerd. Met Opus was dat niet zo. Hopelijk blijft dat zo met 5.5.

[CorbataGames]

Dit is ook mijn ervaring. Voor 95% van wat "ik" programmeer werkt opus top.

[Haribo112]

Opus 5 is ruk. Je moet 4.8 hebben, die gaat als een trein. Fable denkt veel te lang na en doet vervolgens domme aannames.

[phobosdeimos]

Volledig akkoord, ik zit ook nog steeds op Opus 4.8

Opus 5 is zowel trager als dommer.

[SawedOff]

Ja 4.8 is echt kanon. Ik gebruik Sonnet voor claude chat en opus 4.8 voor claude code. Fable heb ik niet, want ik heb het pro plan van 20 euro per maand, maar ik moet zeggen dat opus goed genoeg is, mits je gewoon de juiste prompts en markdown hebt.

[wou5er]

absoluut en voor wat ingewikkeldere problemen kun je fable prima gebruiken om te een onderzoek te doen waar die dan weer wel sterk in is.

[n9iels]

Dit is niet mijn ervaring om eerlijk te zijn. En dat zeg ik als mede React (native) developer. Ik gebruik Sonnet 5, wat dus "dommer" dan Opus zou moeten zijn, voor bijna al mijn werk en kom daarmee prima uit de voeten. Genoeg context geven, taken klein houden en grote taken met de "grill-me-with-docs" voorbereiden. Het gebeurd zelden dat er echt troep uit komt.

[moonlander]

Ik gebruik nog altijd Sonnet omdat ik denk dat dat goedkoper is aan tokens dan Opus.. Of heb ik dat mis? Terwijl Sonnet ook prima code levert.

[W!mpix]

Hangt wat van de taak af, als Sonnet er veel langer over moet doen kan het duurder zijn, maar meestal goedkoper idd

[Cartman!]

Voor typescript werk zit ik nog op Sonnet 4.5, snel en effectief voor wat ik ermee doe en ik kan de hele dag door rommelen zonder rap door credits te gaan. Een paar keer de 5.x serie gebruikt (zowel Sonnet, Opus en Fable) en toen zat ik na n half uurtje al over de helft van m'n credits voor de dag terwijl ik de weinig extra aan merkte qua output.

[pizzafried]

Ik heb ook niet echt de behoefte om Opus te gaan gebruiken. Als je je werk goed afbakent en documenteert (en nee, daar gebruik ik die plan tool van ze niet, maar gewoon een lekkere spar sessie met het model), en zorgt dat het in hapklare blokken klaar ligt (ik werk in branches, dus dan baken ik gewoon af wat er per branch in gaat), en dan hoef je eigenlijk vrij weinig te sturen. En als je iets moet sturen dat ook voor de toekomst geldt, afhankelijk van de situatie leg je dat vast in z'n memory, claude.md of het plan zelf. Over het algemeen kom ik dan per dagdeel en zelfs de hele week wel uit.

[L0g0ff]

Ik zie dat ze in de laatste claude code (2.1.280) nu ook de default op opus 5.5 hebben gezet.

Ik heb laatst een fix geschreven voor CLIProxyAPI dat ik Claude ook kon gebruiken met de 18 euro per maand abonnement icm hermes agent en de sonnet, opus en fable 5 serie. Standaard viel die namelijk terug naar die sonnet 4.x serie. Ik zal eens kijken wat ik aan moet passen om ook opus 5.5 werkend te krijgen.

[Cerebriform]

Oh Wauw dat klinkt wel goed, hoe gebruik ik een relay service, met mijn eigen account?

[L0g0ff]

Met je eigen claude code account inderdaad. Opus 5-5 fix zit er ook in en readme.md met howto is aangepast. Have fun

[thomvh]

Dat is wel tegen de ToS an Anthropic in, anders had ik dat ook al lang gedaan!

[ChristopheS]

Vanaf ze de hermes.md detecteren zie ik Usage credits ipv mijn subscriptie allowance gebruikt worden.

Ga zij tool eens gebruiken en zien of het helpt

[thomvh]

Klopt. Zijn tool werkt om de Toss van Anthropic heen. Om zo toch subscriptie te kunnen gebruiken. Anthropic zegt zelf dat je alleen als jij het zelf draait je subscriptie mag gebruiken.

[JJ Le Funk]

GLM 5.3 $4,40 per miljoen output tokens
Opus 5 $25
Tja, als geld geen rol speelt ga lekker voor Opus 5.5 maar voor de gewone man/vrouw zijn er gelukkig ook alternatieven (minder snel, minder goed, maar je kan wel vooruit komen).

[Reactie gewijzigd door JJ Le Funk op 22 september 2026 21:38]

[Rhizix]

Dan vergeet je dat GLM 5.3 (en veel va de andere Open Weight models) zoveel meer tokens nodig heeft om hetzelfde te bereiken, dat Sol of Opus stukken goedkoper zijn op eenzelfde of beter resultaat te bereiken.

Linkje naar cost per task comparison


En ja, benchmarks zeggen natuurlijk niet perse iets over real world usage, maar sluit wel goed aan bij mn eigen ervaring

[Reactie gewijzigd door Rhizix op 22 september 2026 22:05]

[dmantione]

Dat kan ik niet staven, in ieder geval niet het over één kam scheren van de open-weight-modellen. Mijn ervaring met GLM 5.3 Flash alias Ox Alpha is dat het juist redelijk zuinig omgaat met tokens, het is stukken minder praatzaam dan bijv. Deepeek. Deepseek genereert vaak pagina's aan tekst voordat hij een stap zet, terwijl Ox Alpha het meestal bij enkele alinea's houdt. En dan zet ik Deepseek al op "low"... wat het moet worden als je het 'm op "max" zou zetten. En ook MiMo 2.5 is een stuk minder spraakzaam dan Deepseek, maar ook aanzienlijk minder capabel.

Daarmee kan je ook al een onderscheid maken voor welke taken ze het meest geschikt zijn: Ox Alpha voor zaken die duidelijk zijn en gericht aangepakt moeten worden. Als de context schoon gehouden moet worden wordt dat een voordeel. Deepseek moet je inzetten als kwesties van vele zijden belicht moeten worden om weloverwogen beslissingen te nemen.

Jouw link vertelt iets anders: De prijs om een complexe klus te klaren. De klussen in dat soort benchmarks zijn vaak complexe klussen die de modellen zelfstandig moeten uitvoeren zonder menselijke sturing, terwijl je in praktijk vaak heel sturend bent om te zorgen dat het resultaat bereikt wordt wat je in gedachten hebt.

[JJ Le Funk]

ja als je elke prompt resultaat 3x moet refactoren op een slakkentempo dan is dat geen plusje voor de kosten reductie

[TPar]

Maar is GLM 5.3 ook even goed?

https://aistack.imec-int.com/blog/agents-peeking.html

Het lijkt allemaal wat tegen te vallen.

Toegegeven ze hebben geen Opus getest omdat ze focussen op self-hosting maar het geeft toch aan hoe benchmark-resultaten met een korreltje zout moeten genomen worden (en neen niet omdat er wordt gecherry-picked).

[NietZomaar]

Het kan toch niet anders dan dat hier nog steeds extreem verlies op wordt geleden?

[Dynamix86]

Anthropic maakt inmiddels al winst, twee kwartalen op rij.

[Arjant2]

Operationeel winst ja. Als je de financiering niet mee telt.

Nog steeds indrukwekkend maar er moet nog heel wat geld terugverdiend worden.

[Reactie gewijzigd door Arjant2 op 22 september 2026 23:15]

[flurb]

Bugfix release dus ;)

Zie reddit voor alle publieke feedback op Opus 4.7 tot 5.
Het wegtrainen van eeuwig blijde feedback resulteerde in een twijfelende en warrig output.
Hopenlijk dat dit nu beter in balans is.

(Begon op een gegeven moment te twijfelen aan mijn eigen verstand bij het lezen van Opus 4.8 output, gelukkig was ik niet de enige (zie Reddit)

[base_]

Goedkoper hangt niet van de tokenprijs af maar van resultaat. Opus 5 kost mij vaak meer tokens voor een slechter resultaat als eerdere Opus versies. Lange antwoorden en snel afgeleid, met nog een hogere tokenprijs ook.

edit @flurb nou je het zegt, 4.6 leek het idd beter te doen!

[Reactie gewijzigd door base_ op 22 september 2026 20:22]

[MennoGamed]

Zijn we vergeten normaal te tellen? 8)7/s
Ik vraag me echter wel oprecht af wat de keuze geweest zou zijn om van 5.0 naar 5.5 te gaan?

[FanaticNL]

Wat betekent het tegenwoordig als ze een nieue model hebben? Trainen ze die dan met nieuee datasets? Of is het simpel gezegd slechts wat reasoning en output tweaken?