# 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.

- Bron: https://www.koenholman.nl/onderzoek/modelkeuze-is-geen-prijsvergelijking/
- Auteur: Koen Holman
- Rubriek: Modellen & evaluatie
- Gepubliceerd: 23 augustus 2026

## In het kort

- Een prijs per token is niet vergelijkbaar tussen tokenizergeneraties: dezelfde tekst kan er substantieel meer opleveren, bij Fable 5 ruwweg 30%.
- Model-ID’s zijn sinds de 4.6-generatie gepinde momentopnamen — ook zonder datum erin. Je pijplijn drijft niet weg, maar verbetert ook niet vanzelf.
- De gewichten liggen vast, de serving-infrastructuur eromheen niet; die kan waarneembaar gedrag veranderen zonder dat de ID wijzigt.
- Reken door naar kosten per geslaagde taak: twee keer de prijs per poging kan dertig procent verschil per resultaat worden.

---

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.

- **10×** — prijsverschil tussen het goedkoopste en het duurste model
- **~30%** — meer tokens voor dezelfde tekst, na de tokenizerwissel
- **1M** — contextvenster — identiek voor de bovenste drie

## De tabel, als momentopname

Zoals [het modeloverzicht van Anthropic](https://platform.claude.com/docs/en/about-claude/models/overview) 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.

**Figuur.** Staafdiagram van de invoerprijs per miljoen tokens voor vier modellen: Haiku 4.5 op 1 dollar, Sonnet 5 op 2 dollar, Opus 5 op 5 dollar en Fable 5 op 10 dollar. Het contextvenster staat erboven: 200k voor Haiku 4.5 en 1M voor de drie andere. De prijs vertienvoudigt terwijl het venster vanaf het tweede model gelijk blijft.

Tien keer de prijs, hetzelfde venster. Wat wél verschilt over deze vier is latency, en dat staat in de documentatie als een woord — niet als een getal dat je kunt afwegen.

## 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](https://www.koenholman.nl/onderzoek/context-als-eindige-hulpbron/), 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](https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions) 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.

## Bronnen

1. [Models overview](https://platform.claude.com/docs/en/about-claude/models/overview) — Anthropic · Claude Platform docs · 2026
2. [Model IDs and versioning](https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions) — Anthropic · Claude Platform docs · 2026

## 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.
```