Täglicher Benchmark zur Verfolgung von Leistungsabfällen bei Claude Code

 (marginlab.ai)
9 Punkte von GN⁺ 2026-01-30 | 2 Kommentare | Auf WhatsApp teilen
  • Ein Tracking-System, das die SWE-Aufgabenleistung von Claude Code Opus 4.5 täglich misst, um statistisch signifikante Leistungsabfälle zu erkennen
  • Mithilfe einer ausgewählten Teilmenge von SWE-Bench-Pro werden täglich 50 Testinstanzen ausgewertet; die Ergebnisse spiegeln die tatsächliche Modellleistung bei direkter Ausführung in einer CLI-Umgebung wider
  • In den letzten 30 Tagen wurde eine durchschnittliche Erfolgsquote von 54 % gemessen; gegenüber dem Referenzwert von 58 % wurde ein statistisch signifikanter Rückgang um 4,1 % festgestellt
  • Tägliche und wöchentliche Ergebnisse werden anhand von 95-%-Konfidenzintervallen und Signifikanzschwellen (±14,0 %, ±5,6 %) analysiert, um kurzfristige Schwankungen von langfristigen Trends zu unterscheiden
  • Betrieben von einer unabhängigen Drittorganisation; ein Werkzeug zur frühzeitigen Erkennung von Leistungsabfällen durch Änderungen am Modell oder an der Ausführungsumgebung

Überblick

  • Ziel dieses Trackers ist es, statistisch signifikante Rückgänge in der SWE-Aufgabenleistung von Claude Code Opus 4.5 zu erkennen
    • Die Auswertung erfolgt täglich mit einer kontaminationsresistenten Teilmenge von SWE-Bench-Pro
    • Die Ausführung erfolgt direkt in der Claude Code CLI und bildet ohne separates Custom-Harness die reale Nutzerumgebung ab
  • Unabhängige Drittorganisation, ohne Partnerschaft mit Frontier-Model-Anbietern
  • Wird seit dem Postmortem von Anthropic zu Leistungsabfällen im September 2025 als Ressource betrieben, um ähnliche Fälle künftig frühzeitig zu erkennen

Leistungsübersicht

  • Referenz-Erfolgsquote: 58 %
  • Erfolgsquote der letzten 30 Tage: 54 % (auf Basis von 655 Auswertungen)
  • Erfolgsquote der letzten 7 Tage: 53 % (auf Basis von 250 Auswertungen)
  • Erfolgsquote des letzten Tages: 50 % (auf Basis von 50 Auswertungen)
  • Der Leistungsabfall über 30 Tage ist bei p < 0.05 statistisch signifikant
    • Veränderung über 30 Tage: -4,1 %
    • Signifikanzschwelle: ±3,4 %
  • Die Veränderungen über 1 Tag (-8,0 %) und 7 Tage (-4,8 %) sind nicht statistisch signifikant
Anzeige

Tägliche und wöchentliche Trends

  • Täglicher Trend (Daily Trend)
    • Visualisiert die tägliche Erfolgsquote der letzten 30 Tage
    • Referenzwert 58 %, Signifikanzbereich ±14,0 %
    • 95-%-Konfidenzintervalle können angezeigt werden; je kleiner die Stichprobe, desto breiter das Intervall
  • Wöchentlicher Trend (Weekly Trend)
    • Zeigt mit einem gleitenden 7-Tage-Durchschnitt einen geglätteten Trend zur Reduzierung täglicher Volatilität
    • Referenzwert 58 %, Signifikanzbereich ±5,6 %
    • Ebenfalls mit 95-%-Konfidenzintervallen darstellbar

Änderungsübersicht (Change Overview)

  • 1-Tages-Veränderung (gegenüber gestern): -8,0 %, nicht statistisch signifikant
    • Auf Basis von 50 Auswertungen, erforderlich ist eine Veränderung von ±14,0 % (p < 0.05)
    Anzeige
  • 7-Tage-Veränderung (gegenüber letzter Woche): -4,8 %, nicht statistisch signifikant
    • Auf Basis von 250 Auswertungen, erforderlich ist eine Veränderung von ±5,6 % (p < 0.05)
  • 30-Tage-Veränderung (gegenüber letztem Monat): -4,1 %, statistisch signifikant
    • Auf Basis von 655 Auswertungen, erforderlich ist eine Veränderung von ±3,4 % (p < 0.05)

Methodik (Methodology)

  • Jeder Test wird als Bernoulli-Zufallsvariable modelliert und es werden 95-%-Konfidenzintervalle berechnet
  • Durch die Analyse statistischer Unterschiede bei täglichen, wöchentlichen und monatlichen Erfolgsquoten wird festgestellt, ob ein signifikanter Leistungsabfall vorliegt
  • Die Auswertung erfolgt mit täglich 50 Testinstanzen, daher besteht kurzfristige Volatilität
  • Wöchentliche und monatliche Aggregationen liefern stabilere Schätzwerte
  • Leistungsabfälle sowohl durch Modelländerungen als auch durch Änderungen am Ausführungs-Harness können erkannt werden

Benachrichtigungsfunktion

  • Bei statistisch erkanntem Leistungsabfall werden E-Mail-Benachrichtigungen versendet
  • Nutzer können sich durch Hinterlegen einer E-Mail-Adresse anmelden
  • Nach Bestätigung des Abonnements können Benachrichtigungen empfangen werden; bei Fehlern werden Hinweise zum erneuten Versuch gegeben

Verwandte Beiträge

2 Kommentare

 
iolothebard 2026-01-31

Nicht, dass Claude Code dümmer geworden ist … vielleicht ist es eher so, dass die Person, die es benutzt, gelernt hat, Claude besser zu nutzen …
 
GN⁺ 2026-01-30
Hacker-News-Kommentare

  • Ich bin Thariq aus dem Claude-Code-Team
    Das Harness-Problem, das am 26. Januar auftrat, wurde behoben. Am 28. Januar wurde sofort ein Rollback durchgeführt, daher wird empfohlen, mit dem Befehl claude update auf die neueste Version zu aktualisieren

    • Claude 2.1.x hängt sich häufig auf oder nutzt die CPU zu 100 %, sodass es praktisch unbenutzbar ist. Das zugehörige Issue ist GitHub #18532
    • Ich frage mich, ob es eine Kompensation dafür gibt, dass Claude Tokens verschwendet hat
    • Ich würde gern genauer wissen, was mit „harness issue“ gemeint ist und welche Auswirkungen es hatte
    • Das Problem bestand schon vor dem 26. Januar. Seitdem begann Claude unter dem Vorwand von „Verbesserungen“ Pläne eigenmächtig zu ändern
    • Mich interessiert weniger das Modell selbst als vielmehr das Qualitätssicherungssystem. Gibt es einen internen Prozess, bei dem reale Output-Beispiele regelmäßig geprüft oder Benchmarks verwendet werden, um Leistungsabfälle zu überwachen? Auch aus Sicht der AI-Sicherheit ist eine solche Validierung unverzichtbar

  • Ich bin Mitautor von SWE-bench
    Aktuell scheinen die Tests nur einmal täglich und nur mit 50 Aufgaben zu laufen. Um die Genauigkeit zu erhöhen, sollte man 300 Aufgaben 5–10 Mal pro Tag testen und dann den Durchschnitt bilden. Zufallsfaktoren wie Serverlast können die Ergebnisse stark beeinflussen

    • Sollte ein Leistungsabfall durch Serverüberlastung nicht ebenfalls Gegenstand der Messung sein? Zumindest wenn man nicht ausschließlich Model Distillation messen will
    • Vermutlich sind die Kosten für die Modellausführung das Problem. Es wäre gut, wenn Anthropic etwas Credit-Unterstützung geben oder einen Spendenlink einrichten würde
    • Je nach Tageszeit könnten die Leistungsunterschiede noch größer sein
    • Es gibt die Sorge, dass die Ausführung von SWE-bench zu teuer ist, um sie oft genug laufen zu lassen. Bei mafia-arena.com gibt es ein ähnliches Problem
    • Die Aussage „Der Server ist überlastet, daher ist die Messung ungenau“ wirkt seltsam. Gibt es dann überhaupt Arbeitszeiten, in denen Claude zuverlässig funktioniert?

  • Eine Zusammenfassung, warum ich nicht glaube, dass Anthropic den Nutzern absichtlich ein schlechteres Modell liefert

    1. Der Genauigkeitsrückgang ist klein und verläuft oszillierend auf und ab
    2. Es gibt keinen Vergleichsmaßstab für Sonnet 4.5, und bei hoher GPU-Last könnte Opus auf Sonnet-Niveau absinken
    3. Es ist sehr wahrscheinlich, dass mehrere Checkpoints per A/B-Test ausprobiert werden. Auch Updates der Claude-Code-Version oder die Nichtdeterministik beim Token-Sampling könnten die Ursache sein
    • Ich verstehe die wissenschaftliche Erklärung, aber wenn man es täglich nutzt, hat man eindeutig das Gefühl, dass die Leistung schlechter wird
    • Ich denke auch, dass A/B-Tests die Hauptursache sind. Es wäre gut, wenn Dinge wie Context-Window-Limits oder Änderungen am System Prompt transparent offengelegt würden. Ideal wäre, wenn Nutzer selbst Versionen auswählen und Feedback geben könnten
    • Ich frage mich, warum der Graph am 8. Januar beginnt. Das könnte ein ungewöhnlich hoher Tag gewesen sein
    • Es könnte auch eine Struktur sein, die je nach Last automatisch die Leistungs-Kosten-Abstimmung ändert. Vielleicht startet das System zunächst mit hoher Leistung und skaliert das Modell dann schrittweise herunter, um Kosten zu sparen, oder reduziert die Anzahl der MoE-Experten
    • Die Behauptung, der „Rückgang sei zu klein“, ist nur eine subjektive Einschätzung, die statistische Signifikanz ignoriert

  • Die statistische Methodik ist seltsam
    Sie betrachten offenbar nur das Konfidenzintervall früherer Werte und prüfen, ob der neue Wert außerhalb davon liegt, aber das ist keine korrekte Methode, um die statistische Signifikanz einer Differenz zu testen. Da beide Messungen Unsicherheit enthalten, muss man das Konfidenzintervall der Differenz selbst berechnen. Wenn man zudem monatliche Vergleiche anstellen will, sollte man Daten von vor 60–31 Tagen mit Daten von vor 30 Tagen bis gestern vergleichen, also müsste der Graph mindestens zwei Monate zeigen

  • Vor etwa einer Woche war Claude ungefähr eine Stunde lang down. Direkt nach der Wiederherstellung war es wohl wegen der geringeren Nutzerzahl mehr als dreimal so schnell. In dieser einen Stunde habe ich so viel geschafft wie sonst in einem halben Tag. Es fühlte sich an wie ein kurzer Blick in eine Zukunft ohne Ressourcenbeschränkungen

    • Auch während US-Feiertagen wurden die Nutzungslimits gelockert, und alles lief viel flüssiger
    • Ich hatte vor ein paar Tagen dieselbe Erfahrung. Es war so schnell, dass ich sogar nach „claude speed boost“ gesucht habe. Es war wie die momentane Blitzgeschwindigkeit bei früheren Modem-Upgrades
    • Wenn es zu schnell wird, ist es fast schon schade. Im Moment fühlt es sich wenigstens so an, als würde das Modell hart arbeiten

  • Wenn man in Nutzer-Prompts die Häufigkeit von Schimpfwörtern misst, könnte man bei sinkender Modellleistung einen Anstieg der Feindseligkeit der Nutzer erkennen

    • Aber gibt es überhaupt eine Möglichkeit, Claude-Nutzerprompts „einfach so“ zu scannen?
    • Es gibt eine Korrelation zwischen mehr Schimpfwörtern und direkten Feedback-Anfragen wie „How’s Claude Doing This Session?“
    • Ich fluche ohnehin oft, also könnten meine Daten verzerrt sein
    • Gut zu wissen, dass ich nicht der Einzige bin
    • Manchmal rutscht mir ein Fluch raus, wenn es eine so dumme Antwort gibt. Das liegt an den hohen Erwartungen

  • Es ist möglich, dass das Modell im Laufe der Zeit schrittweise quantisiert (quantization) wird. Das würde Skalierung und Kostensenkung erleichtern und zugleich den Effekt erzeugen, dass neue Versionen „besser aussehen“

    • Ich nutze es täglich 5–10 Stunden, und in der letzten Woche hatte ich eindeutig das Gefühl, dass es dümmer geworden ist. Auch wenn sie es bestreiten, fühlt sich die Veränderung real an
    • Man muss nicht einmal quantisieren; man könnte die Last auch durch verkürzte Gespräche oder kürzere Inferenzzeit senken
    • Open-Modelle wie GPT-OSS oder Kimi K2.x wurden ebenfalls mit 4-Bit-Layern trainiert. Opus 4.5 ist pro Token 8-mal teurer, daher ist es wahrscheinlich ein größeres Modell, aber wegen der Preisstruktur von Abos ist ein einfacher Vergleich schwierig
    • Anthropic wirkt nicht wie ein Unternehmen, das bei Infrastrukturkosten so stark eingeschränkt wäre. In einer Situation mit hartem Wettbewerb wäre es eine schlechte Strategie, die Qualität absichtlich zu senken. Vielleicht erkennen Nutzer nach dem „Honeymoon-Effekt“ die Schwächen einfach besser
    • Trotzdem wirkt eine solche Strategie des schrittweisen Abbaus durchaus plausibel. So ließe sich der relative Verbesserungseffekt neuer Modelle maximieren

  • Im API-Modus wird Claude ab einer bestimmten Token-Zahl plötzlich dümmer und verhält sich dann seltsam, etwa indem es behauptet, „in Zeile 23 ist ein Bug“, und anschließend die gesamte Funktion löscht. Es scheitert sogar an einfachen Änderungen, die selbst mit ChatGPT 3.5 möglich wären. Ich kann nicht verstehen, warum das passiert

    • Vermutlich liegt es an Ressourcenbeschränkungen. Statt einigen wenigen Nutzern sehr gute Antworten zu geben, hat man sich wohl dafür entschieden, mehr Nutzern einigermaßen gute Antworten zu liefern
    • Ich hatte dieselbe Erfahrung. Claude wirkt zunehmend träge

  • In der letzten Woche hat sich die Code-Qualität von Claude spürbar verschlechtert. Zum Beispiel empfiehlt es, bei einem Enum frozen zu verwenden, oder schlägt in einer Funktion, die bereits urlparse nutzt, erneut urlparse vor. Früher machte es solche grundlegenden Fehler nicht

  • Ein großer Frustpunkt bei LLM-Anbietern ist die mangelnde Konsistenz der Inferenzfähigkeit. Auch bei ChatGPT sinkt die Intelligenz bei Eingaben über 45k Tokens abrupt oder Teile der Eingabe werden abgeschnitten. Eine „Ablehnung“-Meldung wäre besser, als heimlich herabgestuft zu werden, denn so geht Vertrauen verloren. Transparenz ist wirklich entscheidend