Anthropic hat die Messages API hinter Claude komplett von Python nach Rust umgezogen. Katelyn Lesse, die für die Technik zuständig ist, und Angela Jiang, die das Produkt verantwortet, haben im Podcast Latent Space geschildert, wie die Migration ablief: Nach der Umstellung sank die CPU-Auslastung um etwa 40 bis 50 Prozent, die Antwortzeit bis zum ersten Token verkürzte sich um rund 10 bis 20 Prozent, bei lang laufenden Aufgaben fiel die Verbesserung noch deutlicher aus. Laut den beiden Gästen war die Rust-Version der API eine Woche vor der Aufnahme vollständig ausgerollt.
Die Messages API ist der wichtigste Zugang für Entwickler, die Claude ansprechen. Angela Jiang erinnerte sich, dass das System, als sie vor etwa einem Jahr einstieg, noch ein monolithischer Python-Dienst war, der nur in einer einzigen GCP-Region lief.
Der Engpass war die CPU
Wenn von Engpässen bei KI-Modellanbietern die Rede ist, schaut man von außen meist auf die GPUs. In diesem Gespräch ging es dagegen immer wieder um die CPU. Nach dem schnellen Nutzungswachstum konkurrierten API-Dienst, Produkt-Backend, Code-Sandboxes und Continuous Integration um CPU-Zeit; je mehr Code geschrieben wird, desto häufiger läuft die CI. Den Gästen zufolge teilten sich das Forschungsteam und die Produkt-Sandboxes dasselbe CPU-Kontingent: Was die eine Seite mehr nutzt, muss die andere weniger nutzen. In diesem Umfeld erwies sich der Python-Dienst als besonders ressourcenhungrig.
Die Wahl von Rust war intern umstritten, und der Grund liegt auf der Hand:
"we don't have a single Rust developer in the room."
(Im Raum sitzt kein einziger Rust-Entwickler.)
Erst später stellte das Team nach und nach Ingenieure mit Rust-Erfahrung ein.
Menschen zeichnen die Architektur, Claude schreibt die Umsetzung
Die Arbeitsteilung sah so aus: Die Ingenieure übernahmen Entwurf und Verifikation des verteilten Systems, den Großteil des Implementierungscodes überließen sie Claude, und Claude half den Ingenieuren zudem, sich das nötige Rust-Wissen anzueignen. Die Gäste betonten, dass Planung und Verifikation wichtiger seien als das Schreiben des Codes selbst.
Die Verifikation fiel eher klassisch aus. Das Team baute zunächst einen vollständigen Rust-Zweig der API, spiegelte den Live-Traffic per Shadow-Verfahren dorthin und verglich Anfrage für Anfrage, ob die Ausgaben von altem und neuem System übereinstimmen. Anschließend wurde der echte Traffic mit Feature-Flags und Load-Balancern Schritt für Schritt umgeleitet. Die Migration lag bei einem eigens dafür abgestellten Team, die übrigen Ingenieure entwickelten weiter neue Funktionen. Damit beide Seiten nicht immer weiter auseinanderdriften, markierte das Team per statischer Analyse Funktionen, die in Python neu hinzukamen und in der Rust-Version noch keine Entsprechung hatten; das Portierungsteam versuchte zudem, während der Migration möglichst keine neuen Anforderungen anzunehmen.
Nach Einschätzung der Gäste hätte eine schrittweise Migration Stück für Stück auf übliche Weise wohl mehrere Jahre gedauert; diesmal handelte es sich um eine einmalige Gesamtportierung. Wie lange sie tatsächlich dauerte und welchen Anteil des Codes Claude erzeugte, nannte das Gespräch nicht, und von außen lässt es sich derzeit nicht überprüfen.
Ähnliche Neuschreibungen im Vergleich
Solche groß angelegten Neuschreibungen nach dem Muster „Das Modell schreibt, der Mensch fängt auf“ gab es zuletzt bereits mehrfach. GitHub hatte zuvor offengelegt, mit Copilot die eigene Laufzeitumgebung in rund 830.000 Zeilen Rust neu geschrieben zu haben; rund um die Veröffentlichung von Opus 5.5 brachte außerdem ein Team damit den TypeScript-Compiler in zwei Wochen nach Rust. Gemeinsam ist den Fällen, dass als Zielsprache jeweils Rust gewählt wurde und die Absicherung über den Vergleich alter und neuer Ausgaben oder über eine vollständige Testsuite lief.
Der Unterschied liegt in den Kosten eines Fehlers. Wenn bei Compilern und Entwicklungswerkzeugen etwas schiefgeht, bleibt die Wirkung meist auf dem lokalen Rechner der Entwickler. Die Messages API dagegen nimmt sämtliche externen Aufrufe entgegen; weicht das Verhalten ab, schlägt das direkt auf die Produktivsysteme der Kunden durch. Dass Anthropic auf dieser Strecke eine Gesamtportierung wagen konnte, beruht auf dem bewährten Verfahren aus Shadow-Traffic und Vergleich jeder einzelnen Antwort; die Schreibgeschwindigkeit des Modells allein hätte das nicht getragen.
Für andere Unternehmen ist wohl eher der Verifikationsprozess übertragbar als die Sprachwahl. Ohne Shadow-Traffic und Ausgabevergleich lässt sich bei einer großen Menge auf einen Schlag vom Modell erzeugtem Code kaum beurteilen, ob er sich wie das Altsystem verhält.
Als Nächstes: der Gesprächszustand
Das Team kündigte an, später die Architektur anzupassen. Eine Richtung ist, den Gesprächszustand serverseitig zu speichern, sodass der Client nicht in jeder Runde den vollständigen Verlauf erneut senden muss. Bei langen Dialogen könnte das viel redundante Übertragung und Verarbeitung einsparen. Wann diese Änderung kommt und ob sie bestehende Schnittstellen oder die Abrechnung betrifft, hat Anthropic bisher nicht bekannt gegeben.
Quellen: Latent-Space-Podcast-Interview, CocoLoop, Anthropic-Entwicklerdokumentation; CPU-Rückgang, Bereich der Verbesserung bei der Latenz bis zum ersten Token und Stand des vollständigen Rollouts wurden anhand des Interviews geprüft.