Zusammenfassung
- Der Vorfall zu Opus 4.8 und Haiku 4.5 dauerte von 13:37:28Z bis 15:23:37Z.
- Haiku 4.5 erholte sich vor Opus 4.8 und vor dem vollständigen Abschluss des ersten Berichts.
- Ein separater Sonnet-5-Vorfall begann um 15:24:05Z, 28 Sekunden später, und endete um 16:12:32Z.
- Beide Berichte nannten claude.ai, Console, API, Claude Code und Cowork.
- Anthropic veröffentlichte keine gemeinsame Ursache, Nutzerzahl, Fehlerquote, Feststellung zu Datenverlust oder Gutschrift.
Saubere Incident-Zählung verhindert, dass aus zeitlicher Nähe eine technische Erklärung wird. Kunden können eine beinahe durchgehende Unsicherheit erlebt haben: Eine Warteschlange, die beim grünen Status wieder anlief, traf Sekunden später auf den nächsten Bericht. Das macht die Betriebsphase eng zusammenhängend, die beiden veröffentlichten Lebenszyklen aber nicht identisch.
Anthropic vergab getrennte IDs und unterschiedliche Modellumfänge. Der erste Bericht betraf Opus und Haiku, der zweite Sonnet. Wer sie zusammenführt, entfernt belegte Unterschiede und fügt eine gemeinsame Ursache hinzu, für die es keine öffentliche Aussage gibt.
Der erste Bericht zeigte eine gestaffelte Erholung
Der Opus/Haiku-Bericht begann um 13:37:28Z mit geringem Einfluss. Nach der Identifizierung meldete Anthropic, dass Haiku 4.5 wiederhergestellt sei, während Opus 4.8 noch erhöhte Fehler aufweise. Um 15:06:53Z wechselte der Eintrag in die Beobachtung und um 15:23:37Z wurde er geschlossen.
Diese Reihenfolge ist für modellfähiges Routing wichtig. Ein Client hätte Haiku mit kleinen synthetischen Anfragen prüfen und geeignete Aufgaben vorsichtig zurückführen können. Arbeiten, die Opus verlangten, mussten dagegen warten oder auf eine kompatible Alternative ausweichen. Ein einziger globaler Gesundheitswert hätte die Teilwiederherstellung ebenso verdeckt wie das verbleibende Risiko.
Als betroffene Oberflächen erschienen claude.ai, Console, API, Claude Code und Cowork. Daraus folgt nicht, dass jede Anfrage in allen fünf Angeboten fehlschlug. Auch „gering“ ist keine Nutzerzahl. Anthropic nannte weder Fehlerprozentsatz noch Region, Warteschlangenlänge oder wirtschaftliche Auswirkung.
28 Sekunden dokumentieren eine Grenze, keine Kausalität
Der Sonnet-5-Bericht startete um 15:24:05Z, wurde um 15:36:57Z als identifiziert markiert und um 16:12:32Z gelöst. Er war ebenfalls als gering eingestuft und führte dieselben fünf Oberflächen auf. Die strukturierte Status-API bewahrt Zeitstempel mit Millisekunden, wodurch der Abstand genau berechnet werden kann.
Die Präzision der Uhr erklärt nicht den Fehler. Anthropic sagte nicht, dass die Opus-Reparatur Sonnet beeinträchtigte oder dass ein Defekt zwischen Modellen wanderte. Getrennte IDs, Modellumfänge und Zustandsfolgen bleiben die belastbaren Angaben.
Verantwortlich ist daher eine enge Formulierung: Nutzer mehrerer Claude-Modelle trafen auf angrenzende Fehlerberichte, ohne praktisch nutzbare Zeit für den Vertrauensaufbau. Diese Aussage reicht für eine Resilienzanalyse und benötigt keine erfundene gemeinsame Root Cause.
Provider-Grün ist nur ein Eingangssignal
Vor dem Freigeben eines Rückstaus kann ein Team eine Folge erfolgreicher synthetischer Anfragen an genau das verwendete Modell, die Schnittstelle und die Region verlangen. Es kann den Verkehr stufenweise öffnen, Idempotenzschlüssel erhalten, Wiederholungen begrenzen und ein alternatives Modell oder einen zweiten Anbieter für ersetzbare Aufgaben bereithalten.
Der Gesundheitszustand sollte mindestens nach Modell und Oberfläche getrennt sein. Bei empfindlichen Arbeitslasten gehören Werkzeugnutzung, Kontextlänge und Betriebsart hinzu. Eine kurze erfolgreiche API-Anfrage beweist nicht, dass ein langer Claude-Code-Lauf oder eine Cowork-Aufgabe wieder funktioniert.
Haiku kam vor Opus zurück; unmittelbar danach bekam Sonnet einen eigenen Bericht. Diese Abfolge zeigt, warum „Claude gesund“ zu grob ist. Fehlerrate, Latenz, Alter der Warteschlange und fachliche Abschlussrate des Kunden müssen die Provider-Seite ergänzen.
Gleiche Oberflächen belegen keine gleiche Ursache
Die wiederholte Liste kann zeigen, dass modellbezogene Fehler über dieselben Zugangskanäle sichtbar wurden. Sie kann ebenso die Kategorisierung der Statusseite oder gemeinsam genutzte Produktflächen widerspiegeln. Ohne Architekturdetails, Metriken und Root Cause lässt sich zwischen diesen Erklärungen nicht entscheiden.
Die beiden Ereignisse liegen nach dem Stichtag der vier früher von BTW erfassten Berichte. Sie sind eine neue Wiederholung, kein rückwirkender Beleg für einen einzigen Dauerfehler. Wiederholung kann strengere Redundanz rechtfertigen; sie vereinheitlicht nicht automatisch die Diagnose.
Fehlende Zahlen setzen die analytische Grenze
Anthropic veröffentlichte keine gemeinsame Ursache, betroffene Nutzer, Fehlerquote, regionale Aufteilung, Datenverlustfeststellung oder SLA-Behandlung. Daraus lässt sich weder vertragliche Verfügbarkeit berechnen noch Kapazitätsmangel oder Gesamtschaden ableiten.
Messbar ist die Sequenz: ungefähr eine Stunde und 46 Minuten für den ersten Bericht, 28 Sekunden Abstand und rund 48 Minuten für den zweiten. Die Statusseite legt die Vorfallsidentität des Anbieters fest. Wann reale Arbeit sicher wieder beginnt, muss der Kunde mit eigenen Prüfungen, Routing und Warteschlangenregeln bestimmen.