Claude Opus 5.5: günstiger pro Token, unbewiesen pro Aufgabe

Ein günstigerer Opus, der einen Teil Ihrer bestehenden Anfragen ablehnt

Claude Opus 5.5 ist Anthropics Ersatz für Opus 5 in derselben Preisklasse, heute angekündigt, nur über die API, ohne Gewichte. Für jeden, der Opus 5 in Produktion betreibt, ändern sich gleichzeitig zwei Dinge, und sie ziehen in unterschiedliche Richtungen.

Das Erste ist die Rechnung. Laut der Tabelle des Herstellers sinkt Input von $5 auf $4 pro Million Tokens, Output von $25 auf $20 und Cache-Reads von $0.50 auf $0.20. Anthropics Ankündigung formuliert die Schlagzeile so:

It costs less per token than Opus 5 and uses fewer tokens per task, which nets out to a 40% drop in costs.

Zwei Behauptungen stecken in diesem Satz. Der Preis pro Token ist ein Fakt, den man aus der Tabelle ablesen kann. Die Tokens pro Aufgabe sind eine Messung, und auf wessen Workload sie gemessen wurde, zählt mehr als der Prozentwert.

Die zweite Änderung ist, dass die API Anfragen nicht mehr akzeptiert, die Opus 5 akzeptierte. Anthropics What's-new-Seite listet vier Breaking Changes: thinking lässt sich nicht deaktivieren, erzwungene Tool-Nutzung liefert einen Fehler, Thinking-Blöcke sind an das Modell und das Gespräch gebunden, und das ältere Computer-Use-Tool computer_20251124 wird auf der Claude API und Google Cloud nicht mehr akzeptiert.

Die ersten beiden sind die, auf die die meisten Opus-5-Integrationen stoßen werden. Jede Anfrage, die thinking: {"type": "disabled"} oder ein manuelles Thinking-Budget sendet, erhält einen 400er. Jede Anfrage, die tool_choice mit any oder einem benannten Tool sendet, erhält einen 400er. Die vom Hersteller empfohlenen Ersatzlösungen sind der Parameter effort für den ersten Fall und tool_choice: auto mit Strict Tool Use oder Structured Outputs für den zweiten. Wenn Sie einen Tool-Call erzwungen haben, um schema-gültiges JSON zu bekommen, ist das eine Code-Änderung, keine Konfigurationsänderung.

Eine fünfte Änderung lässt nichts fehlschlagen und ist leichter zu übersehen:

text between tool calls comes back in thinking blocks

Bei der Standardeinstellung von display haben diese Blöcke leeren Text, sodass eine Anwendung, die den Nutzern die Fortschrittsnotizen des Modells streamt, zwischen Tool-Aufrufen verstummt — ohne Fehler, den man abfangen könnte.

Die Kostenaussage und der Effort-Standardwert stehen im selben Satz

Der Auslöser ist das Release, und was es dringlich macht: Für einen guten Teil der Opus-5-Integrationen ist die Migration nicht optional, wie es bei einem neuen Modell sonst meist der Fall ist. Die Seite des Herstellers selbst sagt, Code, der schon mit eingeschaltetem Thinking auf Opus 5 läuft, brauche keine Änderung. Code, der mit deaktiviertem Thinking läuft, einen Tool-Call erzwingt, das ältere Computer-Use-Tool nutzt oder den früheren Kontext eines Gesprächs bei einem seit dem 31. August angelegten Account bearbeitet, lässt sich nicht einfach auf Opus 5.5 umbiegen und unverändert weiterbetreiben. Wer Opus 5 nutzt, muss sich entscheiden, und das Argument des Herstellers für ein Ja lautet Kosten.

Die Einschränkung zu diesem Argument steht auf derselben Seite wie die Schlagzeile:

at default settings it will cost 40% less than Opus 5 on typical workloads

„Default settings“ leistet mehr Arbeit, als es aussieht. Anthropics Effort-Dokumentation sagt, Opus 5.5 falle standardmäßig auf medium Effort zurück, wo Opus 5 standardmäßig auf high lief:

a request that omits effort runs one level lower than it did on Claude Opus 5

Die 40%-Zahl des Herstellers vergleicht also Opus 5.5 bei medium mit Opus 5 bei high. Das ist ein legitimer Vergleich der Standardwerte. Es ist kein Vergleich desselben Effort-Levels, und der eigene Prompting-Leitfaden des Herstellers beschreibt, was passiert, wenn man den Effort konstant hält:

At a given level, Claude Opus 5.5 tends to think more per turn than Claude Opus 5, especially at xhigh and max.

Legt man diese beiden Zeilen übereinander, bekommt die Migration eine Form. Migrieren Sie und übernehmen den neuen Standardwert, laufen Sie ein Effort-Level niedriger als zuvor — auf einem Modell, das laut Hersteller auf diesem Level stärker ist. Migrieren Sie und behalten Ihren alten Opus-5-Effort-Wert, sagt Ihnen der Hersteller selbst, dass Sie längere Turns und mehr Output-Tokens erwarten sollten, bei einem Preis pro Token, der nur 20% niedriger ist. Die 40% gelten für den ersten Weg. Für den zweiten behauptet die Ankündigungsseite nichts dergleichen.

Drei unabhängige Berichte, und niemand hat den Standardwert getestet

Der stärkste Beleg des Herstellers für die Kosten pro Aufgabe ist ein Diagramm, und der Hersteller hat es mit beschrifteten Achsen veröffentlicht.

Nach Anthropics eigener Darstellung schlägt Opus 5.5 mit Standard-Effort Opus 5 mit max-Effort auf Terminal-Bench 4.0 für rund ein Fünftel der Kosten pro Versuch. Das ist der Benchmark des Herstellers, das sind die Läufe des Herstellers, und es ist das Diagramm des Herstellers — die stärkste Version seines Arguments, weil es pro Versuch gilt und nicht pro Token. Die Ankündigung nennt außerdem rund zwei Dutzend Launch-Partner, die von guten Ergebnissen berichten. Das ist Material des Herstellers. Keiner von ihnen hat eine Token-Zahl veröffentlicht.

Drei Parteien außerhalb von Anthropic haben am Launch-Tag etwas veröffentlicht. Keine davon ist ein direkt vergleichbarer Test der Default-Settings-Behauptung des Herstellers, und jede zeigt etwas Engeres, als die Schlagzeile suggeriert, die sie üblicherweise bekommt: einen pipelineweiten Token-Anstieg gegenüber einem Produktions-Mix, eine Anfrage, die bei max das Output-Limit erreichte, und einen Max-gegen-Max-Indexlauf.

CodeRabbit hat Opus 5.5 in seiner Code-Review-Pipeline laufen lassen und in jeder Konfiguration höheren Token-Verbrauch gemeldet: +49.2% und +57.6% bei 80 Open-Source-Bug-Patterns, +40.6% und +60.1% bei 13 schwierigeren Fällen. Zwei Bedingungen gehören zu diesen Zahlen dazu. Die Baseline ist CodeRabbits eigener Produktions-Modell-Mix, nicht Opus 5, und „Standard“ und „Max“ sind seine pipelineweiten Konfigurationen, keine API-Effort-Werte. Den ersten Punkt benennt CodeRabbit selbst:

The token increase is also a different comparison from the price reduction relative to Opus 5.

Die Zahlen stammen aus einer Laufzusammenfassung, die Input- nicht von Output-Tokens trennt, und sie belegen weder Dollarkosten noch Latenz. Der Beitrag sagt nicht, ob CodeRabbit vorab Zugriff hatte. Was er sagt, ist, wo die Beweislast liegt:

Its efficiency remains an open question, so teams should verify whether its lower token prices actually translate into lower production-review costs.

Es ist keine feindselige Bewertung. Der Grund, den derselbe Beitrag nennt, um das Modell auszuprobieren, ist Fähigkeit, nicht Preis:

The strongest reason to try Opus 5.5 is that it finds a different mix of bugs.

Simon Willison stieß an das andere Ende des immer aktiven Thinkings. Bei der Bitte um ein SVG mit max-Effort:

it hit the limit of 128,000 cap for output tokens while it was still reasoning about the question!

So that failed attempt on max cost me $2.56.

Das ist dokumentiertes Verhalten, kein Bug. Anthropics Effort-Seite rät:

set a large max_tokens at the higher levels: it's a hard limit on total output (thinking plus response text)

Und der Migrationsleitfaden bestätigt, dass das Limit bei 128k geblieben ist. Bei Opus 5 konnten Sie Thinking abschalten und diese Obergrenze damit irrelevant machen. Bei Opus 5.5 geht das nicht, sodass eine Anfrage auf den höchsten Effort-Levels ihr gesamtes Budget mit Nachdenken verbrauchen und nichts zurückliefern kann — und Sie zahlen fürs Nachdenken.

Artificial Analysis hat seinen Intelligence Index auf beiden Modellen mit max-Effort laufen lassen, bei Opus 5.5 mit aktiviertem Fallback. Am Launch-Tag abgerufen, lauten die beiden Seiten:

When evaluating the Intelligence Index, it generated 260M tokens, which is very verbose in comparison to the median of 88M.

When evaluating the Intelligence Index, it generated 140M tokens, which is very verbose in comparison to the median of 88M.

Opus 5.5 erreichte auf diesem Index 58 gegenüber 51 bei Opus 5, und dieselben Seiten, wie am Launch-Tag gelesen, beziffern den kompletten Lauf auf $8,708.20 gegenüber $7,274.74, oder $5.98 pro Aufgabe gegenüber $5.86. Zwanzig Prozent günstiger pro Token, 86% mehr Tokens, zwei Prozent mehr pro Aufgabe. Zwei Einschränkungen: Das ist max gegen max, es sagt also nichts über den Medium-Effort-Standardwert aus, auf dem die Behauptung des Herstellers beruht, und Fallback war aktiviert, sodass manche Aufgaben von einem anderen Modell beantwortet worden sein könnten. Dieselbe Seite führt die Output-Geschwindigkeit von Opus 5.5 als nicht verfügbar. Anthropics Ankündigung sagt, das Modell erzeuge Output mehr als 30% schneller als Opus 5. Bis heute hat niemand außerhalb von Anthropic das gemessen.

Was niemand Unabhängiges getestet hat: der Default-Settings-Vergleich selbst, Opus 5.5 bei medium gegen Opus 5 bei high auf einer echten Workload. Das ist die eine Messung, die die Zahl des Herstellers klären würde, und es ist die, die Sie selbst durchführen können.

Es gibt noch eine Uneinigkeit, und sie besteht zwischen zwei Seiten von Anthropic selbst. Die Ankündigung beschreibt die neuen Safeguards zu Cybersicherheit, Biologie und Distillation als

all of which fall back to another model transparently

Die refusals-and-fallback-Dokumentation nennt Opus 5.5 in ihrem ersten Satz und beschreibt dann etwas, das der Aufrufer selbst einrichten muss. Eine Ablehnung ist kein Fehler:

When that happens, you receive a normal response, not an error, with stop_reason: "refusal".

Eine Antwort von einem anderen Modell zu bekommen bedeutet, sich aktiv für eine von drei Routen zu entscheiden: Server-seitiges Fallback, SDK-Middleware oder ein selbst geschriebener Retry. Zur ersten sagt dieselbe Seite:

Server-side fallback is in beta on the Claude API.

Weiter heißt es, der Parameter fallbacks werde von der Message Batches API nicht unterstützt und sei auf Amazon Bedrock, Google Cloud oder Microsoft Foundry nicht verfügbar, wo stattdessen die SDK-Middleware die Route ist. Auch die Abrechnung ist festgehalten:

An attempt that declined before producing any output is not billed: its tokens are reported on its usage.iterations entry but not charged.

Jeder Versuch, der tatsächlich Output erzeugte, einschließlich eines, der mittendrin ablehnte, wird zu den Sätzen des Modells abgerechnet, das ihn ausführte, und usage.iterations ist der Datensatz pro Versuch. Läuft ein Fallback, nennt die Antwort das Modell, das sie geliefert hat. „Transparently“ bedeutet also sichtbar, nicht automatisch. Eine Pipeline, die sich für nichts davon entscheidet und nur auf Fehler prüft, liest eine Safeguard-Ablehnung als erfolgreichen Aufruf ohne Antwort darin.

Tokens pro abgeschlossener Aufgabe messen, dann entscheiden

Die Migration ist eine Aufgabe aus zwei Teilen, und die Reihenfolge zählt. Machen Sie zuerst die Anfragen gültig: Entfernen Sie das Feld thinking, ersetzen Sie erzwungenes tool_choice durch auto plus Strict Tool Use oder Structured Outputs, wechseln Sie zum neueren Computer-Use-Toolset, falls Sie eines nutzen, und setzen Sie display auf updates, wenn Sie zwischen Tool-Aufrufen streamen. Setzen Sie effort explizit, statt den neuen Standardwert versehentlich zu übernehmen, und setzen Sie max_tokens auf den oberen Levels hoch genug, damit das Nachdenken Platz hat.

Bevor irgendetwas davon in Produktion geht, führen Sie dann den Vergleich durch, den die eigene Effort-Seite des Herstellers empfiehlt: einen Effort-Sweep auf Ihren Evals statt übernommener Einstellungen. Die Zahl, die Sie festhalten sollten, ist nicht der Preis pro Token. Es sind die Gesamt-Tokens, aufgeteilt in Input, Output und Cache-Reads, pro tatsächlich abgeschlossener Aufgabe, auf jedem Effort-Level, mit Ihren Prompts. Cache-Reads zählen mehr, als es aussieht: Anthropic sagt, sie machten den Großteil der Kosten für Agentic- und Coding-Workloads aus, und sie sind die Zeile, die um 60% gefallen ist — eine cache-lastige Workload kann also besser abschneiden, selbst wenn die Output-Tokens steigen. Eine Workload mit wenig Cache und langem Nachdenken kann schlechter abschneiden. Sie wissen nicht, welche der beiden Sie sind, bevor Sie zählen.

Dieser Vergleich ist ein kleiner Workflow, und genau dafür ist Latenode gebaut, unabhängig davon, ob das getestete Modell die eigentliche Pointe ist. Nehmen Sie die dreißig Prompts, die Ihr Produkt tatsächlich verschickt, führen Sie jeden durch zwei Konfigurationen — Opus 5 mit dem Effort, den Sie heute nutzen, und Opus 5.5 mit medium — und lassen Sie einen JavaScript-Node, der jede beliebige NPM-Bibliothek installieren kann, beide Aufrufe über das Vendor-SDK machen und für jeden Input-Tokens, Output-Tokens, Cache-Reads und Wall-Clock-Zeit protokollieren. Ein bezahlter Plan enthält 5 parallele Execution Worker, sodass der Sweep bei einer Concurrency läuft, die in etwa der entspricht, die Sie bedienen, statt einen Prompt nach dem anderen abzuarbeiten. Der Zähler spielt beim Experiment mit: Latenode berechnet die CPU-Sekunden, die ein Lauf tatsächlich verbraucht, nicht pro Node oder pro API-Aufruf und ohne Mindestzeit pro Ausführung, sodass ein paar Hundert kurze Vergleichsläufe die Sekunden kosten, die sie brauchen. Die Rechnung, auf die es ankommt, ist die Modellrechnung, und der Sweep existiert, um diese Zahl zu liefern, bevor Sie sich festlegen.

Migrieren Sie diese Woche, wenn Ihre Workload cache-lastig ist und Sie zählen können

Migrieren Sie jetzt, wenn drei Dinge zutreffen: Sie betreiben Opus 5 mit eingeschaltetem Thinking, Ihr Traffic ist Agentic- oder Coding-Arbeit, bei der Cache-Reads dominieren, und Sie haben eine Möglichkeit, Tokens pro abgeschlossener Aufgabe vorher und nachher zu messen. In diesem Fall erledigt die Preistabelle des Herstellers den Großteil der Arbeit von selbst, der Standard-Effort-Rückgang ist ein Bonus, den Sie annehmen oder ablehnen können, und die Breaking Changes kosten Sie einen Nachmittag. Nehmen Sie zuerst medium. Steigern Sie nur, wenn Ihre Evals es nahelegen.

Migrieren Sie diese Woche nicht, wenn eines davon zutrifft. Sie betreiben Opus 5 mit deaktiviertem Thinking: Diese Konfiguration existiert nicht mehr, und der nächstliegende Ersatz ist ein niedrigeres Effort-Level, das Sie noch nicht kalibriert haben. Sie erzwingen Tool-Calls, um gültiges JSON zu bekommen: Dieser Pfad ist weg, und der Ersatz braucht Tests. Sie laufen auf xhigh oder max: Die einzigen unabhängigen Messungen an diesem Ende zeigen mehr Tokens, und die 128k-Obergrenze schließt jetzt Nachdenken ein, das Sie nicht abschalten können. Ihr API-Account wurde am oder nach dem 31. August 2026 angelegt, und Ihre Pipeline bearbeitet den System-Prompt oder die Tools mitten im Gespräch: Preserved Thinking lehnt den Replay ab. Ihr Traffic berührt Security-Tooling oder Biologie: Eine Safeguard-Ablehnung kommt als normale Antwort mit einem Refusal-Stop-Reason zurück, nicht als Fehler, und eine Antwort von einem anderen Modell zu bekommen bedeutet, sich für eine Fallback-Route zu entscheiden, von denen die server-seitige nur in Beta auf der Claude API verfügbar ist und nicht auf Batches oder den Cloud-Plattformen angeboten wird. Bauen Sie den Retry, bevor Sie ihn brauchen.

Und migrieren Sie nicht wegen der 40%. Das ist die Zahl des Herstellers für seine eigenen Workloads bei seinen eigenen Standardwerten, und heute hat niemand außerhalb des Herstellers sie an irgendetwas reproduziert. Die erste unabhängige Messung des Default-gegen-Default-Vergleichs auf einer Produktions-Workload wird mehr wert sein als jeder Benchmark auf der Ankündigungsseite. Bis es sie gibt, entscheidet über Ihre Migration die Zahl, die Sie selbst erzeugen.