Modelupdates en deprecaties bijhouden zonder verrassingen

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · Laatst bijgewerkt: 6 augustus 2026

Je model kan verdwijnen — en dat is geen nieuws

In de softwareontwikkeling geldt al decennia een ongeschreven regel: zolang een REST API-endpoint dezelfde JSON-structuur accepteert en teruggeeft, blijft de integratie werken. Bij Large Language Models (LLM's) klopt die aanname slechts ten dele. Aanbieders garanderen weliswaar de technische achterwaartse compatibiliteit van hun REST-laag en client libraries, maar het onderliggende gedrag van het model kan per update veranderen.

OpenAI formuleert dit verschil expliciet in hun officiële API-documentatie:

"Model prompting behavior between snapshots is subject to change… The best way to ensure consistent prompting behavior and model output is to use pinned model versions, and to run evals for your applications." (OpenAI API Overview)

API-aanbieders kondigen het uitfaseren van modellen (deprecatie) en de definitieve buitengebruikstelling (retirement of shutdown) maanden van tevoren aan. OpenAI publiceert de exacte opzegtermijnen op hun deprecations-pagina, Anthropic hanteert vaste termijnen voor actieve accounts, en Google geeft garanties voor General Availability (GA)-modellen. Wanneer een applicatie in productie vastloopt doordat een model-endpoint niet meer bestaat of ander gedrag vertoont, is dat vrijwel nooit een gevolg van een gebrek aan informatie vanuit de provider. Het is een gevolg van een gebrek aan operationele routine.

De reflex om in productiecode een algemene alias zoals latest te gebruiken of te vertrouwen op ongewijzigde modelnamen brengt grote risico's met zich mee. Wie een alias gebruikt, beweegt ongemerkt mee met elke snapshot-update die een aanbieder doorvoert. Wie een preview-model in een kritieke productieomgeving inzet, werkt met opzegtermijnen die kunnen variëren van enkele weken tot zelfs enkele dagen. Het beheren van LLM-integraties vereist dat een model-API wordt behandeld als een vastgezette afhankelijkheid (pinned dependency) met een eigen levenscyclus. Voor een overzicht van de verschillende lifecycles kun je het artikel over modelversies en deprecatie op llmnet hub raadplegen. Het structureel inrichten van dit proces vraagt gemiddeld dertig minuten per maand en voorkomt dat ontwikkelaars ad-hoc migraties moeten uitvoeren onder tijdsdruk.

Waar vendors deprecaties aankondigen: één centrale pagina per aanbieder

De belangrijkste stap in het voorkomen van verrassingen is het kennen van de officiële informatiekanalen. Elke grote AI-aanbieder onderhoudt specifieke documentatiepagina's waarin modelupdates, opzegtermijnen en geplande shutdowns worden bijgehouden.

OpenAI bundelt alle wijzigingen op twee centrale locaties:

Anthropic hanteert een heldere indeling in vier fases voor hun modellen: Active, Legacy, Deprecated en Retired. De status van elk model is inzichtelijk via de volgende bronnen:

Het is hierbij van belang op te merken dat de datums van Anthropic betrekking hebben op de Claude API, AWS en Foundry. Wolkenplatforms zoals Amazon Bedrock en Google Cloud hanteren voor hun gehoste instanties eigen uitfaseringsschema's.

Google publiceert informatie over Gemini en Vertex AI verspreid over meerdere documentatiebronnen:

Ook kleinere aanbieders van modelinfrastructuur publiceren formaliteiten rondom levenscycli. Together AI geeft bijvoorbeeld op hun Together AI Deprecations-pagina inzicht in hun beleid rondom automatische omleidingen en opzegtermijnen voor gehoste open-source modellen.

Hoeveel tijd krijg je? De opzegtermijnen per aanbieder

De periode tussen de aankondiging van een deprecatie en de definitieve shutdown van een endpoint varieert per aanbieder en per type model. Modellen die de status General Availability (GA) dragen, bieden de langste garanties. Preview-versies en experimentele varianten kennen daarentegen kortere termijnen.

OpenAI hanteert de volgende officiële beleidsregels op de OpenAI Deprecations-pagina:

Anthropic garandeert op de Anthropic Model Deprecations-pagina dat klanten met actieve API-deployments minimaal 60 dagen van tevoren op de hoogte worden gesteld voordat een model definitief wordt retired. Daarnaast heeft Anthropic formeel vastgelegd dat het bedrijf zich inzet voor het langdurig bewaren van model-weights voor wetenschappelijk onderzoek, zoals beschreven in hun Deprecation Commitments.

Google biedt voor het Gemini Enterprise Agent Platform en Vertex AI strak omlijnde garanties via het Vertex AI Model Versions-beleid:

Bij infrastructuurproviders zoals Together AI gelden volgens de Together AI Deprecations-documentatie kortere termijnen: 'upgrade'-modellen worden na 3 dagen automatisch omgeleid naar een nieuwere versie, nieuwe modellen bieden een overlap van 2 weken, en preview-modellen kunnen na 30 dagen beschikbaarheid met minder dan 24 uur notificatie worden uitgeschakeld.

Geen theorie: wat er de afgelopen jaren echt verdween

Dat modeldeprecatie een continu proces is, blijkt uit de lijst van modellen en endpoints die in de periode 2024–2026 definitief zijn stopgezet of voor de komende periode op de planning staan om te worden uitgefaseerd.

Bij OpenAI laten de officiële gegevens op de deprecations-pagina de volgende verifieerbare stappen zien:

Anthropic heeft volgens de Anthropic Model Deprecations-pagina eveneens meerdere generaties gepensioneerd:

Google voerde via de Gemini API Deprecations en het Vertex AI Lifecycle-overzicht de volgende shutdowns door:

Pin je versies — de enige echte verdediging

Om te voorkomen dat een applicatie onverwacht ander gedrag vertoont, is het vastzetten van modelversies (version pinning) de primaire verdedigingslinie. Er is een essentieel verschil tussen een specifiek model-ID (een pinned snapshot) en een alias zoals latest.

Anthropic licht in de documentatie over Model IDs and Versioning toe dat elk model-ID naar een vaste snapshot verwijst. De onderliggende weights van zo'n specifiek ID veranderen gedurende de gehele levensduur van dat ID niet. Sinds de 4.6-generatie zijn dateless ID's (zoals claude-sonnet-4-6) bovendien de canonieke pinned snapshots en geen aliassen. Elk model-ID heeft zijn eigen unieke deprecatietermijn en retirement-datum.

OpenAI onderstreept dit principe in de API Overview: wie consistente resultaten wil garanderen, dient expliciet gedateerde snapshots te gebruiken in plaats van algemene aliassen. Wie gebruikmaakt van een alias zoals gpt-4o of latest, laat de provider bepalen wanneer de onderliggende snapshot wijzigt. Zo'n achtergrond-upgrade kan de outputstructuur, de lengte van antwoorden of het opvolgen van systeem-prompts beïnvloeden zonder dat er in de applicatiecode een regel is gewijzigd.

Het gebruik van aliassen is uitsluitend verstandig in staging-omgevingen of bij niet-kritieke taken. In productieomgevingen behoort elke LLM-call te verwijzen naar een specifiek, vastgezet model-ID. Praktische richtlijnen voor de implementatie in softwareontwikkeling zijn te vinden in de gids over versiebeheer voor prompts in code op llmnet api.

Een upgrade-routine die wél werkt

Het beheren van modelovergangen vereist een gestructureerd proces. Dit proces begint niet bij het aanpassen van de code, maar bij het in kaart brengen van het daadwerkelijke gebruik binnen de organisatie.

Een audit vormt het startpunt. Anthropic biedt hiervoor in het dashboard de mogelijkheid om gebruiksgegevens te exporteren via Console → Usage → Export CSV per API-sleutel en model (Anthropic Model Deprecations). Hiermee wordt inzichtelijk welke microservices of teams nog gebruikmaken van oudere snapshots.

Voor de geleidelijke overgang tussen modelversies hanteren veel softwareteams een vast patroon. Let op: dit specifieke verloop (productie vastgezet, staging op een alias, nachtelijke evaluaties en een upgrade pas na N achtereenvolgende groene dagen) is een bekend community-patroon (zoals beschreven op onder meer de EzAI-blog) en vormt geen officieel vendor-advies van de modelaanbieders zelf.

Een betrouwbare upgrade-routine omvat de volgende stappen:

  1. Stel een eval-baseline vast: Voordat een migratie naar een nieuw model-ID plaatsvindt, moet de prestatie van het huidige model gemeten worden met een vaste evaluatieset. OpenAI documenteert hiervoor best practices in de OpenAI Evals Guide en verwijst op de deprecations-pagina naar de Promptfoo Cookbook voor het uitvoeren van vergelijkende testen. Raadpleeg voor verdere verdieping de gids over regressietesten voor prompts op llmnet benchmark.
  2. Gebruik officiële migratiehulpmiddelen: Leveranciers bieden specifieke handleidingen voor wijzigingen tussen modelgeneraties. Anthropic biedt een Migration Guide inclusief een geautomatiseerde /claude-api migrate skill binnen Claude Code, die codebases doorzoekt op verouderde model-ID's en parameters.
  3. Voer cross-vendor evaluaties uit: Wanneer een migratie ook een wisseling van provider inhoudt, kunnen evaluatiediensten uitkomst bieden. De Google Vertex AI Evaluation Service ondersteunt sinds 2026-03-12 ook partner-modellen zoals Claude en Llama, waardoor vergelijkende testen binnen één testomgeving kunnen worden uitgevoerd (Vertex AI Release Notes).

Laat de changelogs naar je toekomen

Het handmatig controleren van tientallen documentatiepagina's is tijdsintensief. Het is effectiever om meldingen over modelupdates geautomatiseerd te verzamelen.

Er zijn verschillende officiële en geautomatiseerde kanalen beschikbaar:

Naast de officiële vendorkanalen bestaan er secundaire bronnen en community-trackers die wijzigingen verzamelen (naar verwachting handig voor snelle overzichten, maar met een medium-betrouwbaarheid ten opzichte van de officiële documentatie):

Een belangrijk inzicht voor ontwikkelaars en systeembeheerders is dat er geen universele, overkoepelende push-notificatiedienst bestaat die alle modeldeprecaties van alle aanbieders verzamelt. De enige gegarandeerde notificatiekanalen zijn rechtstreekse e-mails die aanbieders sturen naar beheerders van actieve API-accounts, gecombineerd met de officiële deprecations-pagina's. Het bouwen van een eigen interne alert (zoals een geautomatiseerde RSS-parser of BigQuery-job) is de meest betrouwbare manier om tijdig geïnformeerd te worden.

Conclusie: maak er een routine van, geen project

Het beheer van LLM-modellen in een productie-omgeving vereist een verschuiving in werkwijze. Een model-API is geen statische voorziening, maar een dynamische component met een voorspelbare levenscyclus. Door het toepassen van een vaste vier-staps-routine worden verrassingen voorkomen:

  1. Pin: Zet modelversies expliciet vast op specifieke snapshot-ID's en vermijd het gebruik van latest-aliassen of preview-modellen in productie.
  2. Monitor: Richt geautomatiseerde alerts in via RSS, BigQuery of account-e-mails om aankondigingen van deprecaties direct op te vangen.
  3. Eval: Bouw een vaste evaluatie-baseline op om de outputkwaliteit van een nieuw model vooraf kwantitatief te vergelijken met de huidige snapshot.
  4. Migreer: Voer de migratie gecontroleerd uit binnen de door de leverancier geboden opzegtermijn en maak gebruik van beschikbare migratiegidsen.

Met een maandelijkse controle van dertig minuten op de officiële deprecation-pagina's blijft de controle over de modelinfrastructuur behouden. Begin vandaag door de actieve API-keys in de organisatie te auditeren, het belangrijkste model vast te zetten op een specifiek snapshot-ID, en de gids voor het kiezen van het juiste AI-model op llmnet hub te raadplegen voor het selecteren van geschikte opvolgers.