Anthropic ha migrado por completo la Messages API que hay detrás de Claude, de Python a Rust. Katelyn Lesse, responsable de ingeniería, y Angela Jiang, responsable de producto, contaron en el podcast Latent Space cómo fue la migración: tras el cambio, el uso de CPU bajó cerca de un 40 % a un 50 %, el tiempo de respuesta del primer token se acortó entre un 10 % y un 20 %, y en las tareas de larga duración la mejora fue aún más notable. Según las invitadas, la API en Rust estaba desplegada por completo una semana antes de la grabación.
La Messages API es la puerta de entrada principal para que los desarrolladores usen Claude. Angela Jiang recuerda que, cuando se incorporó hace aproximadamente un año, el sistema todavía era un servicio monolítico en Python que funcionaba en una sola región de GCP.
El cuello de botella era la CPU
Cuando se habla de los cuellos de botella de las empresas de modelos, desde fuera se suele mirar a las GPU, pero en esta entrevista lo que salió una y otra vez fue la CPU. Tras el rápido crecimiento del uso, el servicio de API, el backend del producto, los sandboxes de código y la integración continua competían por la CPU; cuanto más código se escribe, con más frecuencia se ejecuta la CI. Según la descripción de las invitadas, el equipo de investigación y los sandboxes del producto compartían la misma cuota de CPU: si un lado usaba más, el otro debía usar menos. En ese entorno, el servicio en Python resultaba especialmente voraz en recursos.
Elegir Rust generó controversia interna, por una razón muy directa:
"we don't have a single Rust developer in the room."
(No hay ni un solo desarrollador de Rust en la sala.)
Solo más tarde el equipo fue incorporando ingenieros con experiencia en Rust.
Las personas dibujan la arquitectura, Claude escribe la implementación
El reparto fue este: los ingenieros se encargan del diseño y la verificación del sistema distribuido, la mayor parte del código de implementación se la dejan a Claude, y Claude también se usó para ayudar a los ingenieros a completar los conocimientos de Rust necesarios. Las invitadas subrayaron que planificar y verificar importa más que escribir el código en sí.
La verificación fue bastante tradicional. El equipo construyó primero una rama completa de la API en Rust, replicó en sombra el tráfico real hacia ella y comparó, petición a petición, si las salidas del sistema antiguo y del nuevo coincidían; después, con feature flags y balanceo de carga, fue desviando poco a poco el tráfico real. La migración quedó a cargo de un grupo específico, mientras los demás ingenieros seguían desarrollando funciones nuevas. Para que ambos lados no se alejaran cada vez más, el equipo usó análisis estático para marcar las funciones añadidas en Python que aún no tenían equivalente en Rust, y el grupo de migración intentó rechazar nuevos requisitos durante el proceso.
La estimación de las invitadas es que, con el método habitual de migrar de forma progresiva, pieza por pieza, podría haber llevado varios años; esta vez fue una portabilidad integral, de una sola vez. Cuánto tiempo llevó exactamente y qué proporción del código generó Claude, la entrevista no lo dijo, y desde fuera por ahora no es posible verificarlo.
Otras reescrituras parecidas
Reescrituras a gran escala de este tipo, en las que "el modelo escribe y las personas respaldan", ya han aparecido varias veces últimamente. GitHub reveló antes que había usado Copilot para reescribir su propio runtime en unas 830.000 líneas de Rust; en torno al lanzamiento de Opus 5.5, un equipo también lo empleó para llevar el compilador de TypeScript a Rust en dos semanas. Lo que tienen en común es que en todos los casos el lenguaje de destino fue Rust y la verificación se apoyó en la comparación de salidas antiguas y nuevas o en un conjunto de pruebas completo.
La diferencia está en el coste del error. Cuando fallan los compiladores y las herramientas de desarrollo, el efecto suele quedarse en el equipo local del desarrollador; la Messages API recibe todas las llamadas externas, y cualquier inconsistencia de comportamiento cae directamente en los sistemas de producción de los clientes. Que Anthropic pudiera hacer una migración integral en este tramo se debe al método de siempre, tráfico en sombra y comparación respuesta a respuesta; la velocidad de escritura del modelo, por sí sola, no lo habría sostenido.
Para otras empresas, lo aprovechable quizá sea el proceso de verificación, y no necesariamente la elección del lenguaje. Sin condiciones para tener tráfico en sombra y comparación de salidas, es difícil juzgar si un gran volumen de código que el modelo produce de golpe se comporta igual que el sistema antiguo.
Siguiente paso: el estado de la conversación
El equipo adelantó que más adelante hará ajustes en la capa de arquitectura, y una de las líneas es guardar el estado de la conversación en el servidor, para que el cliente no tenga que reenviar el historial completo en cada turno. En conversaciones largas, esto puede ahorrar mucha transmisión y procesamiento repetidos. Cuándo llegará este cambio y si afectará a las interfaces actuales o a la forma de facturación, Anthropic todavía no lo ha anunciado.
Fuentes: entrevista del podcast Latent Space, CocoLoop, documentación para desarrolladores de Anthropic; la reducción de CPU, el rango de mejora de la latencia del primer token y el estado del despliegue total se contrastaron con la entrevista.