Claude 5.5: Schluss mit Zahlungen für fehlgeschlagene Aufgaben

Das Sonnet- und Opus-Setup, das wirklich zählt: Effort, Cache, Verifizierung und Kosten pro abgeschlossener Aufgabe

Das günstigste Modell ist nicht das mit dem niedrigsten Token-Preis.

Es ist das, das die Aufgabe abschließt, den Check besteht und dich nicht fünfmal für denselben Kontext bezahlen lässt.

Bei Sonnet 5.5 und Opus 5.5 wird dieser Unterschied ungewöhnlich wichtig. Das eine ist auf Volumen ausgelegt. Das andere auf härtere Arbeit. Beide haben ein neues Effort-Verhalten, und beide können in einem gut gecachten Agent-Loop überraschend günstig sein.

Kopierst du deine alte Config einfach in eines der Modelle, kann das Ergebnis langsamer, teurer oder ein 400-Fehler sein.

Dieses Setup würde ich stattdessen bauen:

1AUFGABE → SONNET 5.5 → CHECK → OPUS 5.5 FALLS NÖTIG → VERIFIZIERTES ERGEBNIS
2             ↘ effort ↗         ↘ cache + usage ledger ↗

Ich veröffentliche auf Substack praxisnahe Analysen zu KI-Agenten, Workflows und Produktionssystemen.

Hier geht's zum Newsletter

Die Kennzahl, die über deinen Stack entscheiden sollte

Die meisten Modellvergleiche starten beim Preis pro Million Tokens.

Dein Agent liefert aber keine Tokens aus. Er liefert fertige Aufgaben.

https://x.com/claudeai/status/2102435511222890900

Nochmal: deren Tests. Deine Architektur braucht deine eigenen Zahlen.

Das heißt: Der Check darf kein vages „Sieht gut aus“ nach einer beeindruckenden Antwort sein. Beim Coden nimmst du den Test, der den Merge blockieren würde. Bei Extraktionen vergleichst du Pflichtfelder mit einem gelabelten Datensatz. Bei Recherchen protokollierst du, ob die zitierte Quelle jede Behauptung tatsächlich stützt. Rechne auch die Kosten für Aufgaben ein, die nie bestehen – nicht nur die hübschen Beispiele aus deiner Demo.

Und schau dir das harte Ende der Verteilung separat an. Wenn die günstigste Einstellung 90 % deiner Requests abdeckt, aber die Hälfte des Budgets für die restlichen 10 % verbrennt, kann der Durchschnitt den Teil des Workflows verschleiern, der ein anderes Modell braucht.

Was die 5.5-Preisliste wirklich aussagt

Stand 3. Oktober 2026, bei den Standardpreisen der Claude API, pro Million Tokens:

1SONNET 5.5
2Fresh input  $2       Output  $10
3Cache read   $0.20    Cache write  $2.50 / 5m, $4 / 1h
4
5OPUS 5.5
6Fresh input  $4       Output  $20
7Cache read   $0.20    Cache write  $5 / 5m, $8 / 1h

Beide Modelle haben ein Kontextfenster von 1M Tokens und einen maximalen Output von 128K Tokens. Das sind Obergrenzen, kein Grund, sie voll auszureizen.

Modellspezifikationen und Preise

Die auffällige Zeile ist Cache Read.

Opus kostet bei frischem Input und Output doppelt so viel, aber ein gecachter Präfix kostet bei beiden Modellen dieselben 0,20 $ pro Million. Das macht einen Opus-Lauf nicht genauso günstig: Für neuen Input, Output und Cache Writes zahlst du weiterhin mehr. Es bedeutet aber, dass der Preisunterschied in Sessions mit vielen Lesezugriffen schrumpfen kann.

Da ist noch ein zweiter Unterschied, den viele übersehen. Anthropics „40 % günstiger als Opus 5“ ist eine Schätzung der typischen Laufkosten. Die Preise für frische Tokens von Opus 5.5 sind um 20 % gefallen; der Preis für Cache Reads um 60 %. Diese Zahlen hängen zusammen, sind aber nicht austauschbar.

Effort ist eine Routing-Entscheidung, kein Qualitätsregler

Sonnet 5.5 unterstützt low, medium, high, xhigh und max. Über die API ist standardmäßig high eingestellt, in den Claude-Apps laut Anthropic medium. Opus 5.5 nutzt über die API standardmäßig medium. Diese Stufen bedeuten nicht exakt dasselbe wie die gleichnamigen Begriffe bei den Vorgängermodellen.

Meine Ausgangsbasis:

• Sonnet low: Für enge, latenzkritische Requests mit einem günstigen Check
• Sonnet medium: Für klar definiertes Coding und routinemäßige Multi-Step-Aufgaben
• Sonnet high: Wenn der Medium-Lauf einen echten Check nicht besteht oder die Aufgabe ein nachweislich komplexes Muster hat
• Opus medium: Für mehrdeutige, dateiübergreifende Aufgaben mit langem Horizont, bei denen Sonnet nur um das Problem herumkreist
• Xhigh/max: Erst wenn deine Evals zeigen, dass sich der Gewinn die zusätzliche Zeit und die Tokens lohnt

Das ist eine Anfangshypothese, keine universelle Hierarchie. In Anthropics veröffentlichten FrontierCode-Ergebnissen für Sonnet 5.5 lag xhigh vor max. Mehr Aufwand ist kein Beweis für ein besseres Ergebnis.

Anthropics Fußnote erklärt das kontraintuitive Resultat: Bei max startete das Modell häufiger zusätzliche Code-Review-Schleifen. In zwei untersuchten Fällen führte das zu einem Timeout oder zu Änderungen außerhalb des Aufgabenbereichs.

Der Fehler war also nicht „das Modell hat zu wenig nachgedacht“. Es hat den Aufwand an der falschen Stelle investiert. Wenn dein Agent seine Checks bereits besteht, können zusätzliche Review-Runden schnell Kosten verursachen und neue Fehler produzieren.

https://x.com/edwinarbus/status/2104675431853248816

Setz außerdem max_tokens nicht einfach niedrig und nenn das Optimierung. Das Limit umfasst Thinking und sichtbaren Output. Kürzt du es mitten in der Aufgabe, kaufst du dir statt einer Ersparnis eine abgeschnittene Antwort und einen zweiten Lauf.

https://x.com/claudeai/status/2104633115620823187

Das ist ein starkes Launch-Versprechen. Eine Produktionskonfiguration muss trotzdem deine eigene Baseline schlagen.

Mach einen kleinen Sweep, bevor du einen Model Router erfindest

Nimm 10–30 Aufgaben, die dir wirklich wichtig sind. Pack leichte Arbeit rein, mehrdeutige Arbeit und die nervigen Fehler aus deinen Logs. Gib jeder Aufgabe einen Verifier: Tests, einen strukturierten Vergleich, eine bekannte Antwort oder eine menschliche Bewertungsgrundlage, die vor dem Lauf festgelegt wurde.

Hier ist der kleinste sinnvolle API-Probe-Call. Er loggt genau die Usage-Felder, die du brauchst. Führe ihn für jedes Modell und jede Effort-Stufe gegen dieselbe Aufgabe aus und häng dann deinen eigenen Pass/Fail-Check dran. Ein vollständiger Agent-Benchmark ist das nicht.

1import anthropic
2
3client = anthropic.Anthropic()
4response = client.messages.create(
5    model="claude-sonnet-5-5",  # repeat with claude-opus-5-5
6    max_tokens=8192,
7    output_config={"effort": "medium"},  # repeat at high
8    messages=[{"role": "user", "content": "Replace this with a real task."}],
9)
10
11answer = "".join(b.text for b in response.content if b.type == "text")
12usage = response.usage
13print(answer)
14print("fresh", usage.input_tokens, "output", usage.output_tokens)
15print("cache read", usage.cache_read_input_tokens)
16print("cache write", usage.cache_creation_input_tokens)

Das setzt das offizielle Anthropic-Python-Package und eine Umgebungsvariable ANTHROPIC_API_KEY voraus. Es ist ein isolierter Aufruf ohne aktiviertes Caching, daher sollten Cache Reads und Writes bei null liegen. Im nächsten Abschnitt siehst du, was das ändert.

Für einen echten Agenten summierst du die Usage über alle API-Calls unter einer Task-ID, inklusive Retries und Tool-Aufrufen. Zähle einen Pass nur, wenn der Verifier sagt, dass die Aufgabe erledigt ist.

Vergleiche die Gesamtkosten in Dollar pro Pass, bevor du deinen Standard festlegst.

Halte den Test ehrlich:

• Friere den Aufgabensatz und den Verifier ein, bevor du Configs vergleichst
• Nutze für jeden Kandidaten dieselben Tools, Berechtigungen, Kontexte und Output-Anforderungen
• Protokolliere Pass-Rate, Gesamtkosten, Kosten pro Pass, Latenz sowie die längsten oder teuersten Fehlschläge
• Werten stop_reason: "max_tokens" als unvollständigen Versuch, nicht als billigen Erfolg

Das kurze Codebeispiel oben nutzt ein 8K-Output-Limit für einen Single-Turn-Probe-Call. Kopiere dieses Limit nicht in einen langen Coding-Agenten.

Anthropic empfiehlt für agentische Aufgaben deutlich mehr Spielraum, weil verstecktes Thinking auf dasselbe Limit einzahlt.

Setze das Limit passend zur Aufgabe und steuere die Kosten dann über Effort, Caching und ein Task-Budget – statt die Antwort mitten in der Arbeit abzuschneiden.

Cache den stabilen Teil der Arbeit

Agenten senden immer wieder dieselben Systemanweisungen, Tool-Definitionen, Repository-Maps und vorherigen Konversationen. Ist dieser Präfix stabil, verändert Prompt Caching die Wirtschaftlichkeit stärker als ein kleines Prompt-Rewrite.

Ein Beispiel: 200K gecachte Tokens, die 50-mal gelesen werden, sind 10M Cache-Read-Tokens. Bei 0,20 $ pro Million kosten diese Reads bei beiden 5.5-Modellen 2 $.

Bei Opus 5.5 würden dieselben 10M Tokens als frischer Input 40 $ kosten. Der erste Cache Write für 200K Tokens (fünf Minuten Gültigkeit) schlägt mit weiteren 1 $ zu Buche.

Das ist nur eine Illustration der Präfix-Kosten: Neuer Input, Output, weitere Writes, TTL-Ablauf und tatsächliche Cache Misses kommen auf die Rechnung.

Die praktischen Regeln:

• Aktiviere Prompt Caching bei der Claude API über cache_control={"type": "ephemeral"} auf oberster Ebene oder über explizite Cache-Breakpoints. Der Probe-Call oben tut beides nicht, weshalb seine Cache-Zähler normalerweise bei null bleiben.
• Platziere stabile Anweisungen und Tools vor der sich ändernden User-Anfrage.
• Halte den gemeinsamen Präfix über alle Turns hinweg identisch; prüfe die tatsächlichen cache_read_input_tokens.
• Behandle einen Modellwechsel wie ein neues Konversationsbudget, nicht als kostenlose Fortsetzung. Der Cache gilt pro Modell: Ein Opus-Request kann nicht den Präfix lesen, den Sonnet gerade gecacht hat.
• Vermeide es, den Top-Level-Effort bei jedem Turn zu ändern; das verändert den gerenderten Prompt und invalidiert gecachte Präfixe.

Bei unterstützten Modellen kann eine Änderung des Efforts pro Nachricht den bisherigen Cache erhalten, erfordert aber Anthropics Beta-Header und ist nicht dasselbe wie eine Änderung von output_config auf oberster Ebene.

Sonnet 5.5 hat zudem eine Einschränkung bei between_tools: In diesem Modus kann der Effort mitten in der Konversation nicht geändert werden.

Dokumentation zu Prompt Caching

Schließe nicht aus einer schnellen Antwort auf einen Cache Hit. Lies das Usage-Objekt. Es trennt frischen Input, Cache-Erstellung und Cache Reads sauber auf.

Beide 5.5-Modelle brauchen mindestens 512 Tokens in einem cachefähigen Präfix. Ein winziger System-Prompt bringt nicht die Ersparnisse aus dem Beispiel oben. Die Standard-Lebensdauer des Caches liegt bei fünf Minuten – perfekt für schnelle Tool-Loops.

Ein Write für eine Stunde kostet mehr und lohnt sich nur, wenn echte Sessions oft lange genug pausieren, um das Fünf-Minuten-Fenster zu verpassen. Miss diese Pausen, bevor du für die längere TTL bezahlst.

Eskaliere nach Beweisen, nicht aus Panik

Die meisten Teams bauen den Router falsch herum: Sie stufen eine Aufgabe als „schwer“ ein, schicken sie ans teure Modell und erfahren nie, ob der billigere Weg gereicht hätte.

Nutze den Verifier als Routing-Signal.

11  Sonnet 5.5 · gewählter Effort  → Aufgabe ausführen
22  Verifier                       → akzeptieren, wenn bestanden
33  Opus 5.5 · medium              → Retry nur mit Nachweis des Scheiterns
44  Verifier                       → akzeptieren oder mit Nachweis weitergeben

Der Check kann eine Testsuite, Schema-Validierung, eine bekannte Antwort oder ein Reviewer sein. Er sollte erklären, was fehlgeschlagen ist.

„Die Antwort fühlt sich schwach an“ ist ein schlechtes Eskalationssignal. „Der geänderte Endpoint fällt bei zwei Integrationstests durch“ ist hilfreich.

Wiederhole nicht blind denselben Prompt. Gib dem nächsten Versuch den fehlgeschlagenen Check, die relevanten Artefakte und eine konkrete Anweisung, die Lücke zu schließen. Deckele die Eskalationsleiter, damit ein Agent nicht sein Budget verbrennt, während er versucht, eine Aufgabe zu lösen, die eine menschliche Entscheidung braucht.

Einen Sonnet-High-Retry kannst du in deinem Offline-Sweep testen. Behalte ihn nur im Live-Routing, wenn er die Kosten pro verifizierter Aufgabe senkt. Es gibt keinen Grund, jeden Fehlschlag erst zwei Sonnet-Läufe kosten zu lassen, bevor Opus drankommt.

Der Modellwechsel selbst kann einen gecachten Präfix zerstören. Berücksichtige das, wenn du den Rettungsweg mit einer Opus-First-Route vergleichst.

Den Break-even übersieht man leicht. Angenommen, ein Sonnet-Versuch kostet 0,06 $ und besteht 80 % deiner Aufgaben.

Wenn jede gescheiterte Aufgabe dann 0,20 $ kostet, um auf Opus abgeschlossen zu werden, liegt dein theoretischer Durchschnitt bei 0,10 $ pro fertiger Aufgabe: 0,06 $ plus eine 0,20 $-Rettung bei jeder fünften Aufgabe. Das ist besser, als für jede Aufgabe 0,20 $ an Opus zu zahlen. Kostet Sonnet aber 0,14 $ und besteht nur die Hälfte, kostet dieselbe Leiter 0,24 $ – noch bevor du den Modellwechsel einpreisst. In diesem Workload ist Opus-First günstiger und schneller.

Diese Zahlen sind Beispiele, keine gemessenen Claude-Ergebnisse. Ihr Zweck ist es, die Routing-Regel widerlegbar zu machen. Die Leiter hat ihre Daseinsberechtigung nur, wenn die eingesparten Opus-Calls die fehlgeschlagenen Sonnet-Versuche, Cache Misses und die zusätzliche Latenz aufwiegen.

Es gibt auch einen Mittelweg: Anthropics Beta Advisor Tool. Sonnet kann die Aufgabe weiter ausführen und Opus bei einer schwierigen Entscheidung um Hilfe bitten, statt den gesamten Job an Opus abzugeben.

Das ist nicht automatisch billiger. Logge, wie oft Sonnet den Advisor tatsächlich konsultiert, was diese Calls kosten und ob sie die finale Pass-Rate verbessern. Fragt der Executor selten nach, ist der Advisor nur ein ungenutztes Feature.

Bei diesen 5.5-Modellen wird der Rat selbst verschlüsselt an den Client zurückgegeben. Bewerte also die resultierende Arbeit, statt so zu tun, als könntest du den privaten Beratungstext prüfen.

Vier Lecks, die die Rechnung treiben, bevor die Modellwahl überhaupt zählt

Nicht jedes Kostenproblem braucht einen neuen Router.

Prüfe zuerst das hier:

• Output, der immer weiter wächst: Bei beiden 5.5-Modellen kosten Output-Tokens fünfmal so viel wie frische Input-Tokens. In einer Konversation kann eine lange Antwort in späteren Turns als Kontext zurückkehren. Fordere das Artefakt und eine kurze Abschlussnotiz an, kein erzähltes Protokoll jedes einzelnen Schritts. Verstecktes Thinking wird ebenfalls als Output abgerechnet, daher löst eine knappe finale Antwort allein kein Effort-Problem. Unterdrücke aber nicht die Belege, die du zur Verifizierung brauchst.
• Bilder, die größer sind als nötig: Sonnet 5.5 kann höher aufgelöste Bilder verarbeiten als ältere Sonnet-Versionen, was die Image-Token-Zahlen erhöhen kann. Braucht der Agent nur einen Button-Text oder einen Absatz, croppe oder skaliere vorher. Braucht er ein dichtes Diagramm oder winzige UI-Details, behalte die Auflösung bei und miss die Kosten, statt blind zu verkleinern.
• Kontext, den niemand nutzt: Tool-Definitionen, veraltete Logs, alte Suchergebnisse und eine ausufernde CLAUDE.md können jeden Request begleiten. Pack dauerhafte Regeln in einen kurzen, stabilen Präfix; halte flüchtige Belege nah an der Aufgabe, die sie braucht. Kontext zu kürzen darf keine Fakten löschen, die das Modell für einen korrekten Abschluss noch benötigt.
• Interaktive Preise für Arbeit, auf die niemand wartet: Die Message Batches API gibt bei beiden Modellen 50 % Rabatt auf Input und Output. Das ist nützlich für Offline-Evaluierungen, Dokumenten-Backfills und andere asynchrone Jobs. Es ersetzt keinen Live-Tool-Loop, bei dem jemand sofort den nächsten Schritt braucht.

Das Muster ist bei allen vier gleich: Streich Arbeit, die die Aufgabe nicht braucht, bevor du mehr Intelligenz einkaufst oder den Effort so weit senkst, bis die Qualität einbricht.

Die Migrationsfallen, die aus einer Ersparnis einen 400-Fehler machen

Alte Request-Bodies sind ein schlechter Startpunkt für die 5.5-Familie.

Besonders wichtig:

• Opus 5.5 Thinking ist immer an: Entferne thinking: {"type": "disabled"} und alte feste budget_tokens-Einstellungen; steuere die Tiefe über output_config.effort.
• Erzwungene Tool-Wahl schlägt bei beiden 5.5-Modellen fehl.

Die tool_choice-Werte any und tool liefern einen 400-Fehler. Nutze auto, gib an, wann das Tool verwendet werden soll, und validiere das Tool-Ergebnis in deinem eigenen Code.

• Thinking Blocks sind keine Text Blocks: Lies Content nach type, nicht über content[0]. Gib in Tool-Loops Thinking Blocks unverändert mit dem Assistant-Turn zurück.
• Deine UI wirkt möglicherweise still: Bei Opus 5.5 kann der Fortschritt zwischen Tools in Thinking Blocks ankommen, die bei der Standardanzeige leer sind. Hast du solche Notizen bisher für Nutzer gerendert, fordere einen unterstützten Thinking-Display-Modus an und rendere Blocks nach Typ. Sonst arbeitet der Agent vielleicht, während das Interface eingefroren wirkt.
• Alte Versionen des Computer-Use-Tools können fehlschlagen: Prüfe vor der Migration eines Browser-/Computer-Agenten die aktuelle Tool-Version.
• Ein kleineres max_tokens-Limit kann Arbeit abschneiden.

Thinking zählt mit, selbst wenn der Text versteckt ist.

Das sind Änderungen im API-Verhalten, keine Prompt-Tricks.

Opus-Migrationsleitfaden und Sonnet-Migrationsleitfaden

Pack den Vertrag in Claude Code, nicht in deinen Kopf

Über die API kannst du jedes Usage-Feld messen. In Claude Code werden viele die Modelländerung zuerst spüren. Das Prinzip bleibt gleich: Gib dem Agenten eine begrenzte Definition von „fertig“ und lass ihn dann die Beweise zeigen.

In Claude Code wählt /model das Modell und /effort die unterstützte Effort-Stufe. Prüfe die aktiven Einstellungen, bevor du Sessions vergleichst. Der Sonnet-API-Standard beschreibt nicht zuverlässig, was deine Claude-App oder deine Claude-Code-Session gerade nutzt.

Hier ist ein vollständiger, wiederverwendbarer Startblock für CLAUDE.md. Passe die Befehle an dein Projekt an.

1# Arbeitsvertrag
2
3Nimm nur die angeforderte Änderung vor. Lass Unbeteiligtes unberührt.
4Führe nach dem Bearbeiten die relevanten Tests aus. Melde jeden Check, den du nicht ausführen kannst.
5Stoppe, sobald die angeforderte Arbeit besteht. Füge keine zusätzlichen Features oder Review-Schleifen hinzu.
6Ende mit: Geändert / Verifiziert / Verbleibendes Risiko.
7Frage vor destruktiven Aktionen, Veröffentlichungen oder Änderungen außerhalb dieses Repositories nach.

Dieser Block macht nicht magisch jeden Lauf billig. Er macht Erfolg und Scheitern sichtbar. Von dort aus kannst du einen Sonnet-First-Workflow mit einem Opus-First-Workflow anhand derselben Aufgaben vergleichen.

Die Task-Nachricht muss trotzdem konkret sein. Hier ist der Unterschied zwischen „Fix den Zahlungscode“ und einem Job, den ein Agent wirklich abschließen kann:

1Änderung: Migriere den Payment-Endpoint zum neuen Client
2Fertig: Alter Client entfernt, Endpoint-Tests bestanden, Diff auf diesen Pfad beschränkt
3Stopp: Vor dem Löschen von Daten oder Änderungen außerhalb des Repos nachfragen
4Bericht: Geänderte Dateien, exakt ausgeführte Checks, verbleibendes Risiko

Dieser kleine Vertrag gibt dem Verifier etwas Konkretes zum Prüfen. Und dem Modell einen Grund aufzuhören. Eine offene Anweisung wie „reviewe, bis es perfekt ist“ kann aus einer bestandenen Änderung eine weitere bezahlte Schleife machen.

Bei langen Projekten hältst du die Checkliste in einer Datei, die eine Compaction überlebt. Bei Subagenten lässt du den Lead-Agent deren Beweise prüfen, bevor du ihre Berichte akzeptierst. Und wenn du nur Ideen wolltest, sag Claude, dass es nicht losbauen soll. Das sind Workflow-Grenzen, keine „Sei schlauer“-Prompts.

Das Setup, das ich zuerst shippen würde

• Wähle 10–30 echte Aufgaben und definiere für jede einen Check
• Mach einen Sweep mit Sonnet 5.5 auf Medium und High, dann mit Opus 5.5 auf Medium
• Logge pro Aufgabe frischen Input, Output, Cache Writes, Cache Reads, Latenz, Retries und Pass/Fail
• Halte den stabilen Präfix cachefähig und bestätige Hits im Usage-Objekt
• Route nur die Fehlschläge nach oben – mit ihren Beweisen im Gepäck
• Überdenke die Leiter neu, wenn sich der Workload ändert. Ein gespeicherter Benchmark ist keine ewige Wahrheit

Wenn die schwierigen 10 % immer wieder direkt vom Sonnet-Fehlschlag zum Opus-Erfolg springen, route diese erkennbare Aufgabenklasse von Anfang an zu Opus. Schafft Sonnet High dieselben Fälle günstiger, lass sie dort. Ein Router ist eine gemessene Policy, keine dauerhafte Meinung darüber, welches Modell klüger ist.

Das 5.5-Upgrade ist nicht einfach „Nimm Sonnet für billige Arbeit und Opus für schwere“.

Es ist die Chance, aufzuhören, das Modell zu bepreisen, und anzufangen, die fertige Aufgabe zu bepreisen.

Wenn du bis hierhin gelesen hast

-> Abonniere meinen Substack

-> Tritt meinem Telegram bei

**-> Speichere diesen Artikel als Lesezeichen

-> Folge @0xwhrrari