SLATEMOTH / ANALYSE
Ein Modellwechsel ändert den Integrationsvertrag – nicht nur die Modell-ID
Claude Sonnet 5.5 zeigt, warum Agenten vor einem Modellwechsel erneut auf Denkmodus, Werkzeuge, Gesprächsverlauf und Ablehnungen geprüft werden müssen.
Der Modellname ist nur eine Zeile der Änderung
Anthropic veröffentlichte Claude Sonnet 5.5 am 28. September und berichtete von höherer Geschwindigkeit und besserer Effizienz pro Aufgabe. Für Teams, die Anfragen an die Messages API selbst erstellen, verdient der Migrationsleitfaden ebenso viel Aufmerksamkeit wie die Leistungsangaben. Er beschreibt Änderungen an zulässigen Parametern und am Umgang mit Gesprächsverläufen. Wer Claude Managed Agents nutzt, muss laut Anthropic dagegen nur den Modellnamen aktualisieren. Die folgende Analyse betrifft eigene API-Integrationen. [1] [2]
Ein Rauchtest mit nur einem Gesprächsschritt kann zwei verschiedene Probleme übersehen: eine Anfrage, die sofort fehlschlägt, und eine erfolgreiche Anfrage, die mit verändertem Kontext weiterläuft. Dafür braucht es getrennte Abnahmekriterien. Eine erfolgreiche HTTP-Antwort belegt, dass der Dienst geantwortet hat; sie belegt nicht, dass die Anwendung ihren Arbeitsablauf beibehalten hat. Dieser Unterschied sollte den Migrationsplan bestimmen.
Das Abschalten des Denkens vor der Antwort hat eine neue Form
Sonnet 5 akzeptierte thinking: {"type": "disabled"}. Sonnet 5.5 weist diese Einstellung mit einem 400-Fehler zurück. Die niedrigste Denkeinstellung heißt between_tools und ist bei den Aufwandsstufen low, medium und high verfügbar; xhigh und max werden damit abgelehnt. Das ändert den Vertrag für Anfragen und ist nicht bloß eine andere Feinabstimmung. Teams, die disabled genutzt haben, um die Latenz zu begrenzen, sollten die neue Einstellung bewusst wählen und ihren Arbeitsablauf erneut messen, statt eine unveränderte Übernahme der alten Anfrage vorauszusetzen. [2]
Der Modus between_tools unterbindet erweitertes Denken vor der Antwort. Fortschrittsmeldungen zwischen Werkzeugaufrufen können aber weiterhin als thinking-Blöcke ankommen. Eine Werkzeugschleife muss diese Blöcke zusammen mit der Assistentennachricht unverändert zurückgeben. Zu prüfen sind Clients, die den ersten Inhaltsblock stets für Text halten oder eine Assistentenantwort nur aus Text und Werkzeugaufrufen rekonstruieren. Beim Lesen ist der Typ des Inhaltsblocks maßgeblich; beim Fortsetzen ist die vom API zurückgegebene vollständige Assistentenantwort zu übernehmen. [2] [6]
Gültige Werkzeugargumente garantieren noch keinen Werkzeugaufruf
Sonnet 5.5 lehnt die erzwungenen tool_choice-Werte tool und any ab. Anthropic empfiehlt auto mit strengen Werkzeugschemata, soweit die Plattform diese unterstützt. Ein strenges Schema begrenzt die Form eines tatsächlich erfolgten Werkzeugaufrufs; auto erlaubt dem Modell weiterhin, ohne Aufruf zu antworten. Amazon Bedrock bietet für dieses Modell keine strenge Werkzeugnutzung an, sodass Anwendungen dort Werkzeugeingaben selbst validieren müssen. [2] [4]
Das hat praktische Folgen. Muss ein Arbeitsablauf vor der Antwort den aktuellen Datensatz abrufen, ist eine formal korrekte Antwort kein Beleg dafür, dass der Abruf stattfand. Markieren Sie den Schritt erst als abgeschlossen, wenn das erforderliche Werkzeugergebnis vorliegt und validiert wurde. Verankern Sie diese Regel in der Anwendung und testen Sie beide Pfade: einen gültigen Werkzeugaufruf und eine direkte Antwort, obwohl der Aufruf erforderlich war. Das ist eine architektonische Folgerung aus dem dokumentierten Werkzeugverhalten, keine Aussage darüber, wie häufig Sonnet 5.5 Werkzeuge auslässt.
Auch HTTP 200 kann einen verlorenen Gesprächszusammenhang verbergen
thinking-Blöcke von Sonnet 5.5 können nur von dem Konto, das sie erzeugt hat, oder von einem verknüpften Konto erneut verwendet werden. Sendet ein nicht verknüpftes Konto einen solchen Block zurück, verwirft das API ihn vor der Inferenz und beantwortet die Anfrage dennoch erfolgreich; ohne den entsprechenden Diagnose-Header bleibt das unbemerkt. Auch ein Modellwechsel kann dazu führen, dass ein Block nicht gelesen wird. Eine erfolgreiche Antwort des Routers beweist somit nicht, dass das Modell die früheren Denkinhalte erhalten hat. [3]
Daneben gilt eine Regel für den bisherigen Gesprächsanfang: Frühere Systemanweisungen, Werkzeuge und Nachrichten müssen unverändert bleiben, wenn ein signierter thinking-Block erneut gesendet wird. Für Konten, die am oder nach dem 31. August 2026 erstellt wurden, wird diese Prüfung standardmäßig durchgesetzt; ältere Konten haben andere Voreinstellungen. Ein fehlerfreier Test mit einem Schlüssel beweist deshalb nicht, dass es bei allen Konten funktioniert. Erhalten Sie den Verlauf als ausschließlich ergänzte Historie und testen Sie beim Umstieg das Speichern und Fortsetzen, Werkzeugänderungen, das Kürzen des Verlaufs im Client und Routenwechsel. Wo unterstützt, zeigt input_transformations, ob Blöcke verworfen wurden. [3]
Eine Ablehnung ist ein Ergebnis und kein Timeout für einen erneuten Versuch
Der Migrationsleitfaden verlangt auch, Ablehnungen zu behandeln. Eine Ablehnung gehört in die Antwort- und Prüflogik des Produkts. Sie unbesehen wie eine fehlgeschlagene Netzwerkanfrage erneut zu senden, verwechselt eine Richtlinienentscheidung mit einem Ausfall. Anthropic dokumentiert für bestimmte Ablehnungskategorien auf der Claude API einen begrenzten, optionalen serverseitigen Fallback. Das macht weder jede Ablehnung wiederholbar noch verspricht es dasselbe Verhalten auf jeder Hosting-Plattform. [5]
Erfassen Sie bei der Abnahme den tatsächlichen Stoppgrund, ob ein offiziell konfigurierter Fallback erfolgte und was die Nutzenden gesehen haben. So bleibt der Umgang mit Sicherheitsentscheidungen beobachtbar, ohne eine Wiederholung auf niedriger Ebene als Umgehung einer Ablehnung zu behandeln. Zugleich verhindert es, dass ein Dashboard erfolgreicher HTTP-Antworten eine Änderung der Antworten für Nutzende verdeckt.
Testen Sie den Arbeitsablauf, der später produktiv läuft
Wir schlagen fünf Abnahmepfade vor: eine alte Anfrage mit deaktiviertem Denken; einen bisher erzwungenen Werkzeugaufruf; einen mehrstufigen Werkzeugaustausch mit erneut gesendeten thinking-Blöcken; die Wiederaufnahme eines gespeicherten Gesprächs über die tatsächlich verwendeten Konten und Routen; und eine vom Produkt behandelte Ablehnung. Prüfen Sie HTTP-Status, Typen der Inhaltsblöcke, Ausführung und Validierung der Werkzeuge, verfügbare Diagnosen zur Gesprächskontinuität und den für Nutzende sichtbaren Endzustand. Nehmen Sie eine lange Sitzung und einen Routenwechsel hinzu, denn ein einstufiger Rauchtest kann Fehler im Verlauf nicht aufdecken.
Vergleichen Sie erst danach bei einer angegebenen Aufwandsstufe die Quote abgenommener Aufgaben, die verstrichene Zeit und die Kosten pro abgenommener Aufgabe. Die Geschwindigkeits- und Kostenaussagen von Anthropic sind nützliche Hypothesen für diesen Versuch, aber kein Ersatz dafür. Die allgemeinere Lehre reicht über diese Veröffentlichung hinaus: Ein Modell ist Teil eines Protokolls zwischen Anwendung, Werkzeugen, Verlauf und Nutzenden. Der Wechsel ist erst abgeschlossen, wenn dieses Protokoll weiterhin das beabsichtigte Ergebnis liefert. [1]
Quellen und Überprüfung
- Anthropic · Vorstellung von Claude Sonnet 5.5, 28. September 2026
- Dokumentation der Claude Platform · Migration zu Claude Sonnet 5.5; abgerufen am 29. September 2026
- Dokumentation der Claude Platform · Bewahrte Denkblöcke; abgerufen am 29. September 2026
- Dokumentation der Claude Platform · Strenge Werkzeugnutzung; abgerufen am 29. September 2026
- Dokumentation der Claude Platform · Ablehnungen und Fallback; abgerufen am 29. September 2026
- Dokumentation der Claude Platform · Denken in Werkzeug- und mehrstufigen Arbeitsabläufen; abgerufen am 29. September 2026