Postmortem zur Störung von Anthropic Claude Code: 23. April 2026

Im vergangenen Monat häuften sich Berichte einiger Nutzer, dass die Antwortqualität von Claude nachgelassen habe. Anthropic verfolgte das Problem zurück und bestätigte, dass drei unterschiedliche Änderungen die Ursache waren, die Claude Code, das Claude Agent SDK und Claude Cowork betrafen. Die API selbst war nicht betroffen; mit Stand vom 20. April 2026 (v2.1.116) seien laut Unternehmen alle Probleme behoben. Dieses Postmortem behandelt die Ursachen der Probleme, die vorgenommenen Korrekturen und Maßnahmen zur Verhinderung einer Wiederholung.

Drei Ursachen der Störung und ihr Verlauf

• Senkung des Standardwerts für den reasoning effort (4. März): Der Standardwert für den reasoning effort in Claude Code wurde von high auf medium geändert. Ziel war es, lange Wartezeiten zu verkürzen, bei denen die UI wie eingefroren wirkte. Nutzer bemerkten jedoch eine schlechtere Antwortqualität, weshalb die Änderung am 7. April wieder zurückgenommen wurde. Aktuell ist für Opus 4.7 xhigh als Standard gesetzt, für alle anderen Modelle high.
• Löschung des Reasoning-Verlaufs durch einen Bug in der Caching-Optimierung (26. März): Beim Wiederaufnehmen von Sitzungen, die länger als eine Stunde inaktiv waren, sollte ein Mechanismus den bisherigen Thinking-Verlauf nur einmal bereinigen. Durch einen Bug wurde dieser Verlauf danach jedoch bei jedem weiteren Gesprächszug wiederholt gelöscht. Dadurch konnte Claude sich nicht mehr daran erinnern, warum bestimmte Aktionen ausgeführt worden waren, was die von Nutzern erlebte „Vergesslichkeit“, wiederholte Antworten und ungewöhnliche Tool-Auswahl verursachte. Weil Cache Misses (das Nichtfinden gespeicherter Daten) wiederholt auftraten, wurde zudem das Nutzungslimit schneller als erwartet aufgebraucht. Der Fehler wurde am 10. April behoben.
• Übermäßig starke Vorgabe zur Kürze im System Prompt (16. April): Um ausufernde Ausgaben von Opus 4.7 zu reduzieren, wurde dem System Prompt hinzugefügt: „Text zwischen Tool-Aufrufen maximal 25 Wörter, finale Antwort maximal 100 Wörter“. In internen Tests zeigte sich kein Problem, später stellte sich jedoch heraus, dass dies die tatsächliche Coding-Qualität negativ beeinflusste, weshalb die Vorgabe am 20. April entfernt wurde.

Warum das Problem so spät erkannt wurde

• Die drei Änderungen wurden zu unterschiedlichen Zeitpunkten und für unterschiedliche Traffic-Umfänge ausgerollt, sodass sie wie ein allgemeiner, aber inkonsistenter Qualitätsabfall wirkten und die Zuordnung einzelner Ursachen erschwerten.
• Es gab Unterschiede zwischen interner Testumgebung und realer Nutzerumgebung. Beim Caching-Bug war die Reproduktion zusätzlich dadurch erschwert, dass intern ein separates Experiment lief und sich auch die Darstellung in der UI unterschied.
• Die bestehende Eval-Suite war nicht breit genug. Erst nach zusätzlichen, vielfältigeren Evaluierungen wurde ein Leistungsrückgang von 3 % durch die Änderung am System Prompt sichtbar.

Maßnahmen zur Verhinderung einer Wiederholung

• Interne Mitarbeiter sollen verpflichtend die tatsächlich öffentlich ausgerollten Builds verwenden, um die Lücke zu internen Test-Builds zu verkleinern.
• Die Kontrolle über Änderungen am System Prompt wird verschärft. Bei jeder Änderung werden umfangreiche modellbezogene Evaluierungen durchgeführt, der Einfluss jeder Zeile per Ablation einzeln analysiert und außerdem schrittweise Ausrollungen sowie ausreichende Prüfzeiträume (soak period) eingeführt.
• Die Code-Review-Tools werden verbessert. Ausgehend von der Erkenntnis, dass Opus 4.7 den Caching-Bug finden konnte, wenn ihm das gesamte betreffende Code-Repository als Kontext gegeben wurde, wird der beim Code Review referenzierbare Repository-Umfang erweitert.
• Mit @ClaudeDevs wird ein neuer Kanal für die Kommunikation mit Nutzern eingerichtet, um die Hintergründe von Produktentscheidungen transparent zu teilen.

Zur Aussage „Es gab keine absichtliche Qualitätsverschlechterung“

• Anthropic erklärt, das Modell nie absichtlich verschlechtert zu haben, und bestätigt, dass API und Inference-Layer nicht betroffen waren. Gleichzeitig ist aber auch klar, dass Konfigurationsänderungen und Bugs auf der Produkt-Ebene (Claude Code) in Kombination zu einer für Nutzer spürbar schlechteren Qualität führten. Außerdem wurde angekündigt, die Nutzungslimits für alle Abonnenten zurückzusetzen.

[crawler]

Wie kommt es, dass alle drei Ursachen des Ausfalls direkt mit Kostensenkung zusammenhängen? lol
Offenbar sind die GPU-Ressourcen wirklich so knapp, dass die Leistung dadurch spürbar leidet.....

[colus001]

Das ist die richtige Antwort, aber die Ausrede ist ganz schön lang, haha.

[youknowone]

Sie haben also ausführlich dargelegt, dass sie weder vor der Auslieferung den öffentlichen Build getestet noch nach dem Rollout Tests durchgeführt haben. Ich selbst bin schon am 26. März sofort auf den Bug gestoßen — halten sie es intern wirklich für vertretbar, dass es drei Wochen dauert, so etwas zu bestätigen ...

[youknowone]

Sobald der Patch eingespielt war, wurde das 5-Stunden-Kontingent, das sonst erst nach 3–4 Stunden Nutzung aufgebraucht war, plötzlich schon nach 30 Minuten verbraucht. Da Mitarbeiterkonten aber entweder kein 5-Stunden-Kontingent haben oder zumindest nicht so knapp bemessen sind, dass man bei der Arbeit ständig /usage im Blick behalten müsste, hat es vermutlich entsprechend lange gedauert, bis das auffiel.

[amond]

Beim täglichen SWE-Bench-Pro-Benchmark (kuratierte Auswahl) fällt bei Claude Code etwas Interessantes auf.

Im Zeitraum vom 10.4. bis 20.4. halbierte sich die Runtime (653s→345s), die Tool-Calls halbierten sich ebenfalls (3,3K→1,8K), und die Tokens gingen um 18 % zurück – trotzdem stieg die Pass-Rate sogar um 16 Prozentpunkte. Dass sich alle vier Kennzahlen gleichzeitig in die positive Richtung bewegen, ist kein häufiges Muster.

Die drei Zwischenfälle, die dabei auftraten, sind im Postmortem vom 23.4. dokumentiert, und wenn man sie sich ansieht, entstanden sie alle beim Versuch, „Tokens/Latenz zu reduzieren“.

Bei Codex (gpt-5.4-xhigh) bewegten sich die Zahlen im gleichen Zeitraum dagegen kaum. Die Pass-Rate blieb bei ungefähr 56 % konstant, und auch Tokens/Runtime/Tool-Calls lagen weiterhin etwa doppelt so hoch wie bei Claude Code.

[colus001]

Ist das nicht eher ein Postmortem zur Kostensenkung als ein Postmortem zu einem Ausfall?

[sudoeng]

Sie verpflichten interne Mitarbeitende dazu, tatsächlich den öffentlich veröffentlichten Build zu verwenden, um die Diskrepanz zu internen Test-Builds zu verringern.
Hahaha

[lim8603]

Ich glaube, man hat Opus 4.7 YAGNI beigebracht. Jedes Mal dachte ich mir wohl, das liege daran, dass bei Architekturentscheidungen mit Verweis auf YAGNI eine schrittweise Änderung begründet wurde, aber am Ende baut es doch einen Unfall. Es ist schon schlimm genug, dass dieser Freund kein langes Gedächtnis hat, und jetzt hat er auch noch die Angewohnheit entwickelt, Dinge aufzuschieben.

[tazuya]

Bin ich der Einzige, der denkt, dass sie anfangs noch darauf beharrt haben, es gebe kein Problem, und es jetzt nur offenlegen, weil das Thema zu groß geworden ist, um es noch unter den Teppich zu kehren?

[unsure4000]

Auch die claude.ai-Webseite fühlt sich in der Nutzbarkeit hier und da etwas verschlechtert an ... Um Tokens zu sparen, habe ich auch den Speicher deaktiviert.

[xguru]

Irgendwie habe ich nach dieser Mitteilung eher noch weniger Vertrauen in Anthropic.

Oben stehen zwei verwandte Beiträge, und zwischen beiden liegen sieben Monate. Die Probleme sind in beiden Fällen dieselben drei.

Postmortem zu drei aktuellen Problemen mit der Claude-Qualität 2025-09-19
Update zu aktuellen Berichten über die Qualität von Claude Code 2026-04-24

[skageektp]

Ich bin so wütend wie 5 $ Guthaben wert!!

[wedding]

Ganz schön geschwätzig..