# Claude Opus 5.5 ist kein Drop-in-Upgrade: Ein Migrationsleitfaden für produktive Agenten > Opus 5.5 ist günstiger und leistungsfähiger, doch API-Änderungen können Tool-Loops, Response-Parsing, Gesprächszustand und Computer-Use-Agenten brechen. So gelingt die Migration kontrolliert. Source: https://mcdougall-digital.de/de/blog/claude-opus-5-5-agent-migration/ Published: 2026-09-24 Author: Kyluke McDougall, McDougall Digital Language: de --- Claude Opus 5.5 trendet auf X, und die Kennzahlen lassen ein Upgrade zunächst selbstverständlich erscheinen. Anthropic zufolge erreicht das Modell bei vielen Aufgaben annähernd die Leistung des stärkeren Modells Fable 5.1, kostet bei typischen Workloads 40 Prozent weniger als Opus 5 und erzeugt Ausgaben mehr als 30 Prozent schneller. Der Listenpreis sinkt von 5 auf 4 US-Dollar pro Million Input-Token und von 25 auf 20 US-Dollar pro Million Output-Token. Außerdem berichtet Anthropic von besseren Ergebnissen beim agentischen Programmieren und einer höheren Widerstandsfähigkeit gegen Prompt Injection. Für Teams, die Claude über eine API betreiben, sind diese Verbesserungen nicht der dringendste Teil des Releases. Dringender ist der Migrationsvertrag. Opus 5.5 lehnt Request-Einstellungen ab, die frühere Modelle akzeptiert haben. Das Modell verändert die Struktur von Responses, die Regeln für das erneute Senden von Gesprächszustand und die Deklaration von Computer-Use-Tools. Manche Fehler führen sofort zu HTTP 400. Andere senken unbemerkt den Effort, entfernen sichtbare Fortschrittsmeldungen oder entziehen einem Fallback den bisherigen Reasoning-Kontext. Damit zeigt Opus 5.5 ein allgemeines Architekturprinzip besonders deutlich: **Ein Modell-Upgrade ist eine Dependency-Migration und keine Konfigurationsänderung.** ## Die Modell-ID ist die kleinste Änderung Anthropics Migrationsleitfaden nennt mehrere Einstellungen, die Opus 5.5 ablehnt: - Thinking deaktivieren oder ein manuelles Thinking-Token-Budget setzen; - Tool-Nutzung mit `tool_choice: any` oder einem benannten Tool erzwingen; - von den Standardwerten abweichende Werte für `temperature`, `top_p` oder `top_k` senden; - die Konversation mit einer vorbefüllten Assistant-Antwort beenden; - das ältere Computer-Use-Tool in der Claude API oder auf Google Cloud verwenden. Jeder dieser Punkte kann aus dem Austausch einer Modell-ID einen Produktionsfehler machen. In gewachsenen Systemen ist das Risiko größer, weil Modellparameter selten an nur einer Stelle definiert sind. Sie können in einem Gateway, einer Orchestrierungsbibliothek, einem Prompt-Template, einem Observability-Proxy und aufgabenspezifischen Overrides zusammengesetzt werden. Ein längst vergessener Parameter bleibt womöglich monatelang unauffällig, weil das alte Modell ihn toleriert. Vor dem Wechsel der Modell-ID sollte deshalb der tatsächliche Request erfasst werden, der die eigene Infrastruktur verlässt. Eine Quellcodesuche ist sinnvoll, Produktions-Traces sind ebenso wichtig. Das Format auf der Leitung ist der relevante Vertrag. ## Always-on Thinking verändert das Response-Parsing Opus 5.5 verwendet immer Adaptive Thinking. Die Tiefe lässt sich über die Einstellung `effort` steuern, vollständig deaktivieren lässt sich Thinking nicht. Das verändert mehr als das Modellverhalten. Eine Response kann mit einem oder mehreren Thinking-Blöcken vor dem ersten Textblock beginnen. Code wie `response.content[0].text` ist nicht mehr sicher. Streaming-Handler, die das erste Content-Event als Text interpretieren, können aus demselben Grund scheitern. Consumer sollten Blöcke anhand ihres Feldes `type` statt anhand ihrer Position verarbeiten. Das gilt für Benutzeroberflächen, Telemetrie, Ergebnisextraktion und Tool-Loops. Auch die Token-Rechnung verändert sich. `max_tokens` umfasst Thinking und sichtbare Ausgabe gemeinsam. Thinking-Token werden als Output berechnet, selbst wenn der Thinking-Text nicht zurückgegeben wird. Ein Limit, das bisher ausreichend Platz für eine vollständige Antwort bot, kann eine Aufgabe nun abschneiden, nachdem ein Teil des Budgets bereits für Reasoning verbraucht wurde. Hinzu kommt eine leisere Änderung: Opus 5 verwendete standardmäßig hohen Effort, Opus 5.5 startet mit mittlerem Effort. Wenn eine Anwendung den Parameter auslässt, läuft der aktualisierte Request ohne Fehlermeldung auf einer niedrigeren Stufe. Das kann die richtige Abwägung sein. Anthropics zentrale Aussage lautet schließlich, dass das neue Modell mit weniger Token bessere Arbeit leistet. Eine stille Standardänderung ist jedoch keine Evaluationsstrategie. Teams sollten den Effort explizit setzen und Qualität, Latenz sowie Gesamtkosten pro Aufgabe für niedrigen, mittleren und hohen Effort an repräsentativer Arbeit messen. ## Tool-Loops benötigen neue Invarianten Viele Agenten erzwingen einen Tool-Aufruf, wenn ein Schritt zwingend eine Datenbank abfragen, Code ausführen oder ein Dokument abrufen muss. Opus 5.5 akzeptiert keine erzwungene Tool-Auswahl mehr, weder über `any` noch über ein benanntes Tool. Anthropic empfiehlt automatische Tool-Auswahl in Kombination mit strikten Tool-Schemas, strukturierten Ausgaben und klaren Anweisungen dazu, wann ein Tool verwendet werden muss. Damit verändert sich die Garantie der Orchestrierungsschicht. Wenn ein Geschäftsprozess ohne einen erfolgreichen Lookup nicht fortgesetzt werden darf, sollte er sich nicht allein auf die Formulierung im Prompt verlassen. Anwendungscode muss das Modellergebnis validieren. Wurde das erforderliche Tool nicht aufgerufen, muss der Prozess stoppen, nach einer begrenzten Regel erneut versuchen oder die Aufgabe zur Prüfung weiterleiten. Die Invariante gehört in deterministischen Code, auch wenn das Modell die Anweisung normalerweise befolgt. Thinking-Blöcke führen eine weitere Anforderung ein. Enthält eine Assistant-Response Tool-Aufrufe, muss der Tool-Loop die Thinking-Blöcke vollständig und unverändert zusammen mit den Tool-Ergebnissen zurückgeben. Das Filtern leerer Blöcke, eine andere Reihenfolge oder ein Neuaufbau der Assistant-Nachricht kann den Zustand ungültig machen und einen Fehler auslösen. Das sicherste Muster ist einfach: Den Assistant-Turn so speichern, wie er empfangen wurde, Tool-Ergebnisse in einer neuen Nachricht anhängen und signierten Provider-Zustand als undurchsichtig behandeln. ## Konversationskomprimierung wird Teil der Kompatibilität Lang laufende Agenten behalten selten jede Nachricht unbegrenzt. Sie kürzen den Verlauf, fassen ältere Turns zusammen, ändern verfügbare Tools oder aktualisieren den System-Prompt, wenn ein Workflow in eine neue Phase wechselt. Diese Operationen sind nicht mehr nur Entscheidungen des Prompt Engineerings. Opus 5.5 bindet Thinking-Blöcke an die Konversation und das Modell, die sie erzeugt haben. Änderungen an früheren Nachrichten, Tool-Definitionen oder am System-Prompt können den gespeicherten Thinking-Zustand ungültig machen. Bei neueren Accounts wird das erneute Senden ungültiger Blöcke standardmäßig abgelehnt. Ältere Accounts erhalten möglicherweise noch nicht denselben Fehler, laut Anthropic bleiben die Blöcke trotzdem ungültig. Router erzeugen ein verwandtes Risiko. Ein Fallback-Modell kann eine Konversation ohne die früheren Thinking-Blöcke von Opus 5.5 fortsetzen, wenn es diese nicht lesen kann. Der Request kann erfolgreich sein, obwohl dem Agenten verborgener Zustand fehlt, der vorherige Entscheidungen beeinflusst hat. Das bedeutet nicht, dass Agenten unbegrenzten Verlauf behalten sollten. Es bedeutet, dass Komprimierung eine explizite Grenze benötigt: 1. den aktuellen Tool-Loop abschließen oder einen Checkpoint setzen; 2. eine saubere Zusammenfassung aus Fakten, Entscheidungen, offenen Fragen und Artefaktverweisen erstellen; 3. aus dieser Zusammenfassung eine neue Konversation starten; 4. Modell- und Policy-Wechsel in der Telemetrie erfassen; 5. prüfen, ob die fortgesetzte Aufgabe weiterhin ihre Akzeptanzkriterien erfüllt. Das ist eine Zustandsmigration, keine String-Verarbeitung. ## Bei Computer-Use-Agenten unterscheiden sich die Plattformen In der Claude API und auf Google Cloud ersetzt Opus 5.5 das bisherige Tool `computer_20251124` durch das Toolset `computer_toolset_20260801`. Auch das Event-Format ändert sich: Ein Turn kann mehrere Aktionen enthalten, und Tool-Ergebnisse müssen das Toolset benennen. Amazon Bedrock behält zum Veröffentlichungszeitpunkt das ältere Computer-Use-Tool. Genau solche Plattformunterschiede kann eine zu dünne Modellabstraktion bis zur Laufzeit verbergen. Wenn ein System mehrere Provider-Routen unterstützt, sollte die Capability-Erkennung explizit sein. Request-Builder sollten nach Modell und Plattform versioniert werden. Tests müssen den Event-Stream abdecken, nicht nur den initialen Request. Ein grüner Health Check mit „Hallo“ sagt nichts darüber aus, ob ein Browser-Loop mit mehreren Aktionen abgeschlossen werden kann. ## Refusal ist ein Anwendungszustand Opus 5.5 kann `stop_reason: refusal` mit strukturierten Details zurückgeben. Ein Agent, der nur „abgeschlossen“, „Tool erforderlich“ und „Token-Limit erreicht“ kennt, kann eine Ablehnung als erfolgreiche leere Antwort interpretieren oder in eine sinnlose Retry-Schleife geraten. Refusal gehört in die fachliche Zustandsmaschine. Die Anwendung muss entscheiden, ob sie: - dem Nutzer die Grenze erklärt; - sicherere Eingaben anfordert; - auf ein freigegebenes Modell ausweicht, sofern die Policy dies erlaubt; - die Aufgabe an einen Menschen weitergibt; - den Workflow ohne Seiteneffekte beendet. Retries brauchen Grenzen. Eine Policy-Ablehnung ist kein vorübergehender Netzwerkfehler. ## Eine Migrationssequenz für die Produktion Ein sicheres Upgrade muss keine Monate dauern, sollte aber mehrere Stufen haben. ### 1. Die reale Integration inventarisieren Modell-IDs, Request-Parameter, SDK-Versionen, Tool-Schemas, Response-Parser, Regeln zur Verlaufskomprimierung, Fallback-Routen und plattformspezifische Tools erfassen. Traces zeigen, was tatsächlich gesendet wird. ### 2. Contract Tests aufbauen Nicht nur die Antwortqualität testen. Jeder Request-Typ, jeder Streaming-Block, komplette Tool-Runden, Refusal-Pfade, Kontext-Checkpoints und Fallback-Wechsel gehören in die Tests. Fehlerhafte Eingaben und Grenzfälle sollten bewusst enthalten sein. ### 3. Einen Effort-Sweep durchführen Den alten Standard nicht übernehmen. Niedrigen, mittleren und hohen Effort an realen Aufgaben vergleichen. Akzeptanzrate, Latenz, Output-Token, Review-Zeit und Gesamtkosten messen. ### 4. Produktionsverkehr im Shadow-Modus ausführen Eine datenschutzgerechte Stichprobe erneut verarbeiten, ohne dem neuen Modell Seiteneffekte zu erlauben. Tool-Auswahl, strukturierte Ausgaben, Refusal-Raten und Ergebnisqualität mit dem aktuellen Pfad vergleichen. ### 5. Canary nach Workflow und Risiko Mit begrenzten, reversiblen Aufgaben beginnen. Destruktive Tools und folgenreiche Schreibzugriffe hinter menschlicher Freigabe halten. Den Traffic nur erhöhen, wenn die operativen Metriken stabil bleiben. ### 6. Einen getesteten Rollback erhalten Rollback bedeutet mehr als die alte Modell-ID wieder einzutragen. Von Opus 5.5 erzeugter Konversationszustand ist möglicherweise nicht portabel. Beim Rückweg muss eine neue Konversation aus einem Checkpoint gestartet werden können. ## Die dauerhafte Lehre Opus 5.5 kann ein starkes Upgrade sein. Niedrigere Preise, schnellere Ausgaben und bessere Ergebnisse bei lang laufenden Coding-Aufgaben könnten die Wirtschaftlichkeit ernsthafter Agenten-Workflows verbessern. Der Wert entsteht jedoch erst, wenn das umgebende System kompatibel ist. Das Modell sitzt in einer Architektur aus Request-Buildern, Tool-Verträgen, Zustandsverwaltung, Berechtigungen, Observability, Evaluation und Wiederherstellung. Verändert das Modell eine dieser Schnittstellen, muss die Architektur die Änderung bewusst aufnehmen. Am schnellsten profitieren nicht die Teams, die Modell-IDs am schnellsten austauschen. Es sind die Teams, die eine neue Abhängigkeit testen, ihr Verhalten beobachten, den möglichen Schaden begrenzen und einen Rollback durchführen können, ohne den Zustand des umgebenden Produkts zu verlieren. --- Dieser Beitrag wurde mit Unterstützung von KI erstellt. Verantwortlich für den Inhalt ist McDougall Digital.