Ontwerpen voor Model Deprecations met Virtuele Modellen en Stapsgewijze Overstappen

Op 23 juli 2026 staat OpenAI op het punt om 15 vermelde model-entries stop te zetten — een mix van verouderde snapshots en aliassen verspreid over Codex, chat, deep-research, search, audio, realtime en computer-use API's, volgens de deprecations-pagina. De onmiddellijke taak is migratie. Het duurzame engineeringprobleem is eigenaarschap van afhankelijkheden: applicatiecode zou niet direct afhankelijk moeten zijn van identifiers waarvan de levensduur wordt beheerd door een model provider.

Dizze post beschrijft een veiliger operationeel patroon — inventariseer het huidige gebruik, plaats een stabiele virtuele-model-alias tussen applicaties en provider-modellen, evalueer vervangers aan de hand van werklastspecifieke tests, verplaats synchroon verkeer via een gewogen canary en behoud een snel rollback-pad.

‍

1. Lees de Kalender Zoals een SRE Dat Doet

De deprecations-pagina van OpenAI definieert de semantiek rechtstreeks: een model wordt gedeprecieerd op het moment van aankondiging — het werkt nog steeds, maar het heeft nu een stopzettingsdatum — en zodra het is stopgezet, worden requests eraan niet langer verwerkt. Het gepubliceerde aankondigingsbeleid is ten minste zes maanden voor algemeen beschikbare modellen en ten minste drie maanden voor gespecialiseerde varianten zoals Codex en chat-latest-modellen. Preview-modellen kunnen een aankondiging krijgen van slechts twee weken, en OpenAI adviseert expliciet om previews niet te gebruiken voor bedrijfskritische productie-werklasten, tenzij het team snel kan migreren (OpenAI deprecations-pagina).

De aankondiging van 22 april stelde twee geconcentreerde stopzettingsbatches vast: 15 vermelde entries op 23 juli, en op 23 oktober een verdere set van legacy GPT-3.5, GPT-4, GPT-4 Turbo, GPT-4.1 Nano, GPT-4o, en o-serie snapshots en aliassen, samen met gpt-image-1 en diverse fine-tuned base-model families. Let op wat 23 oktober niet is: het is niet de gehele GPT-4-familie, en het is niet de gehele o-serie — de gedateerde o3-2025-04-16 en o3-pro-2025-06-10 snapshots worden afzonderlijk vermeld voor 11 december, en alleen de gpt-4o-2024-05-13 snapshot verschijnt uit de GPT-4o-lijn.

De reeks image-modellen verdient aandacht als precedent. Toen DALL·E 2 en 3 op 12 mei werden stopgezet, had OpenAI gpt-image-2, gpt-image-1 of gpt-image-1-mini vermeld als aanbevolen vervangers. Teams die gpt-image-1-mini hebben geselecteerd, moeten nu opnieuw migreren vóór de stopzetting op 1 december, en gpt-image-1 zelf staat gepland voor 23 oktober. De les laat zich generaliseren: het migratiedoel kan ook op de kalender staan, en een architectuur waarvan de reactie op deprecation bestaat uit het overal bewerken van model-strings en opnieuw deployen, zal dat werk herhalen op het tempo van de leverancier.

Dit is evenmin het patroon van één provider. Anthropic vermeldt Claude Opus 4.1 voor uitfaserung op 5 augustus 2026, met een gedocumenteerd beleid van ten minste 60 dagen van tevoren voor publiekelijk uitgebrachte modellen (Anthropic model deprecations). Google vermeldt 16 oktober 2026 als de vroegste stopzetting voor Gemini 2.5 Pro, Flash en Flash-Lite, en één preview-model — gemini-3.1-flash-lite-preview — liep van 3 maart tot 25 mei 2026, minder dan drie maanden van uitgave tot stopzetting (Gemini deprecations). De eigen API-documentatie van DeepSeek vermeldt dat de legacy-aliassen deepseek-chat en deepseek-reasoner op 24 juli 2026 zullen worden gedeprecieerd, waarbij ze voor compatibiliteit worden gekoppeld aan de non-thinking en thinking modus van deepseek-v4-flash; het merkt die datum niet aan als een stopzetting (DeepSeek modellen en prijzen). Deze vier providers publiceren allemaal actieve wijzigingen in de levenscyclus van modellen; hun aankondigingstermijnen en migratiekoppelingen verschillen.

2. Het Inventarisatieprobleem: Je Kunt Niet Migreren Wat Je Niet Kunt Vinden

Elke migratiehandleiding begint met "audit je gebruik", en elk platformteam weet waarom die stap erbij inschiet: model-ID's verbergen zich in service-configs, notebook-constanten, CI-pipelines, framework-defaults, configuratiebestanden van coding-agents en tools van derden waarvan niemand zich herinnert ze te hebben geaccepteerd. Grep vindt de strings in jouw repositories; het vindt niet het volume, de eigenaar of het verkeer dat buiten versiebeheer ontstaat. De betrouwbare telling is observationeel: als elke model-call één gateway kruist, dan is het gebruik per model — opgesplitst per team, applicatie, gebruiker en virtueel account, met daaraan gekoppelde kosten — een dashboard-query, en "wie roept dit uitfaserende model nog aan" heeft een live antwoord met namen en bedragen erbij. Anthropics eigen richtlijnen wijzen in dezelfde richting en raden klanten aan om voor de migratie gebruiksaudits per sleutel en per model te exporteren. Die telling is ook de prioriteringsfunctie: een model met drie resterende calls per dag vanuit een vergeten batch-job is een ticket; een model dat een klantgerichte functie ondersteunt tegen zes cijfers per maand is een project.

3. Indirectie: Virtuele Modellen Veranderen een Redeploy in een Routing-Update

De structurele oplossing is het oudste idee in systems engineering — voeg een naamslaag toe die je beheert tussen de aanroeper en het ding dat veranderd. In de gateway van TrueFoundry is de eenheid het virtuele model: voor ondersteunde synchrone requests die via de gateway worden gerouteerd (chat en Anthropic Messages, Responses, completions, embeddings, rerank, moderatie, afbeeldingen en audio-operaties), roepen applicaties een stabiele alias aan zoals prod-coding-agent, en operators configureren welke echte modellen erachter zitten, met op gewicht, prioriteit of latency gebaseerde routing plus retries en fallbacks per doel (virtueel model documentatie). Onder die indirectie valt een stopzettingsdatum uiteen in gateway-operaties: de telling uit Sectie 2 identificeert de aliassen waarvan de achterliggende modellen uitfaseren, en elke alias krijgt één keer centraal een compatibele opvolger toegewezen. Het selecteren van een compatibel achterliggend doel vereist geen wijziging van de model-identifier in consumerende services — de eigenschap die het meest van belang is waar de consumerende services in de honderden lopen en hun eigenaren in de tientallen — hoewel applicatiewijzigingen nog steeds nodig kunnen zijn wanneer een vervanging andere prompts, tools, parameters of uitvoerverwerking vereist.

De uniforme, OpenAI-compatibele API van de gateway die meer dan 1.000 modellen omvat, verruimt de zoektocht naar een opvolger: de vergelijkingstest voor een uitfaserend model kan de door de provider voorgestelde koppeling uitvoeren naast Anthropic, Google of zelfgehoste open-weight kandidaten via een gemeenschappelijk request-oppervlak (gateway introductie). Een gemeenschappelijk oppervlak is geen gelijkwaardigheid, en het mag er niet voor worden aangezien: providers verschillen in tool-call-semantiek, ondersteuning voor gestructureerde uitvoer, geaccepteerde parameters, multimodale capaciteiten, contextlimieten, veiligheidsgedrag, tokenisatie en prijzen — wat precies de reden is waarom kandidaten expliciet moeten worden geëvalueerd, volgens Sectie 4, in plaats van dat ze als uitwisselbaar worden beschouwd. Een opmerking over discipline die het precedent van het image-model ons leert: richt aliassen op gepinde snapshots, niet op "latest"-aliassen aan de provider-zijde. De kalender van OpenAI retireert chat-latest-aliassen net als elke andere entry — een naam die je niet beheert is nog steeds een afhankelijkheid die je niet beheert.

4. Migratie Is een Evaluatieprobleem: Diff, Canary, Rollback

Wat indirectie niet oplost is gedrag. Opvolgende modellen zijn geen 1-op-1 vervangers, en een find-and-replace stuurt die verschillen rechtstreeks naar productie. De werkvolgorde voor één alias ziet er als volgt uit:

1. De applicatie roept prod-coding-agent aan, nooit een provider model-ID. Het virtuele model routeert aanvankelijk 100% naar de incumbent.
2. Diff. Voordat er verkeer verschuift, draai je de incumbent en de kandidaat offline tegen je eigen evaluatieset — jouw prompts, jouw tool-schema's, jouw acceptatiecriteria.
3. Canary. Configureer een nominale 95/5 verdeling op dezelfde alias. Voor werk over meerdere turns configureer je sticky routing op basis van een conversatie-, gebruiker- of tenant-identifier, zodat een sessie halverwege een conversatie niet afwisselt tussen incumbent en kandidaat — een belangrijk correctheidsdetail voor agents en chat, geen optionele afwerking. Met sticky routing volgt de initiële sessietoewijzing het gewogen beleid, terwijl opeenvolgende requests gepind blijven, waardoor het waargenomen request-volume kan afwijken van exact 95/5 wanneer sessielengtes variëren.
4. Beoordeel de canary met behulp van twee bewijsstromen. Pas werklastspecifieke kwaliteits-gates toe via je evaluatiesysteem. Vergelijk parallel daaraan de operationele metingen per achterliggend model in het Metrics Dashboard: foutpercentage en -klasse, latency-percentielen (TTFT, ITL, TPOT, P50–P99), request-volume en inferentiekosten (Metrics Dashboard documentatie).
5. Verhoog de kandidaat naar 30%, en vervolgens 100%. Rollback: vóór de stopzettingsdatum van de incumbent herstelt een rollback diens vorige gewicht — een wijziging die alleen de routing betreft en waarvoor de client niet opnieuw hoeft te worden gedeployed, mits het eerdere doel beschikbaar blijft en het request-contract ongewijzigd is. Na de stopzetting is de incumbent ontoegankelijk, dus rollback betekent dan routen naar een ander actief model dat al is gevalideerd voor de werklast.
6. Afronden vóór stopzetting. Stel het gewicht van het uitfaserende doel in op nul en verwijder het uit het virtuele model of stel fallback_candidate: false in, zodat de gateway het ontoegankelijke model nooit probeert te gebruiken op een fallback-pad. Configureer een afzonderlijke actieve, geëvalueerde fallback, en gebruik vervolgens Model Metrics en request-logs om te bevestigen dat geen enkel via de gateway geleid verkeer nog naar het uitfaserende model verwijst — en inspecteer afzonderlijk het gebruik aan de provider-zijde en repositories voor verkeer dat de gateway omzeilt of de provider rechtstreeks aanroept.

Het is de moeite waard om rond die rollback-grens te plannen: de incumbent blijft alleen een geldige rollback-target tot de stopzettingsdatum van de provider, dus de canary moet — met marge — vóór die datum zijn afgerond. Een migratie die kort voor de stopzettingsdatum wordt gestart, laat weinig tijd over om de canary te observeren en alsnog terug te rollen naar de incumbent.

De onderstaande configuratie toont de gedocumenteerde vorm van die canary, met veldnamen afkomstig uit de virtuele-modeldocumentatie van TrueFoundry. Eén compatibiliteitsdetail is hier van belang: gpt-5.1-codex is alleen beschikbaar via de Responses API van OpenAI, en elk doel achter een virtueel model moet de operatie ondersteunen die hoort bij het geconfigureerde modeltype — dus dit virtuele model is gemaakt met het modeltype responses, dat ook door GPT-5.5 wordt geserveerd. Provider-groepsnamen variëren per deployment; vervang deze door de catalogus-identifiers die in jouw gateway zijn geconfigureerd.

Virtueel model routing_config — nominale 95/5 canary met sticky sessions

De kandidaat richt zich bewust op de gedateerde snapshot gpt-5.5-2026-04-23 in plaats van op de gpt-5.5 alias, volgens de hierboven beschreven pinding-discipline. De incumbent illustreert waarom die discipline bestaat: de huidige modelpagina van OpenAI vermeldt gpt-5.1-codex als een Responses-only naam waarvan de onderliggende snapshot regelmatig wordt bijgewerkt, en vermeldt geen afzonderlijk selecteerbare gedateerde snapshot — precies het soort door de provider beheerde naam waaraan deze migratie ontsnapt.

Sticky sessions pinnen requests die dezelfde sessiesleutel delen aan één doel gedurende het geconfigureerde ttl_seconds venster; als het gepinde doel faalt, worden gezonde fallback-kandidaten geprobeerd en blijft de sessie voor de rest van het venster op het werkende doel. Elk request moet de geconfigureerde sessie-identifier bevatten: als x-conversation-id ontbreekt, levert het een lege string op voor de sessiesleutel, waardoor requests zonder de header in dezelfde sessie kunnen samenvallen. Dimensioneer ttl_seconds om de verwachte duur van de conversatie of workflow te dekken; zodra het venster verloopt, wordt de sessie opnieuw geëvalueerd en kan deze aan een ander doel worden toegewezen. Tijdens de canary zijn promotie en rollback vóór stopzetting gewichtswijzigingen. Verwijder of schakel het uitfaserende doel uit vóór de stopzetting van de incumbent en behoud ten minste één actieve, geëvalueerde fallback.

Twee gedocumenteerde observatiemechanismen sluiten de audit-cirkel. Per request retourneert de gateway het werkelijke achterliggende model dat de call heeft afgehandeld in de x-tfy-resolved-model response-header, en — wanneer request-logging is ingeschakeld (configureerbaar als HEADER_CONTROLLED, ALWAYS, of NEVER) — kunnen gelogde requests worden geïnspecteerd in de Requests-weergave, onderworpen aan de geconfigureerde gegevenstoegangsregels (request-logging documentatie). In het algemeen bieden de Metrics- en Routing-dashboards groeperingen op model en virtueel model voor volume, foutpercentages per foutklasse, kosten, latency-percentielen en verdelingen per routingregel-doel. Dus wanneer iemand in november vraagt of de omzetting van 23 oktober samenviel met een door een klant gemelde kwaliteitsdaling, kunnen de dashboards vaststellen of de omzetting samenviel met veranderingen in latency, fouten, verkeer of kosten; het vaststellen van een achteruitgang in taakkwaliteit vereist nog steeds evaluatieresultaten of trace-analyses op request-niveau.

Een opmerking over evaluatie-tooling: OpenAI heeft zijn Evals-platform op 3 juni gedeprecieerd — bestaande evals worden op 31 oktober read-only, en de planning is dat het dashboard en de API op 30 november worden stopgezet. Die uitfaserung versterkt de waarde van het draagbaar houden van evaluatiedatasets, scoring-logica en promotiecriteria over providers heen, in plaats van ze te koppelen aan de tooling van één leverancier. Online evaluatie bij de gateway — waarbij een bemonsterde subset van live responsen in de loop van de tijd asynchroon wordt gescoord — is hiervoor één implementatiepatroon; we beschrijven de architectuur in een afzonderlijke post.

5. Grenzen, Helder Geformuleerd

Datumgegevens en modellijsten hierboven zijn afkomstig van de eigen deprecations-pagina's van de providers vanaf half juli 2026. Deprecations-schema's veranderen, af en toe in het voordeel van de klant, en lezers die een migratie uitvoeren, moeten de primaire pagina's als gezaghebbend beschouwen boven elke secundaire samenvatting, inclusief deze. Indirectie verplaatst het werk van deprecation naar een control plane; het wist het oordeel niet uit — het kiezen van opvolgers, het definiëren van evaluatiecriteria en het beslissen welke kwaliteitsachteruitgang acceptabel is, blijven de beslissingen van jouw team, en een virtueel model dat naar een slechte opvolger wijst, faalt overal tegelijk, wat de reden is waarom de canary- en evaluatiestadia hier zo zwaar wegen. Het argument is specifieker dan "vermijd de molen", wat geen enkele architectuur kan: wanneer de levensduur van een afhankelijkheid wordt bepaald door de roadmap van iemand anders, moet de kant van de interface van de aanroeper een naam zijn die je zelf bezit. TrueFoundry's gedocumenteerde virtuele-modelrouting, sticky sessions, retries en fallbacks, en observatiemogelijkheden op modelniveau implementeren dit operationele patroon voor ondersteunde via de gateway geleide werklasten.

Referenties

• OpenAI — API deprecations-pagina (primaire bron: de stopzettingslijsten van 23 juli, 26 augustus, 23 oktober, 1 december en 11 december; de tijdlijnen voor Evals, Agent Builder en herbruikbare prompts; DALL·E vervangingskoppelingen; gedeprecieerd-versus-stopgezet semantiek; aankondigingsbeleid); GPT-5.1-Codex modelpagina (alleen beschikbaar via Responses API; regelmatig bijgewerkte onderliggende snapshot); GPT-5.5 modelpagina (endpoints; de gpt-5.5-2026-04-23 gedateerde snapshot).
• Anthropic — model deprecations (Claude Opus 4.1 uitfaserung, 5 augustus 2026; 60-dagen aankondigingsbeleid; richtlijnen voor gebruiksaudits).
• Google — Gemini deprecations (Gemini 2.5 Pro/Flash/Flash-Lite vroegste stopzetting, 16 oktober 2026; gemini-3.1-flash-lite-preview levenscyclus).
• DeepSeek — modellen en prijzen (deprecation van de deepseek-chat en deepseek-reasoner aliassen op 24 juli 2026, en hun koppeling aan deepseek-v4-flash modussen).
• TrueFoundry documentatie — virtuele modellen (routing-strategieën, sticky routing, retries en fallbacks, uitsluiting van Batch API, x-tfy-resolved-model); AI Gateway introductie (geünificeerde API); request-logging (logging-modi, Requests-weergave); Metrics Dashboard (model- en virtuele-modelmetrieken, latency-percentielen, kosten, routing-verdelingen).
• Dizze blog — online evaluatie bij de gateway (architectuurpatroon); zelf hosten van open-weight modellen achter de gateway; real-time kostentoewijzing.

Alle schemadetails zijn geparafraseerd van de openbare deprecations-pagina's van de providers, actueel vanaf de datum van publicatie; lezers moeten deze verifiëren op de primaire pagina's alvorens te handelen. De migratiemethodologie in Secties 2–4 citeert de openbare documentatie van TrueFoundry; het configuratie-voorbeeld reproduceert het gedocumenteerde routing-schema; de dashboard-afbeelding is een eigen documentatie-asset van TrueFoundry, overgenomen met bronvermelding. Geen van de geciteerde providers evalueert of ondersteunt TrueFoundry.

‍

‍