Modelversies en deprecation

Wat zijn modelversies en deprecation?

Je toepassing roept een AI-model aan met een model-ID: een tekstje als claude-sonnet-5 of gemini-3.8-flash. Achter dat tekstje zit één welbepaalde set getrainde gewichten. Modelversies zijn hoe de leverancier die versies uit elkaar houdt en hoe jij er één kiest. Deprecation is de aankondiging dat een versie stopt, gevolgd door de dag waarop ze effectief uitgaat.

Allebei komen ze bij jou terecht, want je prompts, je parsers en je evals zijn afgesteld op één versie. Er kunnen twee dingen mislopen. Het model verandert onder een naam die hetzelfde blijft, dus het gedrag schuift zonder dat iemand bij jou iets aanraakt. Of het model verdwijnt: Anthropic schrijft dat aanvragen naar een gestopt model falen, en OpenAI geeft elk model dat het uitfaseert een stopdatum mee. Denk aan een leverancier die hetzelfde artikelnummer op het etiket houdt maar het recept aanpast, en die artikelen ook uit het gamma haalt met twee maanden verwittiging.

Hoe de leveranciers hun versies benoemen

Drie leveranciers, drie systemen, en hetzelfde woord betekent bij elk iets anders. Dit stond er in september 2026 op hun pagina's.

Anthropic. Voor de Claude 4.6-generatie zat er een datum in het ID, bijvoorbeeld claude-sonnet-4-5-20250929, met een kortere alias claude-sonnet-4-5 die naar de recentste gedateerde snapshot wijst. Vanaf 4.6 is het ID datumloos en is het zelf de vaste snapshot: claude-sonnet-4-6 verandert nooit van gewichten, en een bijgewerkt model verschijnt onder een nieuw ID. De documentatie noemt het een veelgemaakte denkfout dat zo'n datumloos ID naar de nieuwste versie zou doorschakelen. Bedrock en Google Cloud gebruiken voor dezelfde modellen hun eigen ID-formaat en hun eigen stopdatums.

OpenAI. Gedateerde snapshots als gpt-4o-2024-05-13 staan naast gewone aliassen; de alias gpt-5.6 stuurt door naar gpt-5.6-sol. OpenAI verkocht ook modellen die openlijk een bewegend doel waren, zoals chatgpt-4o-latest, en die worden net als elk ander ID uitgefaseerd: aangekondigd op 18 november 2025, gestopt op 17 februari 2026.

Google. Gemini werkt met vier labels. Een stabiel ID zoals gemini-3.8-flash wijst naar één model dat normaal niet verandert. Een preview-ID mag in productie, maar kan met twee weken verwittiging uitgefaseerd worden. Een latest-alias zoals gemini-flash-latest wordt bij elke nieuwe release van die lijn omgewisseld, en experimentele ID's horen helemaal niet in productie. Google zelf schrijft dat de meeste productietoepassingen een specifiek stabiel model horen te gebruiken.

De opzegtermijnen in september 2026

Lees de termijnen hieronder als minima, en kijk ze opnieuw na op de dag dat je plant, want ze schuiven.

• Anthropic verwittigt minstens 60 dagen voor het een publiek uitgebracht model stopzet, per mail en op zijn deprecations-pagina, en dateert elk actief model als "niet vroeger dan" een bepaalde dag. In de praktijk zit die termijn dicht bij het minimum: Claude Sonnet 4 en Opus 4 werden aangekondigd op 14 april 2026 en stopten op 15 juni 2026.

• OpenAI beschouwt een model als uitgefaseerd zodra het aangekondigd is, en belooft minstens zes maanden voor algemeen beschikbare modellen, drie voor gespecialiseerde varianten zoals Codex, en soms twee weken voor previews. De aankondiging van 22 april 2026 zet gpt-4-turbo, gpt-3.5-turbo-0125 en andere oude snapshots stop op 23 oktober 2026; de GPT-5-snapshots uit 2025 stoppen op 11 december 2026.

• Google publiceert de stopdatums van Gemini als de vroegst mogelijke dag en belooft verwittiging voor de exacte datum vastligt. Previews krijgen minstens twee weken, en een breaking wissel achter een latest-alias krijgt twee weken verwittiging per mail. gemini-2.0-flash stopte op 1 juni 2026.

Wat dat doet met een integratie die er niet op voorbereid is, met datums erbij. Op 13 augustus 2025 liet Anthropic weten dat beide Claude Sonnet 3.5-snapshots, claude-3-5-sonnet-20240620 en claude-3-5-sonnet-20241022, op 28 oktober 2025 zouden stoppen. Vanaf die ochtend faalde elke aanvraag naar die ID's. Een team dat dat tekstje hard in een Power Automate-flow had staan, en waar niemand de mails van de leverancier las, zag geen trage terugval in kwaliteit. Het kreeg een foutmelding op een flow die al een jaar ongewijzigd draaide. Bij previews gaat het nog sneller: gpt-4.5-preview werd aangekondigd op 14 april 2025 en was weg op 14 juli 2025.

Wat verandert er tussen twee versies, ook als de naam hetzelfde lijkt?

Overstappen is nooit alleen een tekstje aanpassen. De migratiegids van Anthropic voor Claude Sonnet 5, een model dat ze zelf een drop-in upgrade van Sonnet 4.6 noemen, somt dit allemaal op.

De tokenizer. Sonnet 5 gebruikt een nieuwe, die voor dezelfde tekst ongeveer 30 procent meer tokens maakt. De prijs per token ging omlaag, van 3 en 15 dollar naar 2 en 10 per miljoen, maar de kost van een gelijkaardige aanvraag zakt niet in dezelfde verhouding, en een max_tokens-limiet die op het oude model afgesteld stond, kapt het antwoord nu af. Tokenberekeningen die je op de vorige versie maakte, kloppen niet meer op deze.

Het API-contract. Op Claude 4.7 en later geeft een temperature, top_p of top_k met een andere dan de standaardwaarde een 400-fout in plaats van genegeerd te worden. Denken staat op Sonnet 5 standaard aan, dus een antwoord kan met een thinking-blok beginnen, en code die content[0].text uitleest, werkt niet meer.

De output en de weigeringen. Diezelfde gids waarschuwt dat de JSON-escaping in tool-parameters kan verschillen van vorige modellen. Een echte JSON-parser overleeft dat, een zelfgeschreven parser op tekstpatronen niet. Sonnet 5 kreeg er ook veiligheidscontroles rond cybersecurity bij die Sonnet 4.6 niet had, en een weigering komt terug als een HTTP 200 met stop_reason: "refusal". Een pijplijn die enkel de statuscode nakijkt, boekt dat als een geslaagde aanvraag en bewaart een leeg antwoord.

Pinnen haalt de grote sprongen eruit, niet elke beweging. Anthropic zegt dat de gewichten achter een ID vastliggen, maar dat de infrastructuur eromheen, de router, de veiligheidsclassifiers en de sampling-logica, wel bijgewerkt kan worden en soms een klein verschil in gedrag geeft op een stabiel ID. Een pin geeft je dus een basislijn om tegen te testen, geen belofte dat elk antwoord identiek blijft.

Een prompt die op de ene versie afgesteld was, doet het dus stilletjes minder goed op de volgende. Een parser die op één outputvorm gebouwd is, breekt op een andere. En als niemand na de overstap de eval opnieuw draait, komt geen van beide boven tot een klant er drie weken later over belt.

Alias tegenover gepinde versie: wie beslist wanneer jouw gedrag verandert

De vraag is niet oud model tegenover nieuw model, de vraag is wie aan de schakelaar staat.

Bij een alias staat de leverancier eraan. gemini-flash-latest wees op 21 januari 2026 naar gemini-3-flash-preview, op 19 mei 2026 naar gemini-3.5-flash en op 2 september 2026 naar gemini-3.8-flash: drie modellen achter één tekstje op ruim zeven maanden tijd, elke wissel aangekondigd met een mail die bij de juiste persoon moet aankomen. Je krijgt het nieuwste model zonder te deployen, en je krijgt er zijn tokenizer, zijn schrijfgewoontes en zijn weigeringspatronen bij, op de kalender van de leverancier in plaats van die van jou.

Bij een gepinde versie sta jij eraan. Er beweegt niets tot jij de configuratie aanpast, dus je kan eerst je eval draaien en terugvallen als de cijfers zakken. De prijs is de deadline: een gepind model is een model dat ooit stopt, en die kalender is nu van jou.

Een alias is prima voor een prototype of een intern hulpje waar een licht ander antwoord niets kost. Alles met een parser erachter, een budget eraan vast of een afspraak met een klant hoort op een gepinde versie. Een alias met een eval die elke nacht loopt is een verdedigbare tussenweg, zolang je eerlijk blijft over wat het is: de leverancier beslist nog altijd, jij hoort het alleen sneller.

Hoe je dit in de praktijk organiseert

1. Model-ID's in configuratie, één regel per taak. Classificatie, gegevens uit documenten halen en de agent die klanten te woord staat verhuizen op verschillende momenten, dus ze krijgen aparte regels. Een LLM-gateway is de logische plek voor die tabel, en voor een klein systeem volstaat een configuratiebestand per omgeving. Niemand zou de code moeten doorzoeken om te weten welk model welke aanvraag beantwoordt.

2. Een eval-set per taak, voor elke wissel. Vijftig tot een paar honderd echte inputs met een gekend juist antwoord, elke keer op dezelfde manier gescoord. Draai oud en nieuw erop en vergelijk nauwkeurigheid, outputvorm, tokenaantal, snelheid en kost. Anthropic vraagt net hetzelfde: test het vervangmodel ruim voor de stopdatum, en de checklist voor Sonnet 5 eindigt met je kost opnieuw uitrekenen op je eigen werklast.

3. Een changelog-regel per wissel. Datum, oud ID, nieuw ID, de evalcijfers voor en na, welke prompts je aanpaste en waarom, en wie het goedkeurde. Als iemand binnen zes maanden vraagt waarom de kwaliteit in maart terugviel, staat het antwoord daar.

4. Een deprecation-kalender met een naam erbij. Eén regel per gepind ID: de vroegste stopdatum, het model dat de leverancier aanraadt, de dag waarop jij wil overstappen, en de persoon die de mails van de leverancier leest. Bij Anthropic kan je in de console je verbruik per API-sleutel en per model exporteren, de snelste manier om een vergeten integratie op een oud ID te vinden.

5. Een week dubbel draaien op echt verkeer. Stuur live aanvragen naar beide versies, geef het oude antwoord terug, log het nieuwe en vergelijk. Een eval dekt de inputs waar je aan gedacht hebt, een week productie dekt die andere.

6. Een terugvalpad met een houdbaarheidsdatum. Houd het oude ID beschikbaar tot het nieuwe een week proper gedraaid heeft, en onthoud dat het maar bestaat tot het oude model stopt. Nog een reden om vroeg over te stappen in plaats van in de laatste week van de termijn.

Voor modellen die je zelf traint doet een model registry hetzelfde werk als het ID-systeem van de leverancier bij een gehost model: genummerde versies, een verplaatsbare alias zoals champion, en een lijn terug naar de trainingsrun. De eval voor promotie, de changelog en het terugvalpad zijn gewoon MLOps. Bij gehoste modellen zit de versie achter een API verstopt, met een stopdatum die jij niet bepaalt.

De korte versie voor een zaakvoerder

Je huurt een model, je koopt het niet. De verhuurder mag verbouwen en mag de huur opzeggen, met 60 dagen bij Anthropic en zowat zes maanden bij OpenAI voor hun gewone modellen. Iemand in je bedrijf moet kunnen zeggen welke modelversies je tools aanroepen en waar dat genoteerd staat. Voor er een versie verandert, draai je dezelfde testset op oud en nieuw en kijk je naar de cijfers. Zet elke stopdatum in een kalender met een naam ernaast, en laat "latest" nooit het antwoord zijn voor een tool waar je klanten mee in aanraking komen.