Anthropic hat aufgeschrieben, wie es im August die Kernabläufe von claude.ai und der Desktop-App in einem zweiwöchigen Sprint etwa dreimal schneller gemacht hat. Der Beitrag steht seit Dienstag im Engineering-Blog. Der erste Satz ist der ehrlichste: Nutzer hatten gesagt, es sei langsam, und sie hatten recht.
Die Zahlen
Gemessen wurde an vier Abläufen, die 95 Prozent der Nutzung ausmachen, aufgeteilt in dreizehn Messpunkte zwischen Web und Desktop. Am 75. Perzentil, real gemessen, zwischen dem 13. und dem 27. August:
- claude.ai im Browser, Kaltstart bis zur tippbaren Seite: 3.085 auf 550 Millisekunden
- Desktop-App, Kaltstart: 6.310 auf 3.328 Millisekunden
- Neue Claude-Code-Sitzung starten: 837 auf 347 Millisekunden
- Cowork-Cloud-Sitzung laden: 2.566 auf 728 Millisekunden
- Nachricht abschicken in Cowork, clientseitiger Anteil: 928 auf 48 Millisekunden
Über alle dreizehn Messpunkte liegt der geometrische Mittelwert bei Faktor 3,1. Anthropic schätzt, dass das täglich zehntausende Nutzerstunden Wartezeit spart.
Wie gearbeitet wurde
Der ganze Sprint lief in einem Slack-Kanal, mit Claude in jedem Thread. Zum Einsatz kam Claude Tag in der Beta, darunter ein internes Forschungsmodell, das ungefähr auf dem Niveau von Opus 5.5 liegt. Claude suchte Engpässe, baute Benchmarks, lieferte Änderungen aus und beobachtete jedes Deployment. Die Menschen setzten Ziele, entschieden Abwägungen und gaben jede einzelne Änderung frei. Am Ende standen über dreitausend gemergte Änderungen, ohne Rollback und ohne einen Vorfall, den Kunden bemerkt hätten.
Die geplante Liste mit rund zwanzig Projekten war nach drei Tagen weitgehend abgearbeitet: zwölf der dreizehn Ziele erreicht. Was dabei half, klingt handfest. Ein statischer Composer steckt jetzt direkt im HTML, damit man tippen kann, während React noch startet. Der Desktop-Hauptprozess bekam einen vorkompilierten V8-Code-Cache. Zwischen zwei Unterhaltungen bleibt der Composer montiert, Sitzungen werden beim Überfahren mit der Maus vorgeladen, und die Seitenleiste rendert 90 Prozent seltener neu.
Der eigentliche Trick war die Messgröße
Wanduhrzeit ist das, was Nutzer spüren, aber sie schwankt zu stark für ein CI-Gate. Also suchte das Team nach deterministischen Zahlen: Instruktionszähler unter Valgrind mit node --predictable, V8-Aufrufzähler, React-Commits, Style-Recalculations, DOM-Mutationen. Jeder neue Benchmark musste zwei Aufgaben erfüllen — eine Zahl, die Claude im Labor senken kann, und eine Schranke in der CI, die nur nach unten darf. Benchmarks, die nicht mit der echten Latenz korrelierten, flogen raus.
An zwei heißen Pfaden hat Claude den Beweis geliefert. Beim Zusammenbauen des Nachrichtenbaums gingen ein Viertel der Instruktionen für megamorphe Dictionary-Lookups drauf, die dieselbe Nachrichten-ID dreimal auflösten: minus 48 Prozent Instruktionen, minus 78 Prozent Wanduhrzeit. Beim Scanner für Statuszeilen in der Claude-Code-Ausgabe reichte eine billige Prüfung des ersten Zeichens vor dem regulären Ausdruck: minus 31 und minus 44 Prozent. Beide Zähler wurden als Schranke eingecheckt, ein täglicher Job senkt die Decke weiter, sobald der Wert fällt.
Messen ist der Anfang, nicht die Vorarbeit
Der Satz, um den es in dem ganzen Text geht, steht in der Mitte: Sobald Claude eine Zahl hat, die es schlagen kann, fängt die Optimierung an. Früher war eine Metrik Schritt null — einbauen, warten, Daten ansehen, dann verstehen. Jetzt ist sie Schritt eins.
Das lässt sich mitnehmen, auch ohne Anthropics Infrastruktur. Wenn du einen Agenten hast, der stundenlang durchläuft, ist die teuerste Frage nicht mehr „wie mache ich das schneller”, sondern „woran merke ich, dass es schneller wurde”. Der Rest ist Bergsteigen.