Vier Spitzenmodelle in 48 Stunden: Wie Unternehmen ein neues KI-Modell einführen, ohne ihr Produkt zu brechen

Vier Spitzenmodelle in einer Woche

Am 21. September veröffentlichten xAI mit Grok 4.7 und Xiaomi mit MiMo‑V2.6‑Pro zwei neue Modelle, das eine proprietär, das andere mit offenen Gewichten. Am 22. September folgte Anthropic mit Claude Opus 5.5 — günstiger als der Vorgänger Opus 5 und mit eigener Migrationsanleitung für Entwickler —, rund 90 Minuten später OpenAI mit GPT‑6 Sol und Luna, laut TechCrunch „boasting lower cost and fewer mistakes“. Vier Spitzenmodelle in 48 Stunden.

Für Konsumenten ist dieses Tempo ein Kuriosum. Für jedes Unternehmen, das eines der Vorgängermodelle produktiv eingebaut hat, ist es der eigentliche Befund: Ein neues Spitzenmodell ist kein Ereignis mehr, das man einmal bewertet und dann jahrelang laufen lässt, sondern ein wiederkehrender Betriebsvorgang. Die Frage ist nicht mehr, ob man wechselt, sondern wie man das tut, ohne dass Support-Tickets, Preisliste oder Kernfunktion des Produkts an einem Dienstagmorgen plötzlich anders aussehen.

Gepinnt statt „-latest“: die erste Entscheidung

Die meisten Anbieter bieten zwei Arten, ein Modell anzusprechen: eine gepinnte, exakt versionierte ID — vergleichbar mit einer festen Software-Version, die sich nie von selbst ändert — und einen Alias wie „-latest“, der eher wie die Auto-Update-Einstellung eines Smartphones funktioniert: bequem, aber man weiß nie genau, welche Version morgen läuft. Anthropic warnt in seiner Dokumentation zu Modell-IDs ausdrücklich vor einem verbreiteten Missverständnis: „A common misconception is that dateless model IDs such as claude-sonnet-4-6 behave as evergreen pointers that route to the latest or best-performing version. That is not the case“ — die Annahme, datumslose IDs würden automatisch zur jeweils besten Version zeigen, ist seit der Claude-4.6-Generation schlicht falsch, jede solche ID ist ein fixierter Schnappschuss. Nur ältere, ausdrücklich als Alias gekennzeichnete IDs wie claude-sonnet-4-5 verhalten sich anders: Sie „resolve to the most recent dated snapshot for that minor version“ und können sich damit unter der Hand ändern, ohne dass im eigenen Code etwas angefasst wurde.

Für die Praxis heißt das: Wer in Produktion auf einen Alias statt auf eine gepinnte Version setzt, hat den Modellwechsel nicht vermieden, sondern nur seinen Zeitpunkt an den Anbieter delegiert — und verliert die Möglichkeit, vorher zu testen. Die saubere Reihenfolge ist umgekehrt: erst auf einer gepinnten neuen Version evaluieren, dann bewusst umstellen.

Evals als Torwächter

Was ein Anbieter in seinen eigenen Benchmarks zeigt, sagt wenig darüber aus, wie ein Modell auf die eigene Kundschaft, den eigenen Ton und die eigenen Grenzfälle reagiert — dazu hat dieses Magazin in der Reportage vom 14. August bereits am Beispiel des Tokenpreises gezeigt, dass die einkaufsrelevante Zahl selten die ist, die im Marketing steht. Für Modellwechsel gilt das ebenso, nur dass hier nicht der Preis, sondern das Verhalten unter der Lupe steht. Der gängige Ausweg heißt Evals: eigene Testsätze, gebaut aus echten Produktionsanfragen, gegen die jede Modellversion vor dem Rollout laufen muss — im Prinzip ein Regressionstest, wie man ihn aus der klassischen Softwareentwicklung kennt, nur dass die „Assertions“ oft nicht exakt, sondern über ein zweites Modell als Bewerter (LLM-as-Judge) geprüft werden. Genau das ist die Schwachstelle: Ein Richter-Modell hat eigene Vorlieben und Blindstellen, weshalb erfahrene Teams seine Urteile stichprobenhaft von Menschen gegenprüfen, statt ihm blind zu vertrauen. Als Werkzeuge dafür haben sich neben OpenAIs eigenem, offenem Evals-Framework — laut Projektbeschreibung „a framework for evaluating LLMs and LLM systems, and an open-source registry of benchmarks“ — kommerzielle Plattformen wie Promptfoo, Braintrust oder LangSmith etabliert, die Testläufe, Kennzahlen und Regressionsvergleiche zwischen Modellversionen verwalten.

Wie teuer das Fehlen solcher Gates werden kann, zeigte OpenAI selbst im April 2025. Ein Update von GPT‑4o hatte das Modell übertrieben zustimmend gemacht; OpenAI musste es zurückrollen und schrieb dazu offen: „We have rolled back last week's GPT‑4o update in ChatGPT so people are now using an earlier version with more balanced behavior.“ Zur Ursache hieß es: man habe „too much on short-term feedback“ (zu stark auf kurzfristiges Nutzerfeedback) optimiert und dabei nicht berücksichtigt, wie sich die Wahrnehmung über die Zeit entwickelt — mit dem Ergebnis, dass das Modell „overly supportive but disingenuous“ wurde, also unaufrichtig gefällig. Der Vorfall lief bei einem laufenden Modell, nicht erst bei einem Anbieterwechsel — genau deshalb zeigt er, wie wenig ein Verhaltensbruch mit äußerer Ursache zu tun haben muss und wie sehr er ein eigenes, kontinuierliches Monitoring braucht.

Prompts sind nicht portabel

Selbst wer beim selben Anbieter bleibt, migriert nicht kostenlos. Anthropics eigener Migrationsleitfaden zu Claude Opus 5.5 listet vier Breaking Changes gegenüber dem Vorgänger Opus 5 auf. Zwei davon dürften jeden treffen, der viel Automatisierung um das Modell gebaut hat: „thinking.type.disabled“ und „thinking.type.enabled“ werden nicht mehr akzeptiert, das Ausschalten oder manuelle Budgetieren des Denkprozesses quittiert die API stattdessen mit einem 400er-Fehler — wo bisher Kosten durch Abschalten des Nachdenkens gespart wurden, tritt jetzt ein „effort“-Level als Regler an dessen Stelle. Ebenso entfällt erzwungene Werkzeugnutzung: tool_choice-Werte wie „any“ oder „tool“ liefern ebenfalls einen 400er, empfohlen wird stattdessen „auto“ in Kombination mit strikter Werkzeugnutzung. Wer Prompt-Vorlagen, Fehlerbehandlung oder Kostenkalkulation auf das alte Verhalten gebaut hat, muss beides anfassen, bevor das neue Modell überhaupt lauffähig ist — nicht, weil es schlechter ist, sondern weil es anders funktioniert. Immerhin: Anthropic bietet für genau diesen Fall inzwischen ein automatisiertes Migrationswerkzeug innerhalb seiner Entwicklungsumgebung an, das die ID ersetzt und bekannte Breaking Changes im Code aufspürt — ein Eingeständnis, wie viele Kunden bei jedem Versionswechsel an denselben Stellen hängen bleiben.

Die Kostenseite: Cache-Fenster und Routing

Migrieren verändert auch die Rechnung, und zwar nicht nur über den Preis pro Token. Mit GPT‑6 hat OpenAI am 22. September sein Prompt-Caching überarbeitet: Wiederverwendete Kontext-Anteile — etwa gleichbleibende Systemanweisungen oder Werkzeugdefinitionen — werden weiterhin mit bis zu 90 Prozent Rabatt auf die zwischengespeicherten Eingabe-Token abgerechnet, neu ist, dass gemeinsame Anfangsstücke eines Prompts jetzt innerhalb eines Fensters von 30 Minuten als Treffer gelten. GitHub-Produktchef Mario Rodriguez wird in der Ankündigung zitiert: sein Team habe „by more than 50% the share of prompt tokens requiring fresh processing“ reduziert — mehr als die Hälfte der zuvor komplett neu verarbeiteten Prompt-Token entfallen jetzt auf den Cache. Entscheidend für die Praxis: Der Cache erkennt nur identische Anfangsstücke — OpenAIs neues Diagnosewerkzeug meldet Fehltreffer etwa mit dem Grund, dass sich die Werkzeugdefinitionen geändert haben — wer also bei einem Modellwechsel gleichzeitig Prompts umschreibt, verliert unter Umständen genau den Kostenvorteil, den das neue Modell mitbringen sollte. Arian Hanifi, Technikchef eines der in der Ankündigung zitierten Kunden, berichtet von einer Verbesserung der Trefferrate „by a few percentage points, reducing costs by 20%“ durch gezieltes Monitoring statt Zufall. Wer, wie in der Reportage vom 14. August beschrieben, ohnehin nach Kosten pro gelöster Aufgabe statt nach Kosten pro Token rechnet, sollte diese Cache-Mechanik als festen Bestandteil jeder Migrationsrechnung mitführen, nicht als Fußnote.

Der Rückzug hat eine Frist — und eine Checkliste

Die drei großen Anbieter geben unterschiedlich lange Vorlauf, bevor ein Modell abgeschaltet wird, aber alle geben einen Vorlauf. OpenAI verspricht für allgemein verfügbare Modelle „at least 6 months“, für spezialisierte Varianten „at least 3 months“ und für Preview-Modelle nur „much shorter notice, such as 2 weeks“ — wer also mit einem als „preview“ gekennzeichneten Modell produktiv arbeitet, spielt bewusst mit der kürzesten Frist. Anthropic garantiert „at least 60 days' notice before model retirement for publicly released models“ und sagt zusätzlich zu, Modellgewichte danach nicht zu löschen: Man habe sich verpflichtet, „preserving the weights of all publicly released models ... for, at minimum, the lifetime of Anthropic as a company“ — die Gewichte bleiben also erhalten, auch wenn der Zugriff über die API endet. Google gibt für seine als „GA“ eingestuften Gemini-Modelle mindestens zwölf Monate Verfügbarkeit ab Release, für kurzlebigere Zwischenversionen aber nur „at least 45 days to migrate“ ab Ankündigung des Abschalttermins — ein Unterschied, den man vor der Modellwahl kennen sollte, nicht erst beim Abschalt-Hinweis.

Für Unternehmen mit Sitz in der EU kommt eine zweite Frist hinzu, die zunächst den Anbieter trifft: Seit dem 2. August 2025 gelten die Transparenz- und Urheberrechtspflichten des AI Act für Anbieter von General-Purpose-AI-Modellen — Modelle, die laut Kommission mit „over 10^23 FLOP“ trainiert wurden; Modelle, die bereits vor diesem Stichtag am Markt waren, müssen erst bis zum 2. August 2027 nachziehen. Die Pflicht trifft den Modellanbieter, nicht seine Kunden. Wer aber das Modell hinter dem eigenen Produkt wechselt, tut gut daran, ebenso sorgfältig festzuhalten, was er einsetzt: welches Modell, welche Version, ab wann, mit welchem Testergebnis. Spätestens wenn ein Kunde, ein Prüfer oder die eigene Rechtsabteilung fragt, ist diese Liste mehr wert als jede Benchmark.

Daraus lässt sich ein Ablauf destillieren, der sich wiederholen lässt, statt jedes Mal neu erfunden zu werden: Erstens, jede Produktionsanfrage an eine gepinnte, versionierte Modell-ID binden, nie an einen automatisch aktualisierenden Alias. Zweitens, vor jedem Wechsel den eigenen Eval-Satz aus echten Produktionsfällen laufen lassen — nicht den Benchmark des Anbieters. Drittens, Breaking Changes in der Migrationsanleitung des Anbieters Zeile für Zeile gegen den eigenen Code prüfen, bevor man die ID tauscht. Viertens, Cache-Konfiguration und Kostenrechnung getrennt von der Modellwahl neu bewerten. Fünftens, die Abschaltfrist des alten Modells im Kalender eintragen, sobald die Migration beginnt, nicht erst, wenn die E-Mail des Anbieters kommt. Wer diese fünf Punkte als Standardprozess führt, erlebt den nächsten Modellwechsel als Routine — und nicht als Notfall am Dienstagmorgen.