Anthropic zufolge wurden seine Claude-Apps dreimal schneller: Was sich geändert hat

Anthropic zufolge verkürzte ein zweiwöchiger Sprint im August die Dauer zentraler Aufgaben in claude.ai und der Claude-Desktop-App auf etwa ein Drittel. Der am 23. September veröffentlichte technische Bericht liefert mehr als nur die Schlagzeilenzahl: Er zeigt, welche Vorgänge beschleunigt wurden, wie das Team seine Messungen prüfte und bei welchen Entscheidungen und Freigaben die Verantwortung bei den Ingenieuren blieb.

Die große Veränderung

• Was sich geändert hat: Anthropic berichtet von kürzeren Wartezeiten in 13 Messungen typischer Aktionen im Web und auf dem Desktop. Der Faktor 3,1 ist das geometrische Mittel dieser Verbesserungen, gemessen am 13. und 27. August beim 75. Perzentil. Es handelt sich um ein Unternehmensergebnis für ausgewählte Nutzungsvorgänge.
• Warum das wichtig ist: Für Claude-Nutzer macht es einen Unterschied, wenn eine neu geladene Webseite nach 550 statt 3.085 Millisekunden Texteingaben zulässt. Für Entwicklungsteams zeigt dieses Beispiel, wie ein KI-Assistent anhand gemessener Leistungsprobleme mitarbeitet, während Menschen Prioritäten festlegen und Änderungen genehmigen.
• Worauf zu achten ist: Nach Angaben von Anthropic müssen das 95. Perzentil, weitere Nutzungsvorgänge und sehr lange Gespräche noch verbessert werden. Diese Messwerte werden zeigen, ob die berichteten Fortschritte über die ausgewählten Aktionen und den Augustvergleich hinausreichen.

Was Nutzer hinzugewannen

Anthropic zufolge entfallen 95 Prozent der Nutzeraktivität auf vier Abläufe: die App starten, ein Gespräch beginnen, ein Gespräch laden und eine Nachricht senden. Daraus entstanden 13 Messungen über Web, Desktop und verschiedene Produkte hinweg. Jede begann mit einer Nutzeraktion und endete, wenn das Ergebnis angezeigt wurde; Client- und Serverarbeit wurden getrennt erfasst.

Beim Laden einer neuen Seite in claude.ai sank die Zeit bis zu einer für Texteingaben bereiten Seite beim 75. Perzentil von 3.085 auf 550 Millisekunden, also um den Faktor 5,6. Ein Kaltstart der Desktop-App ging von 6.310 auf 3.328 Millisekunden zurück, Faktor 1,9. Das Laden einer Claude-Cowork-Cloudsitzung auf dem Desktop sank von 2.566 auf 728 Millisekunden, Faktor 3,5. Der clientseitige Anteil beim Senden einer Web-Chatnachricht sank von 180 auf 59 Millisekunden, Faktor 3,1. Das sind unterschiedliche Vorgänge und Plattformen; der Gesamtwert von 3,1 ist das geometrische Mittel aller 13 Verhältnisse und kein Ergebnis einer einzelnen Aufgabe.

Der Vergleich basiert auf Anthropics Messungen bei realen Nutzern am 13. und 27. August beim 75. Perzentil. Der Beitrag enthält weder ein unabhängiges Audit noch Ergebnisse dieser Abläufe beim 95. Perzentil oder eine kontrollierte Schätzung, welcher Anteil des Gewinns auf Claudes Unterstützung zurückging. Anthropic schätzt, dass die schnelleren Abläufe täglich Zehntausende Nutzerstunden Wartezeit einsparen, legt die Berechnung dafür aber nicht offen.

Der Messkreislauf hinter den Änderungen

Das Team begann mit etwa 20 von Ingenieuren ausgewählten Projekten. Nach Angaben von Anthropic nutzte es Claude Tag, einen Beta-Agenten mit einem internen Forschungsmodell, das ungefähr mit Opus 5.5 vergleichbar sei, um Engpässe zu finden, Benchmarks aufzubauen und Änderungen vorzuschlagen. Das Team zufolge erreichte es am dritten Tag zwölf seiner 13 anfänglichen Ziele, setzte danach neue Ziele und suchte nach Problemen, die seine bisherigen Überwachungssysteme übersehen hatten.

Ein Beispiel begann mit einer Aufzeichnung, auf der sich Zeilen der Seitenleiste nach dem Laden einer Seite bewegten. Die bestehende Kennzahl Cumulative Layout Shift machte das Problem nicht deutlich. Ein Ingenieur schlug vor, die zugrunde liegende Layout Instability API zu verwenden. Claude ergänzte daraufhin Telemetrie, die den betroffenen Seitenbereich erkannte, sowie einen Integrationstest mit verzögert geladenen Seitenleistendaten. Anthropic zufolge schlug der Test bei allen 20 Durchläufen des ursprünglichen Codes fehl und bestand alle 20 Durchläufe mit der vorgeschlagenen Änderung. Nach der Einführung der Telemetrie fand das Unternehmen Bewegungen nach dem nutzbaren Seitenaufbau bei 31 Prozent der Webaufrufe. Dies ist ein dokumentiertes Beispiel aus Anthropics Sprint und keine von BIG CHANGE wiederholte Messung.

Das Team verwendete außerdem Labormesswerte, um zwischen Veröffentlichungen schneller voranzukommen. Für zwei zeitkritische JavaScript-Codepfade verglich es deterministische Instruktionszahlen mit der Laufzeit in denselben Benchmarks. Anthropic zufolge gingen Senkungen der Instruktionszahlen um 48 und 31 Prozent mit Laufzeitverkürzungen von 78 und 44 Prozent einher. Das Team setzte diese Instruktionszahlen als Grenzwerte in der kontinuierlichen Integration fest und senkte die Grenzwerte weiter, sobald sich die Leistung verbesserte. Nach eigenen Angaben verwarf es unzuverlässige Benchmarks und solche, die nicht mit der Latenz für Nutzer übereinstimmten. Der Unterschied ist wichtig: Ein Labormesswert half bei der Steuerung der Änderungen; Messwerte von realen Nutzern prüften, ob die veröffentlichten Änderungen tatsächlich halfen.

Wo Menschen die Kontrolle behielten

Anthropic beschreibt einen Slack-Kanal mit vielen kleinen Threads, die jeweils einem Nutzungsvorgang oder Benchmark gewidmet waren. Claude untersuchte Probleme, schlug Benchmarks und Pull Requests vor, beobachtete Veröffentlichungen und las Felddaten. Ingenieure legten die Ziele fest, entschieden über akzeptable sichtbare Änderungen und genehmigten jede Anpassung. Für jeden Thread gab es einen benannten menschlichen Verantwortlichen. Eine Änderung mit 900 Codezeilen wurde abgelehnt, weil die Ingenieure eine Ersparnis von zwei Millisekunden pro Nachricht für den Wartungsaufwand nicht für angemessen hielten.

Der Veröffentlichungsprozess umfasste mehrere Prüfungen. Nach Angaben von Anthropic erhielt jeder Pull Request eine automatisierte Prüfung und mindestens eine menschliche Genehmigung; vor Optimierungen liefen Unit-Tests. Für Nutzer sichtbare Änderungen wurden hinter kurzlebigen Feature-Flags eingeführt. Änderungen mit hohem Risiko erhielten zunächst Beschäftigte, dann ein Prozent der Nutzer und schließlich alle. Das Team führte während des Sprints knapp 200 Flags ein und entfernte nach eigenen Angaben bis zum Ende mehr als die Hälfte davon. Anthropic berichtet, über 3.000 Änderungen ohne kundenseitigen Vorfall oder Rollback eingebunden zu haben. Das ist die Darstellung des Unternehmens zu diesem Sprint und kein Beleg dafür, dass ein anderes Team oder eine andere Codebasis dasselbe Ergebnis erzielen würde.

Der statische Editor zeigt, warum diese Kontrollen wichtig waren. Anthropic fügte einen sofort nutzbaren Eingabebereich in den anfänglichen HTML-Code ein, während React geladen wurde. Zur Prüfung des Übergangs verglichen Tests die statische und React-Version bei 14 Bildschirmgrößen, prüften die Ausrichtung bis auf einen Pixel genau und simulierten Eingaben während des Übergangs, um verlorene oder vertauschte Tastenanschläge zu erkennen. Feldtelemetrie maß Bewegungen während dieses Übergangs. Ein Mitarbeiter bemerkte später eine Layoutverschiebung beim Öffnen eines neuen Tabs, die diese Messungen übersehen hatten. Anthropic führte sie auf eine Größenänderung des Browsers während des spekulativen Ladens zurück und ergänzte einen Test für diesen Ablauf.

Der Bericht von Anthropic stützt eine konkrete Schlussfolgerung: Die Ingenieure setzten Claude ein, um gemessene Engpässe innerhalb eines von Menschen gesteuerten Veröffentlichungsprozesses zu finden und zu beheben. Ausgewählte Nutzungsvorgänge waren Ende August schneller. Offen bleibt, wie sich das Produkt in den langsamsten Fällen verhält, wie dauerhaft die Fortschritte sind und welchen Anteil ein unabhängiger Beobachter dem Agenten statt den Messinstrumenten, der Entwicklungsarbeit und den Veröffentlichungsentscheidungen des Teams zuschreiben würde.