Anthropic a fait passer l'ensemble de la Messages API qui sert Claude de Python à Rust. Katelyn Lesse, responsable de l'ingénierie, et Angela Jiang, responsable du produit, ont raconté la migration dans le podcast Latent Space : après le basculement, l'usage du CPU a diminué d'environ 40 % à 50 %, le temps de réponse du premier token s'est raccourci d'environ 10 % à 20 %, et l'amélioration est encore plus nette pour les tâches de longue durée. Selon les invitées, l'API en Rust était entièrement déployée une semaine avant l'enregistrement.
La Messages API est la porte d'entrée principale des développeurs pour appeler Claude. Angela Jiang se souvient que, lorsqu'elle a rejoint l'entreprise il y a environ un an, ce système était encore un service Python monolithique, qui ne tournait que dans une seule région GCP.
Le goulot d'étranglement, c'était le CPU
Quand on parle des goulots d'étranglement des entreprises de modèles, on regarde d'ordinaire les GPU de l'extérieur, mais dans cet entretien, c'est le CPU qui revenait sans cesse. Après la croissance rapide de l'usage, le service d'API, le backend produit, les bacs à sable de code et l'intégration continue se disputaient le CPU ; plus on écrit de code, plus la CI tourne souvent. D'après les invitées, l'équipe de recherche et les bacs à sable du produit se partageaient le même quota de CPU : ce qu'un côté consomme en plus, l'autre doit le consommer en moins. Dans cet environnement, le service Python se montrait particulièrement gourmand en ressources.
Le choix de Rust a fait débat en interne, pour une raison très simple :
"we don't have a single Rust developer in the room."
(Il n'y a pas un seul développeur Rust dans la salle.)
Ce n'est que plus tard que l'équipe a recruté, petit à petit, des ingénieurs ayant de l'expérience en Rust.
Les humains dessinent l'architecture, Claude écrit l'implémentation
La répartition était la suivante : les ingénieurs se chargent de la conception et de la vérification du système distribué, l'essentiel du code d'implémentation est confié à Claude, et Claude a aussi servi à aider les ingénieurs à combler les connaissances de Rust nécessaires. Les invitées ont insisté sur le fait que planifier et vérifier compte davantage que l'écriture du code elle-même.
La vérification est restée plutôt classique. L'équipe a d'abord construit une branche complète de l'API en Rust, y a dupliqué en mode fantôme le trafic réel, et a comparé requête par requête si les sorties de l'ancien et du nouveau système étaient identiques, puis a basculé le trafic réel petit à petit au moyen de feature flags et d'un répartiteur de charge. La migration était confiée à une équipe dédiée, tandis que les autres ingénieurs continuaient à développer de nouvelles fonctionnalités ; pour éviter que les deux côtés ne s'éloignent de plus en plus, l'équipe a utilisé l'analyse statique afin de repérer les fonctions ajoutées en Python qui n'avaient pas encore d'équivalent en Rust, et l'équipe de portage s'est efforcée de refuser les nouvelles demandes pendant la migration.
L'estimation des invitées est qu'avec la méthode habituelle, une migration progressive morceau par morceau, cela aurait pu prendre plusieurs années ; cette fois, il s'agissait d'un portage global en une seule fois. La durée exacte et la part du code générée par Claude n'ont pas été chiffrées dans l'entretien, et il est impossible pour l'instant de les vérifier de l'extérieur.
Ce que donnent d'autres réécritures du même genre
Ce type de réécriture à grande échelle, où « le modèle écrit et les humains rattrapent », est déjà apparu plusieurs fois récemment. GitHub avait révélé avoir utilisé Copilot pour réécrire son propre runtime en environ 830 000 lignes de Rust ; vers la sortie d'Opus 5.5, une équipe s'en est aussi servie pour porter le compilateur TypeScript vers Rust en deux semaines. Point commun de ces cas : le langage cible était à chaque fois Rust, et la vérification reposait sur la comparaison des sorties anciennes et nouvelles ou sur une suite de tests complète.
La différence tient au coût d'une erreur. Quand un compilateur ou un outil de développement se trompe, l'impact reste le plus souvent sur la machine locale du développeur ; la Messages API, elle, reçoit tous les appels externes, et la moindre incohérence de comportement retombe directement sur les systèmes de production des clients. Si Anthropic a pu faire un portage global sur ce maillon, c'est grâce à la vieille méthode du trafic fantôme et de la comparaison réponse par réponse ; la vitesse d'écriture du modèle ne suffisait pas à elle seule.
Pour d'autres entreprises, ce qui est transposable, c'est sans doute le processus de vérification, pas forcément le choix du langage. Sans trafic fantôme ni comparaison des sorties, il est difficile de juger si un gros volume de code produit d'un coup par le modèle se comporte comme l'ancien système.
Prochaine étape : l'état de la conversation
L'équipe a indiqué qu'elle ferait ensuite des ajustements au niveau de l'architecture, l'une des pistes étant de stocker l'état de la conversation côté serveur, afin que le client n'ait plus à renvoyer l'historique complet à chaque tour. Dans les conversations longues, cela peut éviter beaucoup de transmissions et de traitements redondants. Quand ce changement sera mis en ligne, et s'il touchera les interfaces existantes ou le mode de facturation, Anthropic ne l'a pas encore annoncé.
Sources : entretien du podcast Latent Space, CocoLoop, documentation développeur d'Anthropic ; la baisse du CPU, la fourchette d'amélioration de la latence du premier token et l'état du déploiement total ont été recoupés avec l'entretien.