Anthropic hat angekündigt, claude-sonnet-4-5-20250929 am 30. November 2026 auf der Claude API abzuschalten. Als Nachfolger nennt der Anbieter claude-sonnet-5-5. Die Ankündigung betrifft die genannte API. Für einen anderen Bereitstellungsweg gilt der Termin des jeweiligen Anbieters. Anthropic: Modellabschaltungen
Im folgenden Beispiel verwendet ein Kundenservice das Modell, um Antworten vorzubereiten. Ein eigenes Werkzeug namens bestellstatus_lesen liefert den Eintrag aus dem Warenwirtschaftssystem. Der Ablauf hat die Anforderung, erst nach einer erfolgreichen Abfrage einen Lieferstatus zur Freigabe vorzulegen. Die Bestelldaten und die Prüffälle sind konstruiert.
Die erzwungene Abfrage fällt beim Wechsel weg
Mit Sonnet 4.5 kann eine Anwendung über tool_choice ein bestimmtes Werkzeug vorgeben oder die Nutzung eines beliebigen Werkzeugs erzwingen. Sonnet 5.5 weist die Varianten tool und any laut Anthropic mit HTTP 400 zurück. Eine Änderung der Modellkennung allein würde einen solchen Aufruf also scheitern lassen. Anthropic: Wechsel zu Sonnet 5.5
Der Anbieter beschreibt als Alternative tool_choice vom Typ auto. Mit strict: true kann das Werkzeug seine Eingaben an ein festes Schema binden. Diese Prüfung greift, wenn das Modell das Werkzeug tatsächlich aufruft. Im Modus auto kann es auch direkt einen Text zurückgeben. Die Anwendung muss deshalb selbst prüfen, ob eine erfolgreiche Abfrage vorliegt, bevor sie den Lieferstatus weitergibt.
Die Freigabe gehört an das Ergebnis der Abfrage
Für den Kundenservice bedeutet das eine Änderung an der Freigabe. Der Satz „Ihre Bestellung wurde versendet“ reicht als Nachweis nicht aus. Vor der Freigabe gleicht die Anwendung den Status im Entwurf mit dem erhaltenen Ergebnis für diese Bestellung ab. Dabei muss auch die Bestellnummer stimmen. Ein gültiges Werkzeugargument kann sich auf die falsche Bestellung beziehen.
Wenn die Abfrage eine Pflicht ist, kann die Anwendung sie nach Prüfung der Bestellnummer selbst ausführen und das Ergebnis an das Modell weitergeben. Soll das Modell die Abfrage weiter auswählen, braucht die Anwendung einen eigenen Pfad für fehlende oder fehlgeschlagene Abfragen. Ein ungeprüfter Status bleibt dann beim Supportteam statt im Kundenentwurf.
Drei Fälle für die erneute Abnahme
Nehmen Sie einen Fall aus der früheren Freigabe, dessen erwartetes Ergebnis noch gilt. Legen Sie dazu zwei Varianten an. Prüfen Sie den ganzen Weg vom Eingang der Anfrage bis zum Kundenentwurf.
- Die richtige Bestellnummer ist vorhanden und das System liefert „versendet“. Im Entwurf steht derselbe Status. Das Protokoll verbindet den Entwurf mit dem erfolgreichen Abruf dieser Bestellung.
- Der Aufruf des Modells gelingt, aber es kommt kein Werkzeugaufruf zurück. Der Ablauf gibt keinen Lieferstatus zur Freigabe. Er holt den Status nach der vereinbarten Regel ein oder legt den Fall dem Supportteam vor.
- Prüfen Sie getrennt, was bei einer fehlgeschlagenen Abfrage und bei einem Ergebnis für eine andere Bestellung passiert. In beiden Fällen hält die Anwendung den Kundenentwurf zurück. Im internen Fall steht, warum die Statusprüfung offen ist.
Für den ersten Fall können Sie einen früheren, fachlich freigegebenen Entwurf als Referenz nehmen, wenn Bestellung und Systemstand dokumentiert sind. Gleiche Formulierungen sind dafür zweitrangig. Entscheidend ist, ob die neue Anwendung denselben belegten Status durchlässt und in den beiden anderen Fällen keinen Lieferstatus ohne bestätigte Abfrage freigibt. Weitere Fälle für die Abnahme eines KI-Workflows
Quellen
- Anthropic: Model deprecations (Claude Sonnet 4.5) Geprüft am 6. November 2026
- Anthropic: Claude Sonnet 5.5 migration guide Geprüft am 6. November 2026
Mehr zur Auswahl und Einordnung von Quellen steht in unserer Arbeitsweise.
Eine Angabe fehlt oder stimmt nicht?
Hinweis an die Redaktion ↗