Die AgentinNICOLENDERS.COM
DEEN
← Depeschen

NachschlagewerkDIE AGENTENFÜHRERINDIE TECHNIKERIN

Dein Modell hat ein Verfallsdatum, dein Agent nicht

Veröffentlicht

Eine Reihe gleicher Keramiksicherungen in einem grauen Schaltkasten, eine davon ist durchgebrannt, in der offenen Schublade darunter liegt die eingepackte Ersatzsicherung.KI-generiert
Foundry Models lifecycle and support policyMicrosoft Learn

Am 1. September 2026 hat GitHub eine Reihe Modelle über alle Copilot-Oberflächen hinweg abgeschaltet, von Chat über inline edits bis zur Code Completion. Wer danach in der Modellauswahl nachgesehen hat, fand entweder ein Ersatzmodell oder nichts, je nachdem, ob ein Administrator die Modellrichtlinie vorher angefasst hatte. Genau das ist der Punkt: Ein Modell ist eine Dependency mit Ablaufdatum, und die meisten Teams behandeln es wie eine Einstellung. Diese Depesche sammelt, wer die Fristen setzt, wie lang sie sind und was am Stichtag passiert. Ich halte sie aktuell.

Drei Plattformen, drei Uhren

Plattform

Wer setzt das Datum

Vorlauf

Was am Stichtag passiert

Foundry, Modelle von Azure

programmatisch bei Launch

mindestens 60 Tage Ankündigung bei GA, mindestens 30 Tage vor Versions-Upgrades in preview

je nach Upgrade-Policy automatischer Wechsel oder Fehler

Foundry, Partner-Modelle über den Marketplace

der Anbieter

mindestens 90 Tage im Zustand deprecated, bei Fireworks laut Retirement-Schedule 15 Tage

Deployment antwortet nicht mehr

GitHub Copilot

GitHub, per Changelog

unterschiedlich, im Fall vom 1. September rund vier Wochen

Modell verschwindet aus der Auswahl, Ersatz nur, wenn die Policy es erlaubt

Die dritte Zeile ist die, die im Alltag am meisten Ärger macht, weil dort keine Deployment-Einstellung existiert, an der du drehen könntest. Es gibt nur die Modellrichtlinie im Enterprise, und die pflegt jemand anderes als der, dem das Modell fehlt.

Der Unterschied zwischen deprecated und retired

Bei Foundry sind das zwei Zustände mit unterschiedlicher Wirkung. Deprecated heißt, dass keine neuen Deployments mehr entstehen können, während bestehende weiterlaufen. Erst retired heißt, dass Aufrufe mit Fehlern beantwortet werden. Zwischen beiden liegen bei Foundry Models mindestens 90 Tage.

Das ist deine eigentliche Migrationsfrist, nicht das Retirement-Datum. Wer wartet, bis der Fehler kommt, hat 90 Tage verschenkt.

Die Upgrade-Policy ist die wichtigste Zeile deines Deployments

Pro Deployment wählst du eines von drei Verhalten, und die Wahl entscheidet, ob ein Retirement für dich ein Ereignis ist oder nicht.

Wer automatische Versions-Upgrades abwählt, muss manuell wechseln, und das Deployment hört mit dem Retirement auf zu funktionieren. Wer auf die neue Standardversion aktualisiert, bekommt den Wechsel, sobald eine neue Default-Version da ist. Wer auf Ablauf der aktuellen Version stellt, wechselt genau dann, wenn die eigene Version stirbt.

Was dabei passieren kann, zeigt ein Beispiel aus der Dokumentation: Als gpt-4o in den Versionen 2024-05-13 und 2024-08-06 am 31. März 2026 retired wurde, wurden die betroffenen Deployments auf gpt-5.1 auf der Standard-SKU hochgezogen. Vorher gab es gpt-5.1 auf dieser SKU überhaupt nicht, die Präsenz wurde für den Upgrade in allen acht betroffenen Regionen erst angelegt.

Lies das noch einmal mit deinen Evaluierungen im Kopf. Ein automatischer Upgrade kann dich in eine andere Modellfamilie tragen, nicht nur in eine neue Versionsnummer.

Wo die Quellen auseinandergehen

Zur Lebensdauer eines GA-Modells sagt Microsoft Learn zwei verschiedene Dinge.

Die Seite zu den Azure-OpenAI-Retirements nennt für GA-Modelle 365 Tage ab Launch als programmatisch gesetztes "nicht früher als"-Datum. Die neuere Seite zur Lifecycle- und Support-Policy für Foundry Models schreibt, GA-Modelle bekämen ihr Retirement-Datum bei Launch programmatisch auf 18 Monate gesetzt, ohne separate Ankündigung.

Ich kann das nicht auflösen. Plausibel ist, dass sich die Politik zwischen der klassischen Azure-OpenAI-Sicht und der neuen Foundry-Sicht geändert hat und beide Seiten nebeneinander stehen. Für die Planung heißt das: Nimm nicht die Policy als Grundlage, sondern das konkrete Datum. Es steht pro Modell im Retirement-Schedule und lässt sich über die Models API mit lifecycleStatus und deprecationDate pro SKU abfragen.

Die Benachrichtigung erreicht die falschen Leute

Bei Foundry gehen die Meldungen an die Rollen owner, contributor, reader, monitoring contributor und monitoring reader der Subscription, in der das Deployment liegt. Bei GitHub steht die Abkündigung im Changelog, und Enterprise-Administratoren müssen den Zugang zum Ersatzmodell gegebenenfalls erst über die Modellrichtlinien freischalten.

In beiden Fällen bekommt das Team, das die Anwendung betreibt, die Nachricht nicht automatisch. Das ist der organisatorische Kern dieser Depesche: Die Frist ist dokumentiert, der Empfänger nicht.

Was GitHub anders macht

Zwei Konstrukte, die es bei Foundry so nicht gibt.

Das base model ist das Standardmodell, wenn kein anderes aktiviert ist. Wird ein neues designiert, haben Kunden 60 Tage, um ihre IDE-Erweiterungen auf eine passende Version zu heben, danach wird es automatisch für alle Organisationen und Enterprises aktiviert. Seit dem 18. März 2026 ist das GPT-5.3-Codex, und beides gilt nur für Copilot Business und Copilot Enterprise.

Das LTS-Modell ist die Antwort auf genau das Problem dieser Depesche: ein Modell, das für einen längeren Zeitraum garantiert verfügbar bleibt, damit Sicherheits- und Freigabeprozesse überhaupt hinterherkommen. Auch hier gehen die Quellen leicht auseinander. Die Dokumentation spricht von einem Jahr ab dem Designationsdatum, der Changelog von zwölf Monaten ab dem Launch-Datum des Modells und nennt für GPT-5.3-Codex das Ende des LTS-Fensters am 4. Februar 2027. Zwischen beiden Lesarten liegen rund sechs Wochen. Für eine Freigabeplanung ist das der Unterschied zwischen knapp und zu spät.

Meine Empfehlung

Behandle die Modellversion wie eine Bibliotheksversion, nicht wie eine Einstellung. Das heißt drei Dinge.

Erstens gehört das Retirement-Datum in dein Inventar, pro Deployment, mit Upgrade-Policy daneben. Wenn du die Models API ohnehin nutzt, ist das ein Job, der einmal pro Woche läuft und in ein Ticket schreibt.

Zweitens braucht jede Anwendung eine Abstraktion über dem Modellnamen. Ein Alias oder ein Konfigurationswert reicht, damit ein Wechsel kein Deployment der Anwendung erfordert.

Drittens braucht die Benachrichtigung einen Empfänger, der etwas tun kann. Die Subscription-Rollen sind der Ort, an dem die Mail ankommt, nicht der Ort, an dem jemand migriert.

Ich halte die Fristen für fair. Neunzig Tage deprecated plus sechzig Tage Vorlauf sind mehr, als die meisten Bibliotheken dir geben. Mein Vorbehalt gilt der Automatik: Ein Upgrade, das dich stillschweigend in eine andere Modellfamilie hebt, ist bequem und macht deine letzte Evaluierung ungültig. Wenn du für einen Agenten nachweisen musst, mit welchem Modell er entschieden hat, ist die bequeme Einstellung die falsche.

Quellen

Microsoft Foundry · Development