Modellen & evaluatie
Modelkeuze is een architectuurbeslissing, geen prijsvergelijking
Tien keer prijsverschil tussen het duurste en het goedkoopste model, drie redenen waarom dat getal misleidt, en wat een gepinde model-ID betekent voor je pijplijn.
Hoe diep wil je dit lezen?
3 blokken met methode, cijfers en voorbehouden — ook los open te klappen.
Anthropic's modeloverzicht staat op het moment van schrijven op vier actuele modellen. Het goedkoopste kost een dollar per miljoen invoertokens, het duurste tien. Op uitvoer is het vijf tegen vijftig. Een factor tien, over de hele linie.
Dat is het getal waar de meeste keuzegesprekken op stranden, en het is het minst informatieve getal in de tabel. Niet omdat prijs niet telt, maar omdat “per token” drie aannames verbergt die geen van drieën vanzelf waar zijn.
De eenheid die telt is niet de token, maar de geslaagde taak binnen je fout-, latency- en kostenbudget.
De tabel, als momentopname
Zoals het modeloverzicht van Anthropic hem op 23 augustus 2026 geeft, met de eigenschappen die er voor een pijplijn toe doen:
De vier modellen, met prijs, venster en latency
- Fable 5 (
claude-fable-5) — $10 / $50 per miljoen tokens, 1M contextvenster, 128k maximale uitvoer, latency “slower”. Beschreven als bedoeld voor langlopende agents. - Opus 5 (
claude-opus-5) — $5 / $25, 1M context, 128k uitvoer, latency “moderate”. Voor complex agentisch coderen. - Sonnet 5 (
claude-sonnet-5) — $2 / $10, 1M context, 128k uitvoer, latency “fast”. - Haiku 4.5 (
claude-haiku-4-5-20251001) — $1 / $5, 200k context, 64k uitvoer, latency “fastest”.
Let op wat er níét lineair meeloopt met de prijs. Het contextvenster is voor de bovenste drie identiek. De maximale uitvoer ook. Wat wél verschilt is latency, en dat staat er als een woord en niet als een getal.
Aanname 1: dat een token overal hetzelfde is
Dit is de scherpste, en hij staat in een voetnoot. Fable 5 gebruikt de tokenizer die met Opus 4.7 werd geïntroduceerd; ten opzichte van modellen van vóór Opus 4.7 levert dezelfde tekst daarmee ruwweg 30% meer tokens op. Hoeveel precies hangt van de inhoud af.
Wat dat betekent voor een vergelijking
Een prijs per token vergelijken tussen een model van vóór en van ná die wissel, is prijzen vergelijken in verschillende eenheden. Wie op de tabel afgaat en een model van een oudere generatie “goedkoper per token” noemt, moet dat verschil eerst wegrekenen. Bij 30% is dat geen afronding.
De praktische regel die daaruit volgt: vergelijk niet op prijs per token maar op prijs per afgeronde taak, gemeten op je eigen invoer. Dat is meer werk, en het is de vergelijking die je daadwerkelijk kunt gebruiken om te kiezen.
Reken het door naar de geslaagde taak
Zodra je op geslaagde taken rekent in plaats van op tokens, kan de goedkopere optie duurder uitvallen. Twee modellen, dezelfde taak:
- Model A — €0,10 per poging, slaagt in 60% van de gevallen. Je hebt gemiddeld 1,67 pogingen nodig, dus €0,17 per geslaagde taak.
- Model B — €0,20 per poging, slaagt in 90% van de gevallen. Gemiddeld 1,11 pogingen, dus €0,22 per geslaagde taak.
Illustratief voorbeeld, geen benchmark
De getallen hierboven zijn verzonnen om de rekensom te laten zien. Wat ik er wél mee wil zeggen: het verschil van twee keer de prijs per poging kromp tot dertig procent per geslaagd resultaat, en bij een iets ander slagingspercentage kantelt het helemaal. Zonder je eigen slagingspercentage is een prijsvergelijking dus niet af.
En dit is nog de eenvoudige versie. Een mislukte poging kost in een echte pijplijn meer dan z'n tokens: de tijd van een extra ronde, de tooluitvoer die opnieuw moet, en in het ergste geval iemand die het handmatig komt rechtzetten. Dat laatste is meestal de duurste post in de tabel en staat in geen enkele prijslijst.
Aanname 2: dat een contextvenster van 1M ook 1M bruikbaar is
Drie van de vier modellen dragen een venster van een miljoen tokens. Dat is capaciteit, geen belofte over kwaliteit — het vermogen om informatie uit de context terug te halen neemt af naarmate die context voller raakt. Dat is het onderwerp van een ander stuk hier, en het is de reden dat een groter venster zelden de oplossing is voor een agent die de draad kwijtraakt.
Voor een keuze betekent het: het venster is een randvoorwaarde, geen selectiecriterium. Een taak die 200k nodig heeft, kiest niet automatisch het model met 1M — die taak hoort eerst opgesplitst te worden.
Aanname 3: dat je vandaag hetzelfde model draait als vorige maand
Hier zit de bevinding die het minst bekend is en voor een autonome pijplijn het meest uitmaakt. De versioneringspagina benoemt het zelf als een veelvoorkomend misverstand: dat een datumloze ID zoals claude-sonnet-5 een evergreen verwijzing zou zijn die naar de nieuwste of best presterende versie routeert.
Een datumloze model-ID verwijst niet naar het nieuwste model. Het ís het model — zolang de leverancier hem zo definieert.
Vanaf de 4.6-generatie is de datumloze ID de canonieke ID van die release, en hij verwijst naar één vaste momentopname. Anthropic werkt de gewichten of configuratie van een bestaande model-ID niet bij; een nieuwere versie verschijnt onder een nieuwe ID. Dat is precies andersom dan bij de aliassen van vóór die generatie, waar claude-sonnet-4-5 wél een gemakspointer naar de laatste gedateerde snapshot is.
Voor wie een pijplijn draait die zichzelf mag mergen, is dat een geruststelling en een verplichting tegelijk. Geruststellend: het gedrag van je poort verschuift niet onder je vandaan. Verplichtend: je pijplijn wordt ook niet beter zonder dat iemand die ID wijzigt, en dat is een commit — iets wat te reviewen en terug te draaien valt. Dat is de goede eigenschap. Een model dat stilletjes vernieuwt, is een wijziging in productie die nergens staat opgeschreven.
De uitzondering op die geruststelling
De uitzondering: de gewichten liggen vast, de infrastructuur niet
Eén nuance die in dezelfde documentatie staat en zelden geciteerd wordt: de gewichten liggen vast per ID, maar de serving-infrastructuur eromheen niet. Router, veiligheidsclassificatoren en sampling-logica kunnen veranderen, en zulke updates kunnen kleine verschillen in waarneembaar gedrag opleveren terwijl de model-ID en de gewichten ongewijzigd zijn.
De documentatie noemt dat expliciet de meest waarschijnlijke oorzaak wanneer je onverwacht ander gedrag ziet op een ID die tot dan toe stabiel was. Dat is nuttige diagnostiek: het eerste dat je bij zo'n waarneming níét moet doen, is je prompts gaan bijstellen.
Wat hieruit volgt
Vanaf hier: mijn interpretatie
Alles hierboven is terug te lezen in de bronnen onderaan. Wat nu volgt staat daar niet in: het zijn de gevolgtrekkingen die ik eruit trek voor een pijplijn waarin agents zelfstandig werken. Neem ze als voorstel, niet als bevinding.
- Kies per taaksoort, niet per project. Een classificatiestap, een samenvatting en een meerstapsimplementatie hebben verschillende horizons en verschillende foutkosten. Eén model voor alles is een keuze die je op de duurste taak maakt en op de goedkoopste betaalt.
- Pin expliciet, en behandel een wissel als een wijziging. De ID hoort in de repo te staan, niet in iemands hoofd. Dat is dezelfde eis als aan elke andere configuratie: reproduceerbaar uit de repo, of het bestaat niet.
- Toets een wissel differentieel, niet op een benchmarkscore. Laat het oude en het nieuwe model dezelfde taken doen en vergelijk het gedrag — om dezelfde reden dat een groene testsuite geen correcte patch bewijst.
- Reken latency mee als kostenpost. In een pijplijn die op een model wacht, is wachttijd geen comfortprobleem maar doorlooptijd. Een tier-woord in een tabel wordt in een fan-out van twintig taken een meetbaar verschil.
Waar het ophoudt
Wat verouderd raakt, en wat blijft staan
De cijfers hierboven zijn een momentopname van 23 augustus 2026 en zullen verouderen; de documentatie is leidend, niet dit stuk. Ze komen bovendien van de leverancier zelf, en dat geldt ook voor de latency-aanduidingen — dat zijn geen onafhankelijk gemeten waarden maar categorieën die Anthropic zelf toekent.
Wat hier niet in staat is een vergelijking met modellen van andere aanbieders. Die zou deze drie aannames nog scherper maken, want tokenizers verschillen dan ook tussen leveranciers — maar ik heb die tabellen niet met dezelfde zorg nagelezen, en een half nagetrokken vergelijking is slechter dan geen.
Toets het op je eigen systeem
Laat je eigen systeem de modelkeuze per taaksoort onderbouwen in plaats van er één voor alles te gebruiken.
Je gaat de modelkeuze van dit project tegen het licht houden. Stap 1 — inventariseer. Zoek in deze repository elke plek waar een model-ID staat: workflows, configuratiebestanden, scripts, SDK-aanroepen. Geef per vindplaats terug: het pad, de ID, en welke taak daar draait. Stap 2 — classificeer die taken. Deel ze in op twee assen, en onderbouw elke indeling met wat je in de code ziet: a) horizon — één beurt, of een lange reeks stappen met tussenresultaten? b) kosten van een fout — stil verkeerd antwoord, of meteen zichtbaar falen? Stap 3 — toets deze drie aannames, die vaak onuitgesproken blijven: - Wordt hier ergens een prijs per token vergeleken tussen modellen uit verschillende generaties? Dat is geen geldige vergelijking als de tokenizer verschilde. - Staat er een model-ID die iemand voor een evergreen alias aanziet? Controleer of het een gepinde momentopname is. - Wordt er ergens op het volledige contextvenster geleund alsof de hele inhoud even bruikbaar blijft? Stap 4 — geef per vindplaats een aanbeveling: houden, of wisselen naar een andere tier, met de reden erbij. Zeg expliciet welke aanbeveling je NIET kunt onderbouwen met wat er in de repo staat, en welke meting je zou moeten draaien om dat wel te kunnen. Geef geen algemeen advies over modelkeuze. Alleen wat volgt uit deze codebase.
Bronnen
- Models overviewAnthropic · Claude Platform docs · 2026
- Model IDs and versioningAnthropic · Claude Platform docs · 2026