Claudes März-Krise: Wenn Wachstum die Infrastruktur überholt

Ende März 2026. Claude ist das beste Sprachmodell auf dem Markt — und gleichzeitig kaum benutzbar. Was als „Spring Break“-Promotion begann, hat sich zur größten Vertrauenskrise in Anthropics Geschichte entwickelt. Aber die eigentliche Geschichte ist nicht die, die in den Tech-Medien steht.

Die Schlagzeilen drehen sich um Rate Limits: Session-Budgets, die in Minuten statt Stunden verfallen, $200/Monat-Abonnenten, die nach drei Prompts ausgesperrt werden. Das ist ärgerlich, aber für europäische Nutzer oft kein direktes Problem — das Peak-Hour-Fenster (5–11 AM PT, also 14–20 Uhr CET) trifft uns nur am Nachmittag. Was mich als täglichen Power-User wirklich trifft: Claude wird dümmer. Nicht metaphorisch. Messbar.

Die Promotion, die nach hinten losging

Am 13. März startete Anthropic eine zweiwöchige Aktion: doppelte Usage-Limits außerhalb der Spitzenzeiten für alle Pläne — Free, Pro, Max, Team. Die offizielle Promo-Seite klingt großzügig. War es auch, isoliert betrachtet. Das Problem: Gleichzeitig wurden die Peak-Hour-Limits still und heimlich verschärft. Drei Tage lang wusste niemand davon. Erst am 26. März bestätigte Anthropic-Mitarbeiter Thariq Shihipar — nicht per Blog-Post, nicht per E-Mail, sondern in einem X-Post — dass 5-Stunden-Sessions während der Spitzenzeiten absichtlich schneller verbraucht werden.

Die Hintergrundgeschichte: Nach OpenAIs Pentagon-Vertrag Ende Februar explodierten die ChatGPT-Deinstallationen um 295% an einem einzigen Tag. Die #QuitGPT-Bewegung trieb Millionen neuer Nutzer zu Claude. Die App erreichte Platz 1 im US App Store. Anthropics annualisierter Umsatz sprang auf $19 Milliarden. Aber GPU-Kapazität skaliert nicht über Nacht. Der Blogger J.D. Hodges brachte es auf den Punkt: Man kann 100.000 neue Abonnenten über Nacht gewinnen, aber nicht 100.000 GPUs an Inferenz-Kapazität. Irgendwo muss die Lücke sichtbar werden — als langsamere Antworten, niedrigere Qualität oder striktere Limits.

Die Ironie dabei ist zum Haareraufen. Die #QuitGPT-Fraktion wollte ein moralisches Zeichen setzen — und hat das genaue Gegenteil erreicht. Indem Millionen Nutzer OpenAI den Rücken kehrten, haben sie OpenAIs Kapazitäten entlastet. Weniger Consumer-Last auf den GPUs bedeutet mehr freie Rechenzeit für genau den Kunden, gegen den protestiert wurde: das US-Militär. Man hat dem Pentagon quasi einen Gefallen getan und gleichzeitig den einzigen Anbieter in die Knie gezwungen, der den Pentagon-Deal abgelehnt hatte. Glückwunsch.

Wer es wirklich ernst gemeint hätte mit dem Protest, hätte die Strategie umdrehen müssen: Nicht weggehen, sondern bleiben. Jeden Freund, jede Bekannte überreden, sich bei OpenAI anzumelden und die Kapazitäten aufzuzehren. Statt dessen: Massenflucht zu Anthropic, wo die Infrastruktur auf den Ansturm nicht vorbereitet war, während OpenAI plötzlich Luft zum Atmen hatte. Strategisches Denken sieht anders aus. Aber Hauptsache, man konnte einen Screenshot der Deinstallation posten. Ganz großes Kino.

Das eigentliche Problem: Qualitätsverlust unter Last

Rate Limits sind nervig, aber planbar. Was nicht planbar ist: Wenn dasselbe Modell, das vor einer Minute eine Aufgabe sauber gelöst hat, dieselbe Aufgabe plötzlich nicht mehr hinbekommt. Und genau das passiert gerade. Nicht sporadisch — reproduzierbar, über Sessions hinweg, bei mir und offensichtlich bei tausenden anderen.

Die Ursachen sind mehrschichtig, und Anthropic schweigt zu den meisten davon.

Context Rot: Das 1M-Token-Versprechen ist eine Mogelpackung

Anthropic bewirbt ein 1-Million-Token-Kontextfenster für Opus 4.6. Was sie in der Werbung nicht prominent erwähnen: Die Qualität degradiert massiv, lange bevor dieses Fenster voll ist. Anthropics eigene API-Dokumentation räumt ein, dass mit steigender Token-Zahl Genauigkeit und Recall abnehmen — ein Phänomen, das sie selbst „Context Rot“ nennen. Die „Krücke“ dafür nennt man dann „Context Engineering“

Die Zahlen aus GitHub-Issue #35296: Zuverlässige Performance im Bereich 0–256K Token. Danach progressive Degradierung. Bei 1M Token scheitert jede vierte Multi-Needle-Retrieval-Abfrage — und das auf einem synthetischen Benchmark. In realen Coding-Sessions mit Tool-Calls, Fehlermeldungen und Konversationshistorie ist es deutlich schlimmer.

Noch konkreter: Die Performance beginnt laut unabhängigen Analysen bei etwa 147.000 Token zu degradieren. Nicht bei 200K, nicht bei 500K. Bei 147K. Die Auto-Compaction feuert deshalb jetzt bei 64–75% Kapazität statt bei 90% — weil Anthropic selbst weiß, dass das Modell ab diesem Punkt in einem degradierten Zustand arbeitet. Diese Daten sind offenbar vor dem 1 Mio Token Kontext – da wird nochmal deutlich, dass das nichts als eine Mogelpackung ist.

Für Power-User mit MCP-Servern wird es richtig eng: Eine saubere Session ohne MCP bietet ~160–170K Token Arbeitsbudget. Mit 5 MCP-Servern sinkt das auf 120–130K. Mit 9 MCP-Servern können 50.000+ Token allein für Tool-Schemas draufgehen, bevor man ein Wort getippt hat. Das effektive Arbeitsbudget in einer typischen Session mit mehreren MCP-Servern liegt bei 100–120K Token — und die Degradierung beginnt bei 147K. Die Marge ist hauchdünn.

Forschung zu Context Rot zeigt außerdem unterschiedliche Degradierungsmuster je nach Füllgrad: Unter 50% verliert das Modell Token in der Mitte des Kontexts („Lost in the Middle“-Problem). Über 50% gehen die frühesten Token verloren — also typischerweise die initialen Instruktionen, CLAUDE.md-Regeln und Session-Ziele. Das erklärt, warum Claude nach einer halben Stunde Instruktionen ignoriert, die zu Beginn der Session perfekt befolgt wurden.

Trial-and-Error statt Reasoning: Der Opus-4.6-Rückschritt

Seit dem Release von Opus 4.6 Anfang Februar häufen sich Berichte über einen fundamentalen Verhaltenswechsel: Das Modell denkt weniger nach und probiert mehr aus. Statt ein Problem einmal durchzudenken und eine funktionierende Lösung zu liefern, startet es Trial-and-Error-Schleifen, die 20+ gescheiterte Versuche produzieren. Bereits Ende Januar dokumentierte GitHub-Issue #21431 das Muster: „Expected: Think through the problem once, deliver working solution. Actual: Trial-and-error debugging that wasted time.“

Ein professioneller Nutzer dokumentierte den Verfall in GitHub-Issue #28469 mit chirurgischer Präzision: Dieselbe Aufgabe — „SSH auf NAS, Disk-Usage prüfen“ — die unter Opus 4.5 ein einziger Turn war (SSH, df -h, fertig), braucht unter Opus 4.6 plötzlich 5–8 Turns: CLAUDE.md lesen, MEMORY.md lesen, einen Explore-Agent spawnen, SSH-Config lesen, um Erlaubnis fragen, drei überflüssige Befehle ausführen, dann endlich df -h. Seine Produktivitätsschätzung: 50–60% Rückgang seit Opus 4.6.

Das Muster ist immer dasselbe: Claude versucht Ansatz A, scheitert. Man erklärt warum. Zwei bis drei Turns später versucht Claude Ansatz A erneut — manchmal wortgleich. Das ist keine Halluzination im klassischen Sinne. Es ist ein Failure-Loop, der darauf hindeutet, dass das Modell weniger Reasoning-Budget bekommt als früher. Die Analyse von AlphaGuru bringt es auf den Punkt: Das Modell ist nicht dümmer — es bekommt weniger Zeit zum Denken. Es überspringt die tiefe Analyse und springt direkt zur Aktion.

Ein besonders bitteres Detail aus Issue #28469: Nach einer Context-Compaction liest Claude die CLAUDE.md und MEMORY.md erneut ein, zeigt deren Inhalt im Tool-Output — und verletzt die darin enthaltenen Regeln im unmittelbar nächsten Turn. Die Instruktion steht literally im Kontext, und das Modell ignoriert sie trotzdem. Für jemanden, der produktionskritische Regeln in diesen Dateien hinterlegt hat („Niemals main/master pushen, immer branch nutzen“), ist das ein Safety-Problem, kein Komfort-Problem.

Sub-Agent-Hänger: Architektonische Schwächen

Wer mit Claude Code Sub-Agents arbeitet — und das ist zunehmend der Standard-Workflow für komplexere Aufgaben — kennt das Muster: Ein Sub-Agent wird gestartet, arbeitet, und dann… nichts mehr. Der Spinner (das animierte Symbol heißt so, von englisch „to spin/spinning“ – drehen/drehend) dreht sich. Der Haupt-Agent wartet. Keine Fehlermeldung, kein Timeout, keine Recovery. Erst ein manueller Interrupt (/btw oder Ctrl+C) bringt das System wieder in Bewegung.

Das ist kein Edge-Case. Es gibt mindestens vier dokumentierte Failure-Modes:

Stream-Freeze: Die API-Streaming-Verbindung bleibt mitten in der Übertragung stehen. Der Prozess lebt (steckt in epoll_wait), aber es kommen keine Tokens mehr an. Kein Fehler wird gemeldet. Die Session kann sich nicht selbst recovern — nur kill -9 hilft. GitHub-Issue #25979 dokumentiert einen spezifischen Trigger: Wenn eine Background-Agent-Notification genau am Ende eines Turns oder zwischen Turns eintrifft, hat der nächste API-Call eine hohe Wahrscheinlichkeit zu hängen.

Fehlender Timeout im Task-Tool: Wie in OpenCode-Issue #13841 im Detail analysiert, wartet das Task-Tool, das Sub-Agents spawnt, auf den gesamten Sub-Agent-Run — ohne jeglichen Timeout-Wrapper. Der Abort-Mechanismus feuert nur, wenn der Nutzer die Parent-Session manuell abbricht. Der Sub-Agent erbt keinen Tool-Level-Timeout. Das ist kein Bug — das ist eine architektonische Lücke.

Permission-Prompt-Deadlock: GitHub-Issue #7091 dokumentiert: Wenn ein Sub-Agent einen Edit-Approval triggert, hängt der Haupt-Agent auf unbestimmte Zeit. ESC funktioniert nicht. Der einzige Ausweg ist Ctrl+C und eine neue Session. Bonus-Bug: Eine einzige Ablehnung eines Sub-Agent-Edits propagiert fälschlicherweise auf alle wartenden Sub-Agents.

Unsichtbare Sub-Agents nach Compaction: Die März-Release-Notes bestätigen einen Fix für „Background Subagents, die nach Context-Compaction unsichtbar werden, was dazu führen konnte, dass doppelte Agents gespawnt wurden.“ Ebenfalls gefixt: „MCP Tool Calls, die auf unbestimmte Zeit hängen, wenn eine SSE-Verbindung mitten im Call abbricht“ und „eine Race Condition, bei der Background-Agent-Task-Output auf unbestimmte Zeit hängen konnte, wenn der Task zwischen Polling-Intervallen abschloss.“

Die März-Release-Notes listen insgesamt über ein Dutzend Fixes für Hang- und Race-Condition-Bugs auf. Das zeigt, dass Anthropic die Probleme kennt. Aber es ist ein Whack-a-Mole-Spiel: 13 Releases in drei Wochen (v2.1.70–2.1.83), und der Changelog enthält keinen einzigen Fix für Context-Degradierung, keine Wiederherstellung der Thinking-Depth-Kontrolle und keine Infrastruktur-Stabilitätsankündigungen.

Die Routing-Hypothese: Quantisierung unter Last?

Die unbequemste Frage, die Anthropic konsequent nicht beantwortet: Werden verschiedene Modellversionen oder Quantisierungsstufen je nach Serverlast ausgeliefert?

Anthropics offizielle Linie aus dem August-2025-Postmortem: „We never reduce model quality due to demand, time of day, or server load.“ Aber das war vor dem März-Debakel. Entwickler Ahmad Osman spekuliert auf X offen über dynamische Anpassungen während der Spitzenzeiten — Quantisierung der Modellgewichte auf Int4 oder 1.58-bit, KV-Cache-Quantisierung, oder Routing zu destillierten/kleineren Modellen. Ein GitHub-Issue (#21427) fragte direkt, ob unterschiedliche Modellversionen zu verschiedenen Tageszeiten ausgeliefert werden — keine offizielle Antwort.

Anekdotische Evidenz gibt es reichlich: Mehrere Entwickler berichten, dass ihre besten Claude-Sessions nachts oder am frühen Morgen stattfinden. Ein Entwickler dokumentierte auf Grizzly Peak Software, dass seine produktivsten Sessions zwischen 22 Uhr und 2 Uhr nachts (Alaska Time) liegen — bei geringerer Last, möglicherweise auf Full-Precision-Instanzen. Aus dem August-Postmortem wissen wir, dass Anthropic tatsächlich verschiedene Server-Pools für Short- und Long-Context-Requests betreibt und dass fehlerhafte Routing-Logik ~30% der Claude-Code-Nutzer betreffen konnte, wenn Requests an falsche Server-Typen gingen. Das Routing war „sticky“ — einmal falsch geroutet, folgten Nachfrage-Requests demselben falschen Pfad.

Ob sie es nun offiziell tun oder nicht: Die Symptome sind konsistent mit Load-basiertem Routing. Und die Weigerung, die Frage direkt zu beantworten, macht die Sache nicht besser.

Anthropics Kommunikationsversagen

Was dieses Desaster von einem normalen Scaling-Problem unterscheidet, ist die Kommunikation — oder deren Ausbleiben.

Drei Tage lang wussten zahlende Kunden nicht, was mit ihrem Service passierte. Die offizielle Bestätigung kam per X-Thread eines einzelnen Mitarbeiters. Kein Blog-Post, kein E-Mail-Update, keine Statusseite-Erklärung. CEO Dario Amodei hat sich nicht geäußert. PiunikaWeb brachte es auf den Punkt: Für Leute, die $200/Monat zahlen, ist es ziemlich hart, einen Post auf X checken zu müssen, um zu erfahren, was mit ihren Usage-Limits los ist.

Die 90-Tage-Uptime-Zahlen zum 27. März sprechen für sich: claude.ai bei 98,98%, Claude API bei 99,06%, Claude Code bei 99,3%. Alles mit „Major Outage“-Status markiert. Allein im März gab es dokumentierte Incidents am 2., 11., 17.–19., 20.–22., 25. und 27. — das ist kein „gelegentlicher Ausfall“, das ist ein Pattern.

Besonders bitter: Am selben Tag, an dem Anthropic die Limit-Verschärfung einräumte, setzte OpenAI die Codex-Usage-Limits für alle Nutzer kostenlos zurück — als Goodwill-Geste für neue Plugins. Keine Bedingungen, keine Peak-Hour-Einschränkungen. Einfach ein Reset. Das PR-Problem könnte für Anthropic kaum größer sein.

Die Infrastruktur-Lücke

Die tiefste Ironie der März-Krise: Sie ist ein Erfolgsproblem, kein Versagen. Claude ist das beste verfügbare Modell für Coding und analytische Aufgaben. Die ethische Haltung von Anthropic generiert echte Nutzerloyalität. Aber die Infrastruktur kommt nicht hinterher.

Die Pipeline ist massiv: Eine $50-Milliarden-Partnerschaft mit Fluidstack für Custom-Rechenzentren in Texas und New York, Zugang zu bis zu 1 Million Google-Cloud-TPU-Chips, AWS Project Rainier mit 500.000+ Trainium2-Chips, und ein $30-Milliarden Microsoft-Azure-Commitment. Aber diese Kapazitäten kommen im Laufe von 2026 online — nicht heute.

Derweil versucht Anthropic, den Gap mit Promotions, Limit-Umverteilung und Feature-Offensive zu überbrücken: Voice-Mode, Plugin-Marketplace, Excel/PowerPoint-Integration, Claude in Chrome, Cowork — 13 Releases in drei Wochen. Die Priorität liegt klar auf Wachstum und Feature-Parität mit der Konkurrenz. Stabilität und Inferenz-Qualität für Bestandskunden stehen offensichtlich nicht an erster Stelle.

Was hilft — Stand jetzt

Anthropic wird das Compute-Problem nicht über Nacht lösen. Für den Alltag gibt es ein paar Stellschrauben, die den Unterschied zwischen produktiver Session und Frustration ausmachen:

Context aktiv managen. /context regelmäßig prüfen. Bei 60% Füllgrad handeln, nicht erst bei 90%. /compact proaktiv nutzen — nicht warten, bis die Auto-Compaction feuert, denn die läuft bereits in einem degradierten Zustand. /compact akzeptiert einen Custom-Prompt, der die Zusammenfassung auf die relevanten Aspekte fokussiert. Das ist der unterschätzteste Hebel. Abgesehen von diesen Tipps habe ich mein Context-Window auf 20% (also 200k Tokens, wie früher) begrenzt. Was soll ich mit einer Mio Tokens wenn dreiviertel davon verrotten? Zudem starte ich Claude Code nach jedem Feature neu – nicht ganz optimal, weil er sich dann erst wieder zurechtfinden muss, beim aktuellen trial-and-error-statt-denken auch nicht so prickelnd, aber immer noch besser als mit einem völlig dementen Model zu arbeiten.

Also, Sessions kurz halten. 30-Minuten-Sprints mit einem Ziel pro Sprint. Eine Feature, ein Bug, ein Modul. Dann compacten oder clearen. Eine 30-Minuten-Session verbraucht typischerweise 50–80K Token — deutlich unter der 147K-Degradierungsschwelle.

MCP-Server-Last kennen. Jeder MCP-Server kostet Token für Tool-Schemas. Wer 9 Server geladen hat, verbrennt 50K+ Token, bevor der erste Prompt abgeschickt wird. Server nur laden, wenn sie für die aktuelle Aufgabe gebraucht werden.

CLAUDE.md schlank und aktuell halten. Eine AGENTbench-Studie zeigt, dass LLM-generierte Context-Files die Erfolgsrate sogar senken können. Drei Monate akkumulierte Instruktionen, die eine Codebasis beschreiben, die sich längst weiterentwickelt hat, machen das Modell schlechter, nicht besser.

Sub-Agent-Hänger einplanen. /btw als manueller Nudge, wenn der Spinner zu lange dreht. Für automatisierte Workflows: Hooks und externe Watchdogs, die JSONL-Session-Files auf Inaktivität überwachen. Es gibt keinen eingebauten Timeout — man muss selbst dafür sorgen.

Multi-Model-Strategie. Claude für die schweren Aufgaben, bei denen die Reasoning-Qualität den Unterschied macht. Für den Alltag: Gemini CLI (kostenlos, 1000 Requests/Tag, 1M Token Context), OpenAI Codex ($20/Monat mit ChatGPT Plus), oder lokale Modelle für Rate-Limit-Freiheit. Nicht entweder-oder — sowohl-als-auch.

Fazit

März 2026 markiert einen Wendepunkt für Anthropic. Das Unternehmen hat sich in eine Position manövriert, in der es gleichzeitig das beste Modell am Markt hat und das schlechteste Nutzererlebnis für Power-User liefert. Die technische Überlegenheit von Claude Opus 4.6 steht außer Frage — wenn es funktioniert. Aber „wenn es funktioniert“ ist kein akzeptabler Zustand für ein $19-Milliarden-Unternehmen, das $200/Monat für eine Subscription verlangt.

Die Lektion für die gesamte AI-Branche ist klar: Usage-Limits und Inferenz-Qualität unter Last — nicht Benchmark-Scores — werden zum primären Schlachtfeld für Subscriber-Retention. Wer das Compute-Demand-Problem zuerst löst — oder zumindest am ehrlichsten darüber kommuniziert — wird das nächste Kapitel der AI-Subscription-Wars definieren.

Anthropic hat die Infrastruktur-Pipeline, um das Problem zu lösen. Was sie noch nicht haben, ist die Kommunikations-Infrastruktur, um ihren zahlenden Kunden in der Zwischenzeit das Gefühl zu geben, dass sie ernst genommen werden. Ein X-Thread eines einzelnen Mitarbeiters ist kein Krisenkommunikationsplan.

Stand: 27. März 2026. Die Spring-Break-Promotion endet am 28. März. Was danach passiert, wird zeigen, ob Anthropic aus dem März gelernt hat.

Quellen