Claude Opus 4.8 Fast Mode endet am 30. November: Opus 5.5 ist pro Token günstiger, aber nicht immer pro Request

Am 30. Oktober hat Anthropic Fast Mode auf Claude Opus 4.8 als deprecated markiert. Ab dem 30. November 2026 gibt ein Request an claude-opus-4-8 mit speed: "fast" einen Fehler zurück. Die Release Notes zu Claude Code v2.1.316 sagen ausdrücklich, was für alle zählt, die auf einen sanften Rückfall gehofft haben: Der Request fällt nicht auf Standard-Opus 4.8 zurück. Er schlägt fehl.

Das Modell selbst bleibt. claude-opus-4-8 ist als aktiv gelistet, die Abschaltung kommt frühestens am 28. Mai 2027. Es endet nur eine Einstellung dieses Modells, und der offizielle Ausweg ist Opus 5.5, dessen Fast Mode pro Token günstiger ist. Günstiger pro Token und günstiger pro Request sind zwei verschiedene Aussagen, und bei diesem Wechsel können sie in entgegengesetzte Richtungen zeigen.

Was genau hört am 30. November bei Claude Opus 4.8 Fast Mode auf zu funktionieren?

Nur speed: "fast" auf claude-opus-4-8. Requests mit Standard-Speed an dasselbe Modell laufen weiter, ebenso Fast Mode auf Opus 5.5 und, weiterhin als Research Preview, auf Opus 5.

Fast Mode auf 4.8 war immer eine Research Preview hinter dem Beta-Header fast-mode-2026-02-01. Opus 5.5 hat die Preview am 15. Oktober verlassen: kein Header nötig (ihn mitzuschicken funktioniert trotzdem) und ein Standard-Fast-Rate-Limit in den Usage Tiers Start, Build und Scale, du musst also keinen Zugang beantragen. Organisationen im Evaluation Tier bekommen es, sobald sie aufsteigen.

Opus 4.7 hat das schon hinter sich. Sein Fast Mode wurde am 25. Juni deprecated und am 24. Juli entfernt, und speed: "fast" auf 4.7 gibt seitdem einen Fehler zurück. Rechne damit, dass sich 4.8 am 1. Dezember genauso verhält.

Wie findest du die Claude Opus 4.8 Fast-Mode-Calls, die du noch machst?

Aus drei Richtungen, weil jede etwas übersieht. Dein Code zeigt, wo Fast angefordert wird, die Response zeigt, welche Geschwindigkeit du bekommen hast, und die Analytics API zeigt, wer tatsächlich Fast-Traffic schickt, auch die Skripte, die du vergessen hast.

Fang beim Code an. Die Einstellung ist in den meisten Codebases ein Literal oder ein SDK-Enum, und der Beta-Header ist ein guter zweiter Marker, weil Opus 5.5 ihn nicht mehr braucht. Das hier findet die Dict-, YAML- und JSON-Formen plus die Enums in Go, C# und Java:

grep -rnE "fast-mode-2026-02-01|speed[\"']?[[:space:]]*[:=][[:space:]]*[\"']?fast|Speed\.?(Fast|FAST)" \
  --include='*.py' --include='*.ts' --include='*.js' --include='*.go' --include='*.cs' \
  --include='*.java' --include='*.json' --include='*.yaml' --include='*.yml' --include='*.toml' .

Damit findest du die Requests, die „fast“ sagen. Das Modell findest du damit nicht. Eine Model-ID aus einer Umgebungsvariable oder einem Config-Service kann einen Fast-Request auf 4.8 ohne Codeänderung in einen Fast-Request auf 5.5 verwandeln, und umgekehrt. Prüf also auch, wo der Modellname aufgelöst wird.

Zur Laufzeit trägt jede Response usage.speed, entweder "fast" oder "standard". Logge das neben dem Modell. Ein Fast-Request, der mit 429 oder 529 zurückkommt, ist ans Fast-Rate-Limit oder an die Kapazitätsgrenze gestoßen. Mit dem Modell ist alles in Ordnung, und nach dem 30. November scheitert derselbe Request auf 4.8 auf andere Weise.

Für die ganze Organisation hat die Usage and Cost Analytics API (Beta seit dem 29. Oktober und getrennt von der älteren Usage and Cost API) eine speed-Dimension und einen speeds[]-Filter. Sie braucht Admin-Zugangsdaten, für individuelle Accounts geht sie also nicht; dieses Console-Beispiel nutzt einen Admin API Key. Es liefert die API Keys und Produkte, die in den 30 Tagen vor der Veröffentlichung Fast-Traffic an 4.8 geschickt haben (verschieb die Daten auf dein eigenes Zeitfenster, höchstens 31 Tage pro Request):

curl --globoff "https://api.anthropic.com/v1/organizations/analytics/usage?\
starting_at=2026-10-10T00:00:00Z&\
ending_at=2026-11-09T00:00:00Z&\
models[]=claude-opus-4-8&\
speeds[]=fast&\
group_by[]=api_key_id&\
group_by[]=product&\
limit=1000" \
  -H "anthropic-version: 2026-10-21" \
  -H "anthropic-beta: analytics-usage-cost-2026-08-24" \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY"

Das ist die erste Seite. Steht in der Response has_more: true, übergib ihr next_page im nächsten Request als page, bis das nicht mehr der Fall ist.

Beim Lesen der Antwort gibt es zwei Fallen. Ein leeres Ergebnis heißt nicht, dass du sauber bist: In dieser API matcht ein unbekannter oder falsch geschriebener models[]-Wert einfach nichts, statt einen Fehler zu liefern, also produziert ein Tippfehler genau das Ergebnis, auf das du gehofft hast. Führ dieselbe Abfrage einmal mit group_by[]=model und ohne Filter aus und kopier den Modellnamen aus einer Zeile, die zurückkommt.

Und die Daten sind nicht live. Sie werden typischerweise innerhalb von 4 Stunden aktualisiert, manchmal dauert es bis zu 24, und alles nach data_refreshed_at fehlt oder ist unvollständig. Um zu bestätigen, dass eine Migration funktioniert hat, frag die Stunden nach deinem Deploy also erst ab, wenn data_refreshed_at hinter diesen Stunden liegt; ein leeres Fenster, das die Daten noch nicht abdecken, beweist nichts. In der Console bieten die Seiten Usage und Cost dieselbe Aufteilung unter Group by, als „Speed (research preview)“.

Sobald du die Liste der Aufrufer hast, ist die Frage für jeden einzelnen nicht, ob 5.5 Fast pro Token günstiger ist. Das ist es, in jeder Zeile. Die Frage ist, was jeder Request schreibt.

Was kostet Claude Opus 5.5 Fast Mode im Vergleich zu Opus 4.8 Fast Mode?

Weniger, in jeder Zeile der Preisliste. Fast Mode kostet bei beiden Modellen das Doppelte des Standardpreises, und der Standardpreis von Opus 5.5 ist niedriger, also sinkt der Fast-Preis von $10 Input und $50 Output pro Million Tokens auf $8 und $40.

Die Cache-Zeilen bewegen sich stärker. Die Multiplikatoren für Prompt Caching gelten zusätzlich zum Fast-Preis, und Opus 5.5 liest seinen Cache zu 0,05x des Input-Preises, während 4.8 zu 0,1x liest. Mit den veröffentlichten Multiplikatoren, pro Million Tokens:

Ein 4.8-Fast-Workload, der auf 5.5 Fast umzieht, spart also Token für Token 20 % bei Input und Output und 60 % bei Cache-Reads. Schau dir auch die dritte Zeile an. Außer bei Cache-Reads verlangt Opus 5.5 Fast pro Token mehr als Opus 4.8 mit Standard-Speed, und das spielt weiter unten bei der Entscheidung eine Rolle.

Warum kann derselbe Request auf Claude Opus 5.5 Fast Mode mehr kosten?

Weil es nicht mehr derselbe Request ist. Auf Opus 4.8 läuft ein Request ohne thinking-Feld ohne Thinking. Auf Opus 5.5 ist Thinking immer an, thinking: {"type": "disabled"} gibt einen 400 zurück, und Thinking-Tokens werden als Output-Tokens abgerechnet, auch wenn du den Thinking-Text gar nicht zurückbekommst. Ein Fast-Call auf 4.8, der nur seine Antwort produziert hat, produziert jetzt die Antwort plus alles, was das Modell fürs Denken aufgewendet hat, alles zu $40 pro Million.

Output ist pro Token 20 % billiger geworden, also kann ein Request bis zu 25 % mehr Output-Tokens erzeugen ($50 / $40), bevor seine Output-Zeile mehr kostet als auf 4.8 Fast. Das gilt nur für die Output-Zeile. Der ganze Request enthält auch Input, Cache-Writes und Cache-Reads, und alle drei sind billiger geworden. Meine Einschätzung: Am ehesten werden antwortlastige Calls mit kurzen Prompts teurer, die ohne Thinking liefen, und lange gecachte Agent-Sessions haben den meisten Rabatt, um das aufzufangen. Garantiert ist keins von beidem. Anthropics eigene Checkliste sagt, du sollst die Kosten bei dem Effort-Level, das du wählst, neu messen, und die Zahl zum Vergleichen sind die Gesamtkosten pro Request oder pro Aufgabe, aus deinen Logs.

Zwei Stellschrauben entscheiden das. output_config.effort ist jetzt der einzige Hebel für die Thinking-Tiefe, und der Standard bei Opus 5.5 ist medium; wo du früher Thinking abgeschaltet hast, um Tokens zu sparen, sagt der Migration Guide, du sollst eine niedrigere Stufe wählen, und sein Beispiel nimmt low. Und max_tokens deckt jetzt Thinking plus Text ab, also kann ein Limit, das für Antworten ohne Thinking eingestellt war, plötzlich mit stop_reason: "max_tokens" enden. Beides kommt als 200 zurück, aus derselben Familie stiller Brüche, die das Upgrade von Opus 5 auf Opus 5.5 mitgebracht hat, und der verlinkte Beitrag deckt den Rest des Umstiegs ab: Erzwungenes tool_choice und abgeschaltetes Thinking geben jetzt 400 zurück, und Thinking-Blöcke müssen in Tool-Loops unverändert zurückgehen.

Ist Claude Opus 5.5 Fast Mode für deinen Request wirklich schneller?

Schneller beim Schreiben, nicht unbedingt schneller beim Anfangen. Fast Mode erhöht die Output-Tokens pro Sekunde um bis zu 2,5x, und laut Docs liegt der Gewinn dort, nicht bei der Zeit bis zum ersten Token.

Auf 4.8 ohne Thinking war das erste Token Antworttext. Auf 5.5 kann die Response mit Thinking-Blöcken beginnen, die beim Standard display: "omitted" mit leerem thinking-Feld ankommen. Für jemanden, der einen Stream beobachtet, ist das eine Pause, bevor sichtbarer Text erscheint. Schnellere Generierung verkürzt vielleicht auch die Thinking-Phase, aber nichts in den Docs verspricht das. 5.5 Fast kann also gleichzeitig pro Token schneller und beim ersten sichtbaren Wort langsamer sein.

Miss vorher und nachher die Zeit bis zum ersten nicht-leeren Text-Delta im Stream. Die Tokens pro Sekunde sind so oder so gestiegen; auf diese Zahl wartet dein Nutzer nicht. Wenn das erste sichtbare Wort langsamer geworden ist, senk zuerst den Effort. Braucht die Aufgabe das Thinking, aber die Nutzer sollen Fortschritt sehen, setz display: "summarized", damit die Pause etwas enthält. Die Docs von Claude Code schlagen dieselbe Kombination von der anderen Seite vor: Fast Mode plus niedrigeres Effort-Level für maximales Tempo bei einfachen Aufgaben.

Wenn Claude Fast Mode an sein Rate Limit stößt: auf Standard-Speed zurückfallen oder warten?

Bei langen gecachten Kontexten: warten. Das ist die zweite Stelle, an der die Rechnung pro Request steigt, und sie sitzt in deinem Error-Handler, nicht im Modell. Fast Mode hat ein eigenes Rate Limit, getrennt von Standard-Opus, gemeldet in den Response-Headern anthropic-fast-input-tokens-* und anthropic-fast-output-tokens-*. Überschreitest du es, gibt die API einen 429 mit retry-after-Header zurück, und die SDKs versuchen es standardmäßig zweimal erneut. Die Docs beschreiben die Wartezeit als meist kurz, weil sich die Fast-Kapazität kontinuierlich auffüllt.

Die Docs zeigen auch einen Fallback: den 429 abfangen, speed weglassen, mit Standard-Speed erneut senden. Das funktioniert. Die Anmerkung daneben ist die ganze Kostengeschichte: Requests mit unterschiedlicher Geschwindigkeit teilen keine gecachten Präfixe, der Fallback ist also ein Prompt-Cache-Miss. Laut den Caching-Docs macht ein Wechsel der Geschwindigkeit die Caches für system und Messages ungültig; nur die Tool-Definitionen bleiben gecacht.

Rechnen wir das für eine Agent-Session mit einem gecachten Präfix von 200.000 Tokens auf Opus 5.5 durch, unter der Annahme, dass das ganze Präfix in system und den Messages liegt. Ein warmer Fast-Read davon kostet etwa $0,08. Der Fallback schreibt es für $1,00 in den Standard-Cache. Ist der Fast-Eintrag abgelaufen, wenn du zurückkommst (standardmäßig nach fünf Minuten), schreibt der nächste Fast-Request es erneut, $2,00. Ein Hin und Zurück kostet zwischen $1 und $3 an Cache-Writes, wo das Bleiben auf Fast $0,08 pro warmem Read gekostet hätte. Bei kurzen Prompts ist der Fallback billig und völlig in Ordnung. Bei langen wartest du das retry-after ab, es sei denn, eine Deadline auf Nutzerseite verträgt die Verzögerung nicht.

Bei der Modellwahl ist es genauso. Jedes Modell hat seinen eigenen Cache, also liest der erste 5.5-Request in einer langen Unterhaltung den ganzen Kontext ungecacht. Wechsle an einer Session-Grenze. Mitten in einem Lauf mit 300k Tokens schreibt der erste 5.5-Request alles neu. Und wenn deine Cache-Reads nach einem Wechsel einbrechen, ohne dass sich am Prompt etwas geändert hat: Die Geschwindigkeit ist ein weiterer Parameter außerhalb des Prompt-Texts, eine Art von Miss, die du mit Cache-Diagnose durch Lesen des Prompts nicht findest.

Was müssen Claude-Code-Nutzer vor dem 30. November tun?

Einen von zwei Befehlen ausführen. Um Fast Mode zu behalten, wechsle mit /model ausdrücklich auf Opus 5.5; das braucht Claude Code v2.1.280 oder neuer, und Fast Mode bleibt nach dem Wechsel an. /fast einzuschalten ist keine Migration: Auf einem Modell, das Fast Mode unterstützt, behält es dein aktuelles Modell, und bis zum 30. November gehört 4.8 dazu. Um auf 4.8 zu bleiben, führ /fast off aus. Fast Mode auf Opus 4.8, ohne dass du etwas änderst, ist die eine Kombination, die bricht.

Vier weitere Details aus den Docs. Muss Fast Mode dein Modell wechseln, wählt es in v2.1.280 und neuer standardmäßig Opus 5.5. In den Plänen Pro, Max, Ultra, Team und Enterprise wird Fast Mode nur aus Usage Credits bezahlt und nie aus der im Plan enthaltenen Nutzung, selbst wenn davon noch etwas übrig ist. Claude Code bietet Fast Mode nur über die Anthropic API und Abos an, nicht auf Bedrock, Google Clouds Agent Platform, Microsoft Foundry oder Claude Platform on AWS. Und wenn du in Claude Code ans Fast-Rate-Limit stößt, fällt es selbst auf Standard-Speed zurück, graut das ↯-Icon aus und schaltet Fast nach einer Abkühlphase wieder ein. Das Icon zeigt dir, dass der Fallback passiert ist. Es zeigt dir nicht, dass jeder Wechsel die Unterhaltung ungecacht neu liest (der Miss aus dem vorigen Abschnitt). Und bei einem Abo zählen diese Turns mit Standard-Speed als Plan-Nutzung, nicht als Credits.

Ist es eine vernünftige Wahl, bei Claude Opus 4.8 mit Standard-Speed zu bleiben?

Ja, wenn Tempo nie das war, was du davon gebraucht hast. Opus 4.8 mit Standard-Speed kostet pro Token weniger als Opus 5.5 Fast, außer bei Cache-Reads ($5 und $25 gegen $8 und $40), die Abschaltung ist nicht vor Mai 2027 geplant, und es behält Dinge, die 5.5 gestrichen hat: Thinking standardmäßig aus, erzwungenes tool_choice, das Tool computer_20251124 auf der Claude API und Priority Tier, das Opus 5.5 überhaupt nicht unterstützt. Und es gibt eine dritte Option, die die Deprecation-Mitteilung nicht erwähnt: Opus 5.5 mit Standard-Speed, $4 und $20, für alles, was auf 5.5 funktioniert und das Tempo nicht braucht.

Die Frage, die ich jedem Fast-Call stellen würde, ist, warum er schnell war. Wenn ein Mensch auf den Output wartet, war das Tempo der Sinn der Sache, und der Weg führt zu 5.5 Fast, mit den Prüfungen von Effort und max_tokens von oben. Läuft er in einer Pipeline oder einem Batch, wo niemand zusieht, war Fast Mode vielleicht ein Aufpreis für nichts. Die Docs von Claude Code selbst zählen lange autonome Aufgaben und CI zur Arbeit für den Standard-Modus. Die Deprecation ist ein günstiger Moment, um herauszufinden, welche deiner Fast-Calls Absicht waren.

Was solltest du ändern, bevor Claude Opus 4.8 Fast Mode entfernt wird?

Sortiert danach, wie viel es kostet, wenn du es auslässt:

1. Finde jeden Aufrufer: grep nach fast und dem Header fast-mode-2026-02-01, verfolg, wo jede Model-ID aufgelöst wird, und blättere durch die Analytics-Abfrage, nachdem du geprüft hast, dass der Modellname Zeilen liefert.
2. Gib jedem Aufrufer ein Ziel: Opus 5.5 Fast, wo ein Mensch auf den Output wartet, Opus 5.5 oder 4.8 mit Standard-Speed, wo niemand wartet.
3. Entscheide, was ein Fast-429 tut: erneut versuchen bei langen gecachten Prompts, zurückfallen nur dort, wo der Prompt kurz ist oder eine Deadline es verlangt.
4. Auf 5.5: effort ausdrücklich setzen, max_tokens fürs Thinking erhöhen und die 400er und die Regeln für Thinking-Blöcke aus dem Migration Guide abarbeiten.
5. Auf 5.5 neu messen: Gesamtkosten pro Request gegen 4.8 Fast, und die Zeit bis zum ersten sichtbaren Text.
6. Modelle an einer Session-Grenze wechseln und dabei mit einem kalten Cache pro Unterhaltung rechnen.

Der Fehler am 1. Dezember ist der einfache Teil, weil er angekündigt kommt. Die Thinking-Tokens und die Cache-Writes vom Fallback kommen als 200 zurück und tauchen auf der Rechnung auf.