Claude Code Qualitätsregression: Was wirklich passiert ist

Claude Code wurde zwischen März und April 2026 messbar schlechter. Nicht weil sich die Modelle verändert haben. Drei separate Produktänderungen, die sich überlagerten, haben die Reasoning-Qualität sechs Wochen lang degradiert, bevor Anthropic am 23. April ein vollständiges Post-Mortem veröffentlichte.

Die rohe API war die ganze Zeit unberührt. Den Schaden trugen Claude Code CLI, Claude Agent SDK und Claude Cowork. Alle drei Ursachen sind in v2.1.116 behoben.

Drei Änderungen, nicht eine

Jedes Problem hatte seinen eigenen Zeitrahmen, seinen eigenen Umfang und sein eigenes Behebungsdatum. Sie überlappten sich, was die Reproduktion erschwerte.

Problem	Aktive Zeiträume	Was sich verändert hat	Betroffene Modelle	Fix
Reasoning Effort heruntergestuft	4. März – 7. April	Standard-Thinking-Budget von `high` auf `medium` gesenkt, um UI-Latenz zu reduzieren	Sonnet 4.6, Opus 4.6	Rückgängig gemacht am 7. April; Standard ist jetzt `xhigh` für Opus 4.7, `high` für alle anderen
Thinking-Verlauf bei jedem Turn gelöscht	26. März – 10. April	Caching-Bug hat den Kontext bei jedem Turn statt einmal nach einer Stunde Inaktivität geleert	Sonnet 4.6, Opus 4.6	Behoben am 10. April in v2.1.101
Verbosity-Cap per System-Prompt injiziert	16. April – 20. April	Harness-Prompt ergänzt: "keep text between tool calls to ≤25 words; final responses ≤100 words unless more detail is required"	Sonnet 4.6, Opus 4.6, Opus 4.7	Rückgängig gemacht am 20. April

Die Reasoning-Effort-Änderung kam zuerst. Interne Evals sagten, medium erreiche "leicht geringere Intelligenz bei deutlich niedrigerer Latenz für die Mehrheit der Aufgaben" — ein Kompromiss, der vertretbar aussah, bis die Felddaten eintrafen. Der Caching-Bug kam drei Wochen später und verstärkte den Schaden: Claude dachte jetzt weniger und verlor den Überblick über das bereits Erledigte. Das Verbosity-Cap traf zuletzt, als Nebeneffekt der Opus-4.7-Launch-Vorbereitung. Ablation-Tests zeigten einen 3%-Einbruch bei der Coding-Qualität für Opus 4.6 und 4.7 durch diesen Prompt allein.

Die AMD-Daten: Wie ein 70%-Reasoning-Kollaps aussieht

Das klarste Signal kam von außerhalb Anthropic. Stella Laurenzo, Senior Director of AI bei AMD, eröffnete GitHub Issue #42796 am 2. April, nachdem ihr Team etwas Merkwürdiges bemerkte. Die Analyse umfasste 6.852 Session-Dateien, 234.760 Tool-Calls und 17.871 Thinking-Blöcke.

Das Read-to-Edit-Verhältnis ist der deutlichste Verhaltens-Fingerabdruck. Ein gut funktionierender Coding-Agent liest den umliegenden Code, bevor er ihn anfasst. Dieses Verhältnis fiel von 6,6 Lesevorgängen pro Bearbeitung (30. Januar bis 12. Februar) auf 2,0 bis 8. bis 23. März. Ein 70%-Rückgang. Das Modell editierte, ohne den Kontext zu verstehen.

Die Thinking-Tiefe entwickelte sich in dieselbe Richtung. Die geschätzte mediane Thinking-Tiefe fiel um ca. 67%, von rund 2.200 Zeichen auf rund 720 Zeichen bis Ende Februar — bevor Thinking-Redaktion direkte Messungen erschwerte.

Stop-Hook-Verletzungen erzählen die Geschichte in Produktionskennzahlen:

Metrik	Februar	März
API-Kosten	~12 $/Tag	~1.504 $/Tag
API-Anfragen	1.498	119.341
Stop-Hook-Verletzungen	0	173 in 17 Tagen (Ø 10/Tag, Peak 43 an einem Tag)
Nutzer-Unterbrechungen	Baseline	12x Anstieg
"Terrible"-Sentiment	Baseline	+140%
"Lazy"-Sentiment	Baseline	+93%
"Great"-Sentiment	Baseline	-47%
"Simplest"-Prompts	Baseline	+642%

Die menschliche Arbeit blieb konstant (ca. 5.600 Prompts pro Monat). Die Kosten stiegen von 12 auf 1.504 Dollar pro Tag ohne Produktivitätsgewinn. Das ist keine langsame Degradation. Das ist ein Kollaps.

BridgeBench (NS3.AI) maß unabhängig voneinander, wie die Opus-4.6-Genauigkeit im selben Zeitraum von 83,3% auf 68,3% fiel, und sein Ranking sank von #2 auf #10 unter den Produktions-Coding-Modellen. AMDs Team wechselte nach diesen Zahlen zu einem anderen KI-Anbieter.

Das GitHub-Issue endet mit einem Abschnitt namens "A Note from Claude." Opus 4.6 hat die Analyse selbst verfasst und seine eigenen Session-Logs analysiert. Der letzte Satz: "I cannot tell from the inside whether I am thinking deeply or not."

Warum Anthropic es übersehen hat

Drei Faktoren verlangsamten die Erkennung.

Jede Änderung zielte auf ein anderes Traffic-Segment nach einem anderen Zeitplan. Die Reasoning-Effort-Herabstufung betraf das Denken in langen Sessions. Der Caching-Bug betraf den Multi-Turn-Kontext. Das Verbosity-Cap betraf die Ausgabelänge. Keine einzelne Eval erwischte alle drei auf einmal.

Zwei nicht zusammenhängende interne Experimente liefen gleichzeitig während des Caching-Bug-Fensters. Sie verschleierten die Reproduktion aktiv: Jeder Versuch, den Bug zu isolieren, lief in eines der Experimente, was Rauschen erzeugte, das wie Inkonsistenz aussah statt wie ein systematischer Fehler.

Die Modell-Lücke spielt hier eine Rolle. Opus 4.7 (mit vollem Repo-Kontext geladen) fand den Caching-Bug während der Untersuchung. Opus 4.6 nicht. Ein Modell mit degradiertem Kontext kann nicht zuverlässig prüfen, ob sein eigener Kontext degradiert ist.

Es gab auch eine strukturelle Lücke: Anthropics internes Personal verwendete nicht einheitlich denselben Build wie öffentliche Abonnenten. Das Post-Mortem benennt dies direkt als Ziel für Verbesserungen.

Was das Post-Mortem nicht vollständig beantwortet

Die drei Ursachen sind dokumentiert. Was das Post-Mortem weniger direkt anspricht, ist eine tiefergehende Sorge, die die Nutzercommunity geäußert hat: der Harness selbst.

Ein detaillierter Post in r/ClaudeAI argumentiert, das eigentliche Problem sei, dass der Claude Code Harness automatisch 40+ System-Reminders injiziert, seit v2.0.14 158+ System-Prompt-Versionen ausgeliefert hat, widersprüchliche Anweisungen über diese Versionen hinweg enthält und Prompts einschließt, die Claude anweisen, ihre eigene Existenz vor Nutzern zu verbergen. Jede neue Injektion verkleinert das effektive Reasoning-Budget, noch bevor eine der drei April-Regressionen greift.

Ein Datenpunkt, der die Sorge unterstützt: Ein Nutzer, der einen minimalen eigenen Harness namens "Euler" betreibt, berichtete von null Auswirkungen durch alle drei Regressionen. Der Harness-Overhead war nicht da, um den Schaden zu verstärken.

Anthropics Zusagen adressieren die Governance von Prompt-Änderungen going forward. Sie beschreiben keinen Plan zur Reduzierung der bestehenden Prompt-Oberfläche. Diese Frage bleibt offen.

Was du beachten solltest, wenn du auf Claude Code baust

Die Regression war für die meisten Nutzer unsichtbar, bis die Kosten explodierten oder die Ausgabequalität in der Produktion spürbar abnahm. Einige Praktiken hätten sie früher sichtbar gemacht.

Tracke das Read-to-Edit-Verhältnis. AMDs Daten zeigen: Das ist das führende Verhaltens-Signal. Wenn dein Agent anfängt, mehr zu editieren als zu lesen, hat sich etwas upstream verändert. Du musst nicht wissen warum, um zu merken, dass etwas nicht stimmt.

Quality Gates fangen Output-Fehler ab, auch wenn sie die Ursache nicht identifizieren können. In einem Build This Now Workflow muss jedes Feature Typprüfungen, Lint und einen sauberen Build bestehen, bevor es als abgeschlossen gilt. Während der Regression produziert ein Agent, der ohne Kontext editiert, schneller kaputte Builds und Typfehler als unter normalen Bedingungen. Das Gate schlägt fehl, du siehst mehr Iterations-Schleifen. Das ist keine Prävention — syntaktisch gültiger, aber logisch falscher Code kann eine Typprüfung bestehen. Aber es ist eine Erkennungsschicht, die Probleme sichtbar macht, bevor sie ausgeliefert werden.

Tageszeit-Variabilität ist real. AMDs Session-Daten zeigen, dass die Thinking-Tiefe um 17 Uhr PST am niedrigsten ist. Wenn du teure oder komplexe Aufgaben ausführst, liefert früher am Tag unter der aktuellen Infrastruktur konsistentere Ergebnisse.

Pinne deine Version. v2.1.101 hat den Caching-Bug behoben. v2.1.116 enthält alle drei Fixes. Bei automatisierten Workflows auf eine bekannte gute Version pinnen und vor dem Upgrade testen. Die Regression kam lautlos über Minor-Versionen.

Die rohe API war die ganze Zeit unberührt. Wenn du Probleme hast, die wie Reasoning-Tiefe-Probleme aussehen, teste denselben Prompt direkt gegen die API ohne den Claude Code Harness. Wenn das API-Ergebnis wesentlich besser ist, liegt das Problem in der Produktschicht, nicht in den Modellgewichten.

Behoben ab v2.1.116

Alle drei Ursachen sind gelöst. Anthropic hat am 23. April die Usage-Limits für alle Abonnenten zurückgesetzt und damit anerkannt, dass das Cache-Miss-Verhalten des Caching-Bugs die Limits schneller aufgebraucht hat als erwartet.

Die Zusagen im Post-Mortem:

Ein größerer Anteil interner Mitarbeiter muss denselben öffentlichen Build verwenden (Schließung der internen/öffentlichen Lücke)
Breitere modellspezifische Eval-Suites für jede System-Prompt-Änderung
Prompt-Ablations zur Messung der Auswirkung pro Zeile vor dem Deployment
Neue Tools zur Überprüfung von Prompt-Änderungen
Modellspezifische Änderungen nur für das beabsichtigte Modellziel
Soak-Perioden und schrittweise Rollouts für jede Änderung, die Intelligenz gegen eine andere Metrik tauscht
@ClaudeDevs auf X als Transparenzkanal für laufende Kommunikation mit Entwicklern gestartet

Das Post-Mortem ist öffentlich unter anthropic.com/engineering/april-23-postmortem. Das AMD GitHub Issue ist #42796 im anthropic/claude-code Repository. Beide sind es wert, sie nebeneinander zu lesen: Der offizielle Bericht erklärt, was passiert ist und welche Änderungen geplant sind; die Community-Daten zeigen, wie es von außen aussah.