Gestern Nacht bin ich später ins Bett gekommen als geplant. Anthropic hat Claude Opus 5.5 veröffentlicht, und statt zu schlafen habe ich das neue Modell durch meinen aktuellen Code gejagt. Für einen vollständigen Testbericht ist es zu früh. Schon der erste Test hat aber etwas gezeigt, das ich festhalten will: Opus 5.5 hat beim Code-Review meines Stackchan-Projekts zwei Fehler gefunden, die ich selbst übersehen hatte, obwohl ich seit Monaten an diesem Code sitze.
Das eigentlich Interessante an Claude Opus 5.5 ist nicht die Benchmark-Zahlen, die Anthropic veröffentlicht, sondern ob es in echtem, gewachsenem Code Ursachen findet und nicht nur Symptome beschreibt. Genau das habe ich gestern Nacht überprüft, und ich zeig dir, was dabei rausgekommen ist.
Was bringt Claude Opus 5.5 wirklich?
Anthropic hat Opus 5.5 gestern, am 22. September 2026, als erstes Modell der neuen Claude-5.5-Familie vorgestellt. Die Positionierung ist ungewöhnlich direkt: Das Unternehmen sagt selbst, Opus 5.5 arbeite auf dem Niveau von Claude Fable 5.1, dem bisherigen Spitzenmodell, koste aber 40 Prozent weniger im Betrieb. Sonnet 5.5 und Haiku 5.5 sollen in den kommenden Wochen folgen. Als KI-Berater mit Wurzeln in der Kommunikationsbranche seit 1989 teste ich neue Modelle nicht, um Benchmarks nachzubeten. Mich interessiert, was ein Modell in echtem, unaufgeräumtem Code leistet, an dem ich selbst seit Wochen arbeite.
Zur Einordnung, weil der Begriff öfter fällt: Agentic Coding meint, dass ein Modell nicht nur einzelne Codezeilen liefert, sondern selbstständig mehrschrittige Aufgaben plant, ausführt und sein eigenes Ergebnis überprüft, ohne bei jedem Schritt nachfragen zu müssen. Das Alignment-Audit wiederum ist Anthropics interner Test, der ein Modell durch tausende simulierte Szenarien schickt, um zu prüfen, ob es sich innerhalb der gesetzten Grenzen verhält.
Die Zahlen hinter Opus 5.5 sind konkret. Input-Tokens kosten 4 US-Dollar pro Million, Output-Tokens 20 US-Dollar, das sind 20 Prozent weniger als bei Opus 5. Cache-Reads, die bei agentischer Arbeit und Coding den Großteil der Kosten ausmachen, fallen mit 0,20 US-Dollar pro Million Tokens um 60 Prozent günstiger aus. Dazu kommt eine Geschwindigkeit, die laut Anthropics offizieller Ankündigung mehr als 30 Prozent über der von Opus 5 liegt.
Interessant ist der Kontext, in dem Anthropic das Modell veröffentlicht. Es ist die erste Veröffentlichung, seit CEO Dario Amodei öffentlich dafür plädiert hat, das Tempo der KI-Entwicklung bewusst zu drosseln, damit die Sicherheitsarbeit nicht hinter der Fähigkeitsentwicklung zurückbleibt. Opus 5.5 wurde vor der Veröffentlichung von externen Prüforganisationen getestet, darunter METR, und erzielt im eigenen Alignment-Audit die bisher besten Werte aller getesteten Modelle. Bei Biologie und Cybersicherheit liegt das Modell nach Unternehmensangaben nahe an Claude Mythos 5.1, weshalb es mit ähnlichen Schutzmechanismen ausgeliefert wird wie Fable 5.1: Die meisten Cybersecurity-Aufgaben werden an Opus 4.8 umgeleitet, für Biologie-Anwendungsfälle gibt es ein eigenes Verifizierungsprogramm für geprüfte Organisationen.
Wer sich schon länger mit den Opus-Versionen beschäftigt, kennt das Muster aus meinem Praxis-Check zu Opus 4.8: Anthropic verpackt jede neue Version in eine nüchterne Zahlentabelle, aber das eigentlich Relevante steckt meistens daneben, nicht in der Tabelle selbst. Für meine Praxis zählt vor allem ein Punkt, den Anthropic als Kommunikationsverbesserung beschreibt: Das Modell soll klarer strukturieren, weniger Fachjargon verwenden und die wichtigste Information zuerst liefern. Genau das habe ich beim Code-Review heute Nacht bestätigt gefunden, dazu gleich mehr.
Ich bin mir da noch nicht ganz sicher, aber mein Eindruck nach dieser ersten Session ist: Der Sprung fühlt sich weniger nach einem weiteren Versionssprung an und mehr nach einer Verschiebung, wie ein Modell mit bestehendem Code umgeht, nicht nur, was es neu erzeugt. In meinem Vergleich der großen Sprachmodelle habe ich Claude schon vor Monaten als das Modell beschrieben, das über lange Aufgaben seinen roten Faden hält. Opus 5.5 verstärkt diesen Eindruck, statt ihn zu widerlegen.
Wie ich Opus 5.5 im Stackchan-Projekt getestet habe
Mein Stackchan-Projekt ist ein guter Stresstest, weil es kein sauberes Greenfield-Setup ist. Ich habe einen M5Stack-CoreS3-Roboter mit selbst gebauter Firmware laufen, der seit gestern über eine eigene Entity-Abfrage mit drei Fallback-Stufen an meine Home-Assistant-Installation angebunden ist: Erst wird der Bereich direkt an der Entity geprüft, dann am zugehörigen Gerät, und wenn beides leer bleibt, greift eine Heuristik aus dem Entity-Namen selbst. Darüber spricht der Roboter mit meinen Lichtern, Sensoren und formuliert Antworten über eine Text-zu-Sprache-Pipeline, die zuerst den Antworttext zusammensetzt und ihn dann als Audio an das Gerät zurückschickt. Viele bewegliche Teile, viele Stellen, an denen sich ein Fehler einschleichen kann.
Ich habe Opus 5.5 in Claude Desktop den aktuellen Stand des Projekts durchsehen lassen, ganz normaler Code-Review, keine speziell präparierte Testaufgabe. Es war mein erster Test mit dem Modell überhaupt, ich habe es also ohne Referenzpunkt zu Opus 5 im selben Setup eingesetzt. Das Ergebnis war trotzdem eindeutig: Opus 5.5 hat zwei Fehler in der Abfrage der Home-Assistant-Entities identifiziert, die dazu führten, dass die Sprachausgabe verstümmelt beim Gerät ankam.
Das ist der Punkt, an dem es interessant wird. Ich kenne verstümmelte Sprachausgabe als Symptom aus der Praxis, ich habe es schon länger auf dem Schirm gehabt. Was ich nicht auf dem Schirm hatte: dass die Ursache nicht allein in der Sprachausgabe selbst liegt, sondern früher beginnt, nämlich in der Art, wie Entity-Daten aus Home Assistant abgefragt und weitergereicht werden, bevor sie überhaupt bei der Sprachsynthese ankommen. Wenn diese Abfrage fehlerhafte oder unvollständige Daten liefert, bekommt die Text-zu-Sprache-Strecke danach schlicht kaputten Input, egal wie sauber die Sprachausgabe selbst mit gesunden Daten umgehen würde.
Das ist genau die Art Fehler, die man als Entwickler leicht übersieht, wenn man das eigene System schon monatelang kennt. Man hat sich an das Symptom gewöhnt und sucht die Ursache dort, wo man sie vermutet, in der Sprachausgabe oder in der Firmware. Dass zwei Fehler in der vorgelagerten Abfrage der Entities selbst stecken, hätte ich beim x-ten Mal Drüberschauen vermutlich wieder übersehen. In meinem Artikel darüber, warum ein Prompt nur so schlau ist wie der Mensch dahinter, habe ich genau dieses Problem beschrieben: Code, der beim ersten Blick funktioniert und strukturell trotzdem einen Fehler trägt, der sich erst später zeigt. Ein zweites Augenpaar, egal ob Mensch oder Modell, ist dafür kein Luxus, sondern Handwerk.
Was das für meine Arbeit bedeutet
Ich will das nicht überinterpretieren, ein einzelner Test mit einem Projekt ist keine Studie. Aber es deckt sich mit dem, was Anthropic zur Kommunikationsqualität von Opus 5.5 schreibt: Das Modell soll die wichtigste Information zuerst liefern, statt sie in einer langen Analyse zu vergraben. Bei meinem Review habe ich genau das erlebt. Keine seitenlange Auflistung aller theoretisch denkbaren Probleme, sondern eine klare Benennung der zwei konkreten Fehler in der Entity-Abfrage, mit Bezug auf die Stelle im Code, an der sie auftreten.
Für meine Beratungsarbeit mit EPU und KMU in der DACH-Region ist das relevant, weil Code-Review-Qualität selten das ist, worüber gesprochen wird, wenn es um neue Sprachmodelle geht. Die meisten Diskussionen drehen sich um Benchmarks, um Preise, um die nächste Marketingzahl. Ob ein Modell in echtem, gewachsenem Code Ursachen findet und nicht nur Symptome beschreibt, das zeigt sich erst im Alltag, nicht im Prospekt. Ich habe schon beim Umbau von VINCI von der Webapp zur Desktop-App gemerkt, wie viel Unterschied ein Modell macht, das Rückfragen stellt statt einfach draufzulosschreiben. Bei diesem Code-Review war es dieselbe Erfahrung, nur diesmal beim reinen Fehlerfinden statt beim Bauen.
Ich werde Opus 5.5 in den kommenden Wochen weiter durch meine laufenden Projekte schicken. Ein vollständiger Vergleich zu Opus 5 und Fable 5.1 in derselben Codebasis steht noch aus, das hole ich nach, sobald ich genug Sessions gesammelt habe, um mehr als einen einzelnen Eindruck zu liefern.
Was mich am meisten überrascht hat: nicht, dass ein neues Modell Fehler findet, das würde ich von jedem halbwegs kompetenten Review erwarten. Überrascht hat mich, wie präzise die Ursachenkette benannt wurde, von der verstümmelten Sprachausgabe zurück zur fehlerhaften Entity-Abfrage, in einem ersten, unvorbereiteten Test. Ob sich dieser Eindruck bei komplexeren Projekten hält, wird sich zeigen. Als Einstand ist das für mich ein sehr guter.
