Opus 4.8 in Claude Code: Was neu ist, Preise und wie du 2026 wechselst

Ailoot-Referenzdokumentation: ailoot.ai/docs/.

Was wurde am 28. Mai in Claude Code mit Opus 4.8 eingeführt?#

Am 28. Mai brachte Anthropic Opus 4.8 heraus — 41 Tage nach Opus 4.7. Am selben Tag erschienen Claude Code v2.1.154 und der Blogbeitrag „Introducing dynamic workflows in Claude Code“. Am nächsten Tag behob v2.1.156 einen Fehler mit thinking blocks, der die API mit Opus 4.8 beeinträchtigte.

Vier Änderungen, die alle betreffen, die in Claude Code programmieren:

1. Das neue Modell Opus 4.8 — dieselben Preise ($5/$25 pro Million Tokens), aber höhere Benchmarkwerte und es übersieht Fehler im eigenen Code 4-mal seltener.
2. Dynamic Workflows — Claude schreibt ein JS-Skript, das über einen Lauf bis zu 1000 Subagenten startet, mit höchstens 16 gleichzeitig aktiven. Auslöser ist das Wort workflow im Prompt.
3. xhigh effort — eine neue Reasoning-Stufe. Der Standard bei Opus 4.8 ist jetzt high; für anspruchsvolle Aufgaben kannst du auf xhigh erhöhen.
4. Fast Mode wurde 3-mal günstiger — zuvor kostete er das 6-Fache des Standardpreises, jetzt das 2-Fache bei 2,5-facher Geschwindigkeit.

Anthropic selbst äußert sich zurückhaltend zu dieser Veröffentlichung:

In diesem Guide zeige ich genau, was sich geändert hat, was es in der Praxis kostet und ob du jetzt wechseln oder lieber warten solltest.

Wie unterscheidet sich Opus 4.8 von 4.7?#

Was sich bei den Zahlen verbessert hat

Anthropic veröffentlichte Benchmarks in seiner offiziellen Ankündigung und in den Claude API Docs. Übersichtstabelle:

⚠️ Das sind vom Anbieter veröffentlichte Zahlen — Zahlen von Anthropic, keine unabhängige Messung.

Das wichtigste Versprechen: „übersieht 4× seltener Fehler“

Anthropic behauptet:

Das klingt großartig, aber unter der Oberfläche gibt es eine Nuance: Laut der System Card von Anthropic hatte Claude Opus 4.8 bei jedem Benchmark die niedrigste Quote falscher Antworten unter sechs Modellen, weil es sich einer Antwort enthält, wenn es unsicher ist.

In die Sprache von Vibe-Codern übersetzt: Das Modell ist nicht 4-mal intelligenter geworden. Es sagt häufiger „Ich bin mir nicht sicher, prüf das“ statt eine plausible Halluzination auszugeben. Ehrlichkeit statt höherem IQ — so sieht die Entwicklung aus.

In der Praxis bedeutet das: Bei denselben Aufgaben, bei denen Claude früher selbstbewusst gelogen hat, sagt es jetzt: „Da bin ich mir nicht sicher.“ Das senkt das Risiko, erhöht aber nicht die Abdeckung.

Was gleich geblieben ist

• Standardpreis ($5 pro Million Input-Tokens, $25 pro Million Output-Tokens) — unverändert.
• Wissensstichtag — Januar 2026, wie bei 4.7.
• Standardkontext — 1 Million Tokens bei der Anthropic API, AWS Bedrock und GCP Vertex AI. Bei Microsoft Foundry — 200K.
• Maximale Ausgabe — 128K Tokens.
• Sampling-Parameter (temperature, top_p, top_k) — weiterhin nicht unterstützt; sie liefern einen 400 error zurück.

Wo Opus 4.8 schlechter abschneidet

Ehrlich gesagt: Bei Terminal-Bench 2.1 erreicht Opus 4.8 74,6 % — nicht schlecht, aber kein Spitzenreiter der Kategorie. Wenn der Großteil deiner Arbeit im Terminal stattfindet, behalte das im Hinterkopf: Codex ist bei rein terminalbasierten Aufgaben oft etwas stärker. Bei den anderen Benchmarks liegt Opus 4.8 vorn, aber dieser Unterschied ist real.

Der zweite offene Punkt: Bei komplexen agentischen Pipelines mit ungeprüften Eingaben (Website-Parsing, RSS-Lesen) ist der Schutz vor Prompt Injection in Opus 4.8 nicht garantiert. Wenn du Automatisierungen entwickelst, die Dokumente anderer lesen, solltest du einen separaten Eingabe-Sanitizer verwenden.

Was kostet Opus 4.8 im Jahr 2026?#

Preismodelle

Der Standardpreis blieb derselbe wie bei 4.7 und 4.6. Das ist selten — neue Generationen sind üblicherweise teurer. Fast Mode wurde 3-mal günstiger: Bei 4.6 und 4.7 kostete der Fast-Modus das 6-Fache des Standardpreises. Bei 4.8 ist es das 2-Fache.

Was das pro Arbeitsstunde bedeutet

Eine Stunde aktives Programmieren in Claude Code mit Opus 4.8 entspricht etwa 1–2 Millionen Input-Tokens und 100–300 Tausend Output-Tokens. Zu Standardpreisen sind das $5–10 für Input und $2,5–7,5 für Output. Gerundet sind das $8–15 pro Stunde allein über die API.

Bei Abotarifen:

• Pro ($20/Monat) — reicht für 1–2 Stunden aktive Arbeit am Tag. Ein einziger anspruchsvoller Prompt mit einem Dynamic Workflow verbraucht das Limit.
• Max 5x ($100/Monat) — konstant 4–6 Stunden pro Tag. Der Mittelweg für die meisten Vibe-Coder.
• Max 20x ($200/Monat) — ein ganzer Arbeitstag, ohne auf das Limit achten zu müssen. Das lohnt sich, wenn du viele Workflows startest oder mit dem Agent SDK arbeitest.

Weitere Informationen findest du in den Guides So verbrauchst du nicht dein Claude-Code-Limit und Wohin die Tokens gehen.

⚠️ Ein wichtiger Hinweis von Anthropic: Ein Workflow mit 1000 Agenten verbraucht „deutlich mehr Tokens als eine typische Sitzung“. Ein großer Lauf kann viel Kontingent verbrauchen, obwohl höchstens 16 Agenten gleichzeitig aktiv sind. Prüfe verfügbare Nutzung und setze vor dem Start ein Laufbudget. Gleichzeitigkeit allein bestimmt keine Gesamtkosten.

⚠️ Fast Mode ist nicht in den Tarifen Pro / Max / Team / Enterprise enthalten. Dafür müssen Usage Credits aktiviert sein; die Abrechnung erfolgt zusätzlich zum Abo mit $10/$50 pro Million Tokens. Wenn du Max nutzt und Fast Mode ohne Credits aktivierst, erhältst du eine Meldung, dass du dein Guthaben aufladen musst. Beim Lesen der Dokumentation wird das oft übersehen.

Was sind Dynamic Workflows in Claude Code?#

Wie sich ein Workflow von einem Subagenten und einem Skill unterscheidet

Früher nutzte alles, was Claude Code autonom erledigte, eine schrittweise Orchestrierung. In jedem Schritt entschied Claude, welches Tool aufgerufen werden sollte, und Zwischenergebnisse lagen in seinem Kontext. Das funktioniert mit bis zu 4–5 Subagenten; danach läuft der Kontext über.

Dynamic Workflow ändert dieses Muster. Claude schreibt ein JavaScript-Skript, das die Agenten selbst orchestriert. Zwischenergebnisse bleiben in den Variablen des Skripts und nicht in Claudes Kontext. Nur das Endergebnis kehrt in den Kontext zurück. Das hat drei Effekte:

1. Du kannst bis zu 16 Agenten parallel starten, insgesamt bis zu 1000 pro Durchlauf.
2. Claudes Kontext läuft nicht über — jeder Subagent arbeitet in seiner eigenen Sandbox.
3. Das Skript ist wiederverwendbar — drück nach einem erfolgreichen Durchlauf s in /workflows, dann wird es als dein Slash-Befehl gespeichert.

Anthropics Workflow-Dokumentation beschreibt es so:

Laufzeitlimits

Drei Möglichkeiten, einen Workflow zu aktivieren

1. Das Wort workflow im Prompt. „Run a workflow to audit every API endpoint under src/routes/ for missing auth checks“. Claude erkennt den Auslöser, schreibt ein Skript und startet es.
2. /effort ultracode — kombiniert xhigh Reasoning mit automatischer Workflow-Orchestrierung. Es gilt für alle wesentlichen Aufgaben in der Sitzung. In der Dokumentation heißt es:

3. /deep-research [question] — ein integrierter Workflow für Recherche mit Websuche und Quellenabgleich.

Beispiel: Bun mit 750.000 Zeilen Rust in 11 Tagen

Das Bun-Team nutzte Dynamic Workflows für ein Experiment: Bun von Zig nach Rust zu portieren. Laut dem Anthropic-Blog:

• ~750.000 Zeilen Rust generiert.
• 11 Tage vom ersten Commit bis zum Merge.
• 99,8 % der Tests der bestehenden Testsuite bestanden.
• ~300 Regeln für die Übersetzung von Zig → Rust.

Das technische Muster bestand aus drei Workflows hintereinander:

1. Workflow #1 ordnet jedem Struct-Feld in der Zig-Codebasis die passende Rust-Lifetime zu.
2. Workflow #2 schreibt jede .rs-Datei als verhaltensidentische Portierung ihres .zig-Gegenstücks. Hunderte Dateiaufgaben in mehreren Gruppen, höchstens 16 Agenten gleichzeitig und zwei Reviewer pro Datei.
3. Workflow #3 ist eine Korrekturschleife: Build + Test laufen lassen, bis alles erfolgreich ist.

Die größte Falle: Workflows verbrauchen bei kleinen Aufgaben dein Limit

Praktische Schlussfolgerung: Wenn eine Aufgabe mit 1–2 einfachen Subagenten erledigt werden kann, starte keinen Workflow; nutze Subagenten manuell. Workflows lohnen sich bei mehr als 50 Dateien, nicht bei 5.

Dynamic Workflow ist der nächste Schritt im Context Engineering. Ein Workflow kann Arbeit auf bis zu 1000 Agentenstarts insgesamt verteilen und höchstens 16 gleichzeitig planen. Ohne gemeinsamen Projektkontext können sich Fehler über diese Gruppen sammeln, weil jeder Agent nur seinen Ausschnitt sieht.

Wann solltest du xhigh effort aktivieren?#

In den Release Notes zu Claude Code v2.1.154 sagt Anthropic ausdrücklich: Opus 4.8 läuft standardmäßig mit effort=high — das ist nach der Veröffentlichung der neue Standard. Zuvor lag der Standard niedriger. Die neue Stufe xhigh steht zusätzlich für die anspruchsvollsten Aufgaben zur Verfügung, bei denen das Modell pro Schritt mehr Thinking-Tokens verbraucht.

Wann xhigh sinnvoll ist:

• Migrationen (neues Architekturpattern → mehr als 50 Dateien).
• Sicherheitsaudits (Sicherheitsprüfung von mehr als 200 Endpunkten).
• Geplante Refactorings mit Invariantenprüfungen.
• Komplexe, lange Debugging-Sitzungen, in denen sich das Modell an den gesamten Ablauf erinnern muss.

Wann du es NICHT verwenden solltest:

• Routineänderungen in einer Datei (einen Test schreiben, eine Methode umbenennen).
• Einfache Prompts mit klarer Struktur.
• Dokumentation / Kommentare — dort ist xhigh ein unnötiger Aufpreis.

In Claude Code v2.1.154 wurde der Effort-Schieberegler von „Speed/Intelligence“ in „Faster/Smarter“ umbenannt. Der Standard /effort high wird jetzt im Hintergrund angewendet; du musst ihn nicht ausdrücklich einstellen.

Wann solltest du Fast Mode verwenden?#

Preise:

Wann du es verwenden solltest:

• Interaktive Aufgaben, bei denen die Reaktionszeit wichtiger ist als die Genauigkeit (Live-Code-Review in einem Stream).
• Schnelle Änderungen und Hypothesenprüfung.
• Eine Demo / Präsentation für einen Kunden.

Wann du es NICHT verwenden solltest:

• Lang laufende agentische Aufgaben — das 2-Fache des Preises bei einem 1M-Kontext verschlechtert die Wirtschaftlichkeit.
• Ein großer Dynamic Workflow — Fast Mode verdoppelt die geltenden Tokenpreise, und der Verbrauch aller gestarteten Agenten summiert sich. 1000 Gesamtstarts sind kein fester 1000-facher Aufgabenpreis. Plane nach tatsächlichen gesamten Ein- und Ausgaben.
• Hintergrundsitzungen, bei denen Geschwindigkeit nicht entscheidend ist.

Wie wechselst du zu Opus 4.8, ohne Einstellungen zu verlieren?#

Schritt 1. Claude Code aktualisieren

Im Terminal:

claude upgrade

Oder nach der Anthropic-Dokumentation neu installieren.

⚠️ Die Zielversion ist v2.1.156 oder höher. v2.1.154 hatte einen Fehler: Bei Verwendung von Opus 4.8 wurden thinking blocks verändert, was API-Fehler verursachte. Der Fehler wurde in v2.1.156 behoben.

Version prüfen:

claude --version

Schritt 2. Das Modell in /config wechseln

In Claude Code:

/model claude-opus-4-8

Oder /config öffnen → Bereich Model → Opus 4.8 aus der Liste auswählen. Die Modell-ID am API-Endpunkt lautet claude-opus-4-8.

Schritt 3. Dynamic Workflows aktivieren (Pro-Tarif)

Beim Pro-Tarif sind Dynamic Workflows standardmäßig deaktiviert. Öffne /config → Bereich Workflows → aktiviere sie. Bei Max, Team und persönlichem Enterprise sind sie von Anfang an aktiviert. Bei Enterprise mit Admin können sie vom Admin deaktiviert worden sein; bitte den Admin, sie freizuschalten.

Schritt 4. Einen Test durchführen

Bitte Claude Code um eine einfache Aufgabe mit eindeutigem Ergebnis, um sicherzustellen, dass das Modell korrekt antwortet:

Schreibe eine TypeScript-Funktion, die ein Array in Blöcke fester Länge aufteilt.
Gib mir Tests in vitest.

Wenn die Antwort passend ist und am Anfang die Formulierung „using claude-opus-4-8“ erscheint, hat der Wechsel funktioniert. Bei einem 400 error prüfe deine Claude-Code-Version (gehe zurück zu Schritt 1).

Was du NICHT migrieren musst

• CLAUDE.md funktioniert ohne Änderungen mit jedem Modell. Mehr dazu im Guide So konfigurierst du CLAUDE.md.
• Skills werden automatisch von Opus 4.8 übernommen. Mehr dazu im Guide Claude Code Skills.
• MCP-Server funktionieren unverändert. Der Guide zu MCP: 7 fertige Kombinationen.
• Subagenten und Plan Mode bleiben unverändert. Eine Zusammenfassung der Wahl zwischen Skills, Subagenten, MCP und Plugins findest du in der entsprechenden Säule.

Solltest du von Sonnet 4.6 oder Haiku 4.5 wechseln?#

Ich habe die Wahl zwischen Sonnet und Opus bereits in einem älteren Guide behandelt, aber der bezog sich auf 4.7. Mit Opus 4.8 verschieben sich die Regeln ein wenig.

Entscheidungsmatrix für 2026:

Für die meisten Vibe-Coder ist Sonnet 4.6 als Standardmodell zusammen mit Opus 4.8 für anspruchsvolle Aufgaben über den /model-Wechsel der beste Mittelweg. So zahlst du weniger und kannst anspruchsvolle Aufgaben trotzdem ordentlich erledigen.

Was funktioniert bei Opus 4.8 NICHT?#

Laut praktischen Berichten gibt es drei Bereiche, in denen Opus 4.8 schlechter abschneidet:

1. Datenintensive Strategie und Roadmaps. Praxisberichten zufolge ist 4.7 für Analysen weiterhin die bessere Wahl. Wenn dein wichtigster Anwendungsfall darin besteht, eine Kennzahlentabelle zu erstellen und eine Roadmap vorzuschlagen, probiere zuerst 4.8 aus; falls es scheitert, wechsle mit /model claude-opus-4-7 zurück zu 4.7.

2. Die „letzten 10 %“ in bestehenden Codebasen. Das Modell erledigt Greenfield-Arbeit (ein neues Projekt von Grund auf) sehr gut, hat aber Schwierigkeiten mit der Weiterentwicklung alten Codes — Randfällen und spezifischen Eigenheiten der Architektur. Das ist eine typische Schwäche von Reasoning-Modellen: Sie generieren gut, sind aber schlecht darin, Vorhandenes „fertigzustellen“.

3. Halluzinationen sind geblieben. „Übersieht Fehler 4× seltener“ bedeutet, dass das Modell häufiger „Ich weiß es nicht“ sagt. Wenn jedoch Kontext fehlt, kann es immer noch etwas Plausibles erfinden. Schutz bietet der Projektkontext: Je vollständiger CLAUDE.md ist, desto weniger Raum bleibt für Halluzinationen.

Das bedeutet nicht: „Aktualisiere nicht.“ Es bedeutet: Verstehe die Einschränkungen und behalte Sonnet 4.6 und Opus 4.7 als Fallbacks in der Hinterhand.

Was kommt nach Opus 4.8?#

In Anthropics Formulierungen bedeutet „coming weeks“ üblicherweise 4–8 Wochen. Ein Mythos-Modell wird also wahrscheinlich im Juni oder Juli 2026 erscheinen. Das ändert die Strategie:

• Wenn deine aktuellen Projekte Sonnet 4.6 oder Opus 4.7 nutzen — aktualisiere auf 4.8 und probiere xhigh und Workflows bei konkreten Aufgaben aus. Preislich ist das ein kostenloses Upgrade.
• Wenn du eine große Migration mit einem Workflow geplant hast — überstürze es nicht. In ein oder zwei Monaten könnte ein Modell erscheinen, das sie noch besser erledigt. Du kannst mit einem Experiment an einem Modul anfangen, um den Ablauf kennenzulernen.
• Wenn du deine Infrastruktur für Dynamic Workflows umbauen wolltest — warte. Mythos könnte die grundlegenden Muster verändern.

In dieser Unsicherheit liegt der wichtigste Rat: Bleib flexibel. Opus 4.8 ist ein gutes inkrementelles Upgrade. Mythos könnte ein Sprung sein. Investiere nicht einen Monat vor einem möglichen neuen Modell in umfangreiche Umbauten.

Entdecke Ailoot weiter auf ailoot.ai.