Anthropic erklärt: Warum Claude Code wochenlang schlechter lief
Sechs Wochen lang berichteten Nutzer, dass Claude Code vergesslich wurde, Tools merkwürdig auswählte und sich „weniger intelligent” anfühlte. Anthropic hat jetzt einen Post-Mortem veröffentlicht — die Beschwerden waren berechtigt, drei voneinander unabhängige Änderungen haben sich übereinandergeschichtet.
Drei Fehlerquellen, die sich überlagert haben
1. Reasoning-Effort heruntergedreht (4. März – 7. April) Anthropic senkte den Standard-Reasoning-Effort von „high” auf „medium”, weil einige Nutzer extreme Latenzen meldeten. Interne Tests zeigten nur geringe Qualitätsverluste, im Alltag fühlte sich Claude Code aber spürbar dümmer an. Rückgängig gemacht am 7. April.
2. Caching-Bug (26. März – 10. April) Eigentlich sollte ein Mechanismus ältere Reasoning-Abschnitte erst nach einer Stunde Inaktivität verwerfen. Ein Implementierungsfehler löschte sie stattdessen bei jedem Turn. Die Folge: Claude verlor laufend Kontext über eigene Entscheidungen — Vergesslichkeit, Wiederholungen, schlechte Tool-Auswahl. Zusätzlich fraßen die ständigen Cache-Misses die Usage-Limits schneller leer als gewohnt. Der Bug passierte Code-Reviews, Unit-Tests und internes Dogfooding unbemerkt.
3. Zu strikte Längen-Anweisung (16. – 20. April) Um die Geschwätzigkeit von Opus 4.7 einzudämmen, fügte Anthropic dem System-Prompt diese Regel hinzu: „Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.” In einer breiteren Eval-Suite kostete das rund 3 % Qualität.
Fix und Kompensation
Alle drei Probleme sind mit Version 2.1.116 vom 20. April behoben. Anthropic hat die Usage-Limits für alle Abonnenten zurückgesetzt, um den durch den Caching-Bug verursachten Mehrverbrauch auszugleichen.
Was Anthropic ändern will
- Strengere interne Tests vor Updates, inklusive Soak-Perioden und schrittweisen Rollouts für Änderungen, die das Modellverhalten beeinflussen.
- Jede Anpassung am System-Prompt muss durch eine breite, modellspezifische Eval.
- Mehr Mitarbeiter sollen den öffentlichen Build statt interner Versionen nutzen, damit Regressionen früher auffallen.
- Neuer X-Account @ClaudeDevs für Transparenz bei Änderungen.
Einordnung
Drei harmlose Einzeländerungen — eine Latenz-Notbremse, ein Caching-Refactor, eine Anti-Geschwätzigkeits-Regel — haben sich zu einer mehrwöchigen Qualitätsdelle aufaddiert, die in keinem einzelnen Eval auffiel. Der Vorgang zeigt, wie schwer Regressionen in agentischen Systemen zu fassen sind: Reasoning-Verhalten, Cache-Strategie und Output-Länge greifen ineinander, und „klassische” Tests sehen das nicht. Für Teams, die täglich mit Claude Code arbeiten, ist die wichtigste Lehre weniger das Was als das Wie der Fehlerkette.
Unsere Erfahrung & Empfehlungen
Wir nutzen Claude Code täglich und sehen die Auswirkungen von Opus 4.7 deutlich — auch jenseits dieses Post-Mortems. Im Blog haben wir unsere Beobachtungen zusammengefasst und konkrete Empfehlungen formuliert, wie sich der Token-Hunger und das „Overachieving” des Modells im Alltag eindämmen lassen.
→ Opus 4.7: Anthropics Änderungen, Auswirkungen und unsere Empfehlungen
Entdecke mehr
Opus 4.7 erreicht das Qualitätslevel von 4.6 noch nicht — unsere Empfehlungen
Was wir nach mehreren Wochen Opus 4.7 in der Praxis sehen — Token-Hunger, Overachieving und konkrete Stellschrauben dagegen.
BlogClaude Code: Fast Mode für Opus 4.6 aktivieren — und was er kostet
Fast Mode für Opus 4.6 läuft nur noch über Extra Usage. So aktivierst du ihn — und das ist der wahre Preis dafür.
GlossarAider
Aider ist ein quelloffener KI-Pair-Programmer für die Kommandozeile, der Code direkt im Git-Repository editiert und jede Änderung automatisch committet.