3 Min. Lesezeit

Claude Opus 5.5 arbeitet beim Coding eigenständiger

Claude Opus 5.5Claude Codeагентное программирование

Claude Opus 5.5 erschien am 22. September 2026 für Claude Code und CLI-Workflows. Das Modell bietet ein Kontextfenster von 1 Million Token, bis zu 128.000 Output-Token, niedrigere Preise und mehr Eigenständigkeit bei langen Programmieraufgaben, was dauerhafte Agentenläufe praxistauglicher macht.

Was sich bei Claude Opus 5.5 geändert hat

Wenn ich Claude Opus 5.5 betrachte, sehe ich kein bloß kosmetisches Update, sondern den Versuch, das Modell bei langer autonomer Arbeit robuster zu machen. Anthropic stellte es am 22. September 2026 als Modell für ausgedehnte agentische Aufgaben in der Programmierung und Wissensarbeit vor.

In der Ankündigung nennt Anthropic ein Kontextfenster von 1 Million Token, maximal 128.000 Output-Token und adaptives Denken, das standardmäßig aktiviert ist. Das Modell ist in Claude, Claude Code, Claude Platform und bei großen Cloud-Anbietern verfügbar. In den Release Notes zu Claude Code 2.1.280 wird es zudem als Standardmodell der Opus-Reihe bezeichnet, weshalb das Release sofort in CLI-Szenarien auftauchte.

Zum Start lag der Preis bei 4 $ pro Million Input-Token und 20 $ pro Million Output-Token. Bei Opus 5 waren es 5 $ beziehungsweise 25 $, während Cache-Lesezugriffe in Claude Code mit 0,20 $ pro Million Token berechnet wurden. Für einen langlebigen Agenten ist dieser Unterschied wichtiger als eine eindrucksvolle Zahl aus einem einzelnen Benchmark: Die Kosten summieren sich in jedem Zyklus aus Lesen, Denken und Korrigieren.

Anthropic verspricht mehr als 30 % schnellere Ausgabe und etwa 40 % niedrigere typische Aufgabenkosten gegenüber Opus 5. Zu den veröffentlichten Ergebnissen gehören 66,4 % in Terminal-Bench 4.0, 54,4 % in FrontierCode v1.1 und 57,8 % in CursorBench 4.0. Das sind Werte aus den Launch-Unterlagen und kein Ersatz für Tests im eigenen Repository.

Das interessanteste Detail stammt aus einem Nutzerbericht: Das Modell erledigte eine größere Aufgabe in drei Stunden, erzeugte besser lesbaren Code und verbrauchte sein Limit langsamer. Außerdem fügte es eigenständig bedingte console.log()-Ausgaben zum Debuggen hinzu, obwohl es dafür keinen direkten Auftrag gab. Das wirkt weniger wie beschleunigtes Autocomplete und mehr wie die Auswahl der nächsten Engineering-Maßnahme.

Warum Autonomie hier wichtiger ist als Geschwindigkeit

Bei langen Aufgaben besteht die entscheidende Veränderung darin, dass das Modell weniger fortlaufend manuell gesteuert werden muss. Wenn ein Agent ein Problem selbst diagnostiziert, Beobachtbarkeit ergänzt und weiterarbeitet, sinkt nicht nur die Generierungszeit, sondern auch die Zahl menschlicher Eingriffe.

Ein großes Kontextfenster hilft dabei, Codebasis, Entscheidungshistorie und Tool-Ergebnisse in einem Arbeitsprozess zu halten. Ein sparsamerer Umgang mit Limits macht diesen Zyklus praktischer, besonders zusammen mit den zum Start angekündigten erweiterten Fünf-Stunden-Limits für Pro-, Max- und Team-Pläne.

Trotzdem würde ich aus einem gelungenen Projektlauf noch keine allgemeingültige Schlussfolgerung ziehen. Automatisch ergängte Debug-Ausgaben können eine gute Entscheidung sein, aber auch Code überladen oder unnötige Daten offenlegen. Geprüft werden sollten nicht nur das Endergebnis, sondern auch die Zwischenschritte des Agenten.

Opus 5.5 wirkt wie ein echter Fortschritt, wenn sich die behauptete Eigenständigkeit über unterschiedliche Repositories hinweg reproduzieren lässt. Die zentrale Frage lautet nun nicht mehr, ob das Modell Code schreiben kann, sondern wie lange man es arbeiten lassen kann, ohne eingreifen zu müssen.

Wir haben bereits beschrieben, wie parallele Claude-Code-Agenten Pull Requests prüfen und Race Conditions in Entwicklungsabläufen erkennen können. Dieser Praxisfall liefert zusätzlichen Kontext für das autonome Debugging und die schnellere Codegenerierung, die für Claude Opus 5.5 berichtet werden.