Anthropic verknüpft die Preisgestaltung von Claude Opus 5.5 mit längeren Codierungssitzungen

Anthropic berichtete am 24. September 2026, dass Claude Code‑Sitzungen in den letzten sechs Monaten länger und kontextintensiver geworden sind und erläuterte in einem Beitrag im Claude‑Blog, wie die Preis‑ und Caching‑Mechanik von Claude Opus 5.5 auf diese Veränderung reagiert. Das Unternehmen schätzt, dass die Betriebskosten von Opus 5.5 etwa 40 % unter denen von Opus 5 für eine typische tokenbasierte Arbeitslast liegen.

Sechs Monate Claude Code‑Nutzungsdaten

Der Beitrag, verfasst von Michael Segner, stützt sich auf aggregierte Nutzungsdaten von März bis September 2026. Die Anzahl der Eingabeaufforderungen pro Sitzung blieb laut Bericht konstant, während die Arbeit innerhalb jeder Aufforderung zunahm: Das Modell arbeitet nun 3,3 mal länger pro Aufforderung und führt auf jeder mehr als 40 % mehr Modellaufrufe aus, und Unterbrechungen sanken um 68 %. Entwickler verbinden nun etwa doppelt so häufig einen Tool‑Server oder nutzen eine Fähigkeit und fügen Text in Aufforderungen ein Drittel seltener ein.

Der Kontextumfang jeder Anfrage wuchs im Zeitraum um das 2,6‑fache, und das Eingabe‑zu‑Ausgabe‑Token‑Verhältnis verschob sich von 189 : 1 auf 324 : 1. Anthropic interpretiert diese Zahlen so, dass Entwickler ein länger arbeitendes, besser informiertes Modell für größere, offener gestaltete Aufgaben anstreben, und erklärt, dass die Einsparungen von Opus 5.5 gerade bei diesen längeren, kontextreicheren Sitzungen am größten sind, wenn die Nutzung tokenbasiert abgerechnet wird.

Die Analyse baut auf der Veröffentlichung von Claude Opus 5.5 durch Anthropic auf, die zu niedrigeren Preisen als Opus 5 erschien. Während die Markteinführung die Preise festlegte, untersuchen der Beitrag vom 24. September und eine begleitende Analyse, die am 22. September 2026 von Addy Osmani veröffentlicht wurde, was diese Preise für reale Claude Code‑Arbeitslasten bedeuten.

Token‑Preise und der Abschlag für Cache‑Lesevorgänge

Bei tokenbasierter Abrechnung hat Anthropic die Preise für Eingabe‑ und Ausgabetoken um 20 % gesenkt und den Preis für das Lesen eines zwischengespeicherten Tokens um 60 % reduziert. Das Unternehmen erklärt, dass die Reduzierung der Cache‑Lesegebühr am bedeutendsten sei, weil Cache‑Lesevorgänge den größten Teil der Kosten für agentenbasierte und codierende Arbeit ausmachen, und dass ein zwischengespeicherter Token in Opus 5.5 zum Zeitpunkt der Veröffentlichung nur ein Fünftel der Kosten konkurrierender Modelle verursacht und diese übertrifft.

Osmanis begleitende Analyse listet die API‑Listenpreise von Opus 5.5 mit 4 $ pro Million Eingabetoken, 20 $ pro Million Ausgabetoken und 0,20 $ pro Million Cache‑Lesevorgänge auf. Bei diesen Preisen kostet ein Cache‑Lesevorgang 5 % eines frischen Eingabetokens, während das Schreiben in den Cache das 1,25‑fache des Eingabepreises für einen fünfminütigen Cache und das Doppelte des Eingabepreises für einen einstündigen Cache kostet, wobei jeder Treffer die Lebensdauer kostenlos erneuert. In den Pro‑, Max‑ oder Team‑Plänen wird der niedrigere Opus‑5.5‑Preis auf die Plan‑Limits übertragen, sodass sie etwa 25 % weiter reichen als bei Opus 5; der zusätzliche Cache‑Lese‑Rabatt gilt nur für die API‑Preisgestaltung.

Änderungen nutzen, die den Cache schützen

Selbst als der Kontext pro Anfrage etwa um das 2,6‑fache zunahm, sank laut Bericht der Anteil der Eingaben, die den Cache verfehlten, um mehr als 50 % im sechsmonatigen Zeitraum. Dies wird einer Reihe von Claude Code‑Änderungen zugeschrieben, die versehentliche Cache‑Unterbrechungen reduzieren und kleine Störungen wie ein Login‑Refresh sowie größere wie das Hinzufügen von Anweisungen mitten im Gespräch oder das bedarfsorientierte Laden von Tools abdecken. In Opus 5.5 und Fable 5.1 können Entwickler zudem die Aufwand‑Stufen mitten in einer Sitzung ändern, ohne den Cache zurückzusetzen.

Die offizielle Prompt‑Caching‑Dokumentation gibt an, dass das Verhalten der Aufwand‑Stufen mit einem API‑Schlüssel oder einem Claude‑Abonnement gilt, jedoch nicht auf Amazon Bedrock, der Google Cloud‑Agent‑Plattform oder einem Claude‑Apps‑Gateway, noch wenn das CLAUDECODEDISABLEEXPERIMENTALBETAS‑Flag gesetzt ist oder eine Organisation eine HIPAA‑Konfiguration besitzt.

Entwickler mit API‑Schlüsseln und Cloud‑Anbietern können nun eine Cache‑Lebensdauer von einer Stunde festlegen, die Abonnenten bereits hatten. Die Dokumentation zeigt die Vorgaben: eine Stunde für das Hauptgespräch bei einem Claude‑Abonnement innerhalb der Plan‑Nutzung und fünf Minuten für Nutzungsguthaben, API‑Schlüssel oder Cloud‑Anbieter. Die Einstellung promptCacheTtl oder die Umgebungsvariable CLAUDECODEPROMPTCACHETTL wählt die längere Lebensdauer, und beide Steuerungen erfordern Claude Code v2.1.242 oder neuer.

Gespaltene Sub‑Agenten starten nun aus dem Cache der übergeordneten Sitzung, anstatt die erneute Verarbeitung desselben Kontexts zu bezahlen. Die Dokumentation erklärt, dass ein Fork die System‑Prompt, das Tool‑Set und die gesamte Gesprächshistorie des Elternteils übernimmt, sodass seine Eröffnungsanfrage direkt aus dem Cache des Elternteils liest.

Weniger Durchläufe pro Aufgabe

Anthropic berichtet, dass Opus 5.5 eine Aufgabe in weniger Durchläufen als andere Modelle abschließen kann. Laut dem Beitrag verzeichnete Zeta Labs weniger Durchläufe und Tool‑Aufrufe pro Aufgabe als bei Opus 5, bei fast der Hälfte der Kosten, und schloss doppelt so viele seiner schwierigsten Aufgaben ab.

Der Beitrag warnt, dass dieses Muster nicht für jede Aufgabe gilt, und zitiert Osmanis Analyse: “Bei einer gut abgegrenzten Aufgabe beenden beide Modelle etwa die gleiche Anzahl an Durchläufen, und der Preisnachlass ist das Einzige, was Sie erhalten. Die Lücke sollte bei offenen Aufgaben am größten sein, bei denen ein Modell viele Durchläufe mit einer falschen Idee verbringt.”

Anthropic berichtet zudem, dass Opus 5.5 Ausgaben um mehr als 30 % schneller erzeugt als Opus 5. Der Gewinn lässt den Token‑Verbrauch und die Cache‑Trefferquote unverändert; der Beitrag stellt fest, dass er die Wartezeit bei langen Durchläufen verkürzt, da Claude mehr Zeit unbeaufsichtigt arbeitet.

Der Beitrag schließt mit Praktiken zum Schutz von zwischengespeicherten Lesevorgängen ab: Führen Sie /usage in Claude Code aus, um zu sehen, welcher Anteil einer Sitzung aus dem Cache bedient wird, wählen Sie das Modell zu Beginn einer Sitzung, anstatt es mitten im Ablauf zu wechseln, führen Sie die Komprimierung aus, bevor Sie sich zurückziehen, anstatt danach, und aktivieren Sie bei einem API‑Schlüssel oder Cloud‑Anbieter die einstündige Cache‑Lebensdauer für lange Sitzungen.