Si tienes la impresión de que «tu» Claude últimamente parece que corre más… no eres el único. Anthropic ha contado en su blog técnico cómo consiguió acelerar de forma drástica el rendimiento de claude.ai, su aplicación de escritorio y Claude Code en apenas catorce días. No se trató de una campaña de marketing ni de un simple parche puntual, sino de un sprint de ingeniería en el que la propia Claude actuó como motor principal del trabajo: detectando cuellos de botella, escribiendo benchmarks, generando pull requests y vigilando cada despliegue en producción. El resultado, según la compañía, es una plataforma alrededor de tres veces más veloz de media en las interacciones diarias más comunes, sin que se registrara ni un solo incidente visible para el usuario ni una sola reversión de emergencia durante todo el proceso.
Cuatro trayectos que concentran casi todo el uso
El equipo empezó analizando datos reales de monitorización de usuarios para averiguar dónde se acumulaba la espera. De ahí surgieron cuatro trayectos que, combinados, representan aproximadamente el 95% de toda la actividad en la plataforma: arrancar la aplicación, iniciar una conversación, cargar una conversación existente y enviar un mensaje. Antes del sprint, abrir claude.ai desde cero tardaba más de tres segundos en llegar a un estado en el que se podía escribir, en el percentil 75. Tras la optimización, ese mismo arranque se queda en 0,55 segundos, una mejora del 82%. La carga de una conversación en la app de escritorio bajó de 1,35 segundos a menos de medio segundo, y el envío de mensajes en sesiones en la nube de Claude Cowork pasó de 928 milisegundos a apenas 48, una reducción del 95%. En conjunto, trece mediciones distintas mejoraron una media de 3,1 veces (media geométrica), lo que Anthropic calcula que ahorra decenas de miles de horas de espera acumuladas cada día entre todos sus usuarios.
El bucle: medir, construir, desplegar y volver a empezar
Todo el sprint se coordinó desde un único canal de Slack mediante Claude Tag, la herramienta de Anthropic que permite invocar a Claude dentro de conversaciones de equipo. Cualquier ingeniero podía abrir un hilo señalando un punto lento de la interfaz, normalmente con una grabación de pantalla, y Claude se encargaba de trazar el flujo, construir un benchmark que reprodujera el problema en laboratorio y volver con una o varias pull requests dimensionadas para facilitar la revisión. Una vez desplegado el cambio, Claude leía los datos de campo: si el rendimiento mejoraba, fijaba la ganancia bajando el umbral del benchmark correspondiente; si no, desactivaba la funcionalidad tras la bandera de control y probaba otra vía. Llegaron a mantener más de ciento cincuenta hilos abiertos de forma simultánea, y en los días de mayor actividad se fusionaron más de doscientos cambios en veinticuatro horas. El total del sprint superó los tres mil commits mezclados en dos semanas.
Una de las ideas clave fue sustituir el reloj de pared, ruidoso y poco fiable como métrica de integración continua, por conteos deterministas de instrucciones de CPU bajo Valgrind con node --predictable. Al aplicar esa técnica sobre la rutina que ensambla el árbol de mensajes de una conversación, Claude descubrió que una cuarta parte de las instrucciones correspondían a búsquedas repetidas en diccionarios megamórficos, resolviendo tres veces el mismo identificador de mensaje. Corregirlo redujo el recuento de instrucciones un 48% y el tiempo real de ejecución un 78%, una ganancia de 4,6 veces que después quedó blindada como umbral de CI que solo podía bajar, nunca subir.
Producto principal: qué cambia realmente en claude.ai
El grueso de la mejora recae sobre claude.ai en su versión web y de escritorio, que es donde vive la mayoría de los usuarios habituales del asistente. Anthropic incorporó un composer estático, una copia en HTML puro de la caja de texto que se muestra casi de inmediato, de modo que el usuario puede empezar a escribir mientras React todavía se está inicializando por detrás; ese único cambio explica buena parte del salto de 3,1 a 0,55 segundos en el arranque. También mantuvieron el composer montado al cambiar de conversación, precargaron las sesiones al pasar el ratón por encima en la barra lateral y recortaron en un 90% los repintados innecesarios de esa misma barra. Un censo de hooks de React reveló 6.900 hooks y 900 suscripciones a almacenes de estado activos en el simple hecho de escribir en el cuadro de texto, todos disparándose con cada pulsación de tecla; reducir esa cascada fue otro de los focos del sprint. En paralelo, Claude detectó que resaltar un bloque de código con caracteres como una raya o una comilla tipográfica obligaba a V8 a almacenar la cadena completa en UTF-16, penalizando el motor de expresiones regulares del resaltado de sintaxis; el arreglo, apenas veinte líneas de código, recortó el bloqueo del hilo principal de un segundo a 0,35 segundos en el primer bloque de una página.
Blindaje frente al riesgo de romper algo a esa velocidad
Fusionar tres mil cambios sin incidentes no fue casualidad. Cada pull request pasaba por revisión automatizada más al menos una aprobación humana, las pruebas unitarias siempre precedían a la optimización y cualquier modificación visible para el usuario se desplegaba detrás de una bandera de activación de vida corta; a lo largo del sprint se introdujeron cerca de doscientas de estas banderas, más de la mitad ya retiradas al cerrar el proyecto. Para el composer estático, cuya fragilidad es intrínseca porque debe coincidir píxel a píxel con el render real de React, el equipo añadió pruebas de integración que comparaban ambas versiones en catorce tamaños de ventana distintos, con una tolerancia máxima de un píxel. Incluso así se coló un caso límite: en Chrome gestionado por una organización, la página de nueva pestaña añade un pie de 56 píxeles que desaparece al navegar, provocando un desplazamiento vertical de unos 10 píxeles solo en determinadas condiciones de renderizado especulativo del navegador. Claude localizó la causa exacta y fijó el diseño durante ese redimensionado.
Ocho milisegundos por fotograma
El episodio más técnico del sprint tuvo que ver con el streaming de respuestas largas. Cada fotograma pintado dispone de un presupuesto de 8,33 milisegundos si se quiere sostener 120 imágenes por segundo, así que Claude recorrió la generación de una respuesta larga fotograma a fotograma para localizar los tramos lentos. El equipo eliminó trabajo proporcional a la longitud del mensaje memorizando los bloques ya terminados, trasladó la tokenización de bloques de código en crecimiento a un worker aparte y reveló las tablas celda a celda en lugar de de golpe. El bloqueo total del hilo principal en una respuesta larga bajó de unos 750 milisegundos a unos 200, con un consumo de CPU alrededor de un tercio del original y manteniendo los 120 fps de principio a fin en un MacBook con esa frecuencia de pantalla. Como explica el propio equipo en el blog de Anthropic , la lección central de todo el sprint fue que en cuanto algo se puede medir, Claude puede optimizarlo de forma sistemática.
Reflexiones adicionales
Lo interesante de este caso no es solo la cifra final, sino el modelo de trabajo: un canal único, decenas de hilos paralelos y un modelo de IA actuando como ingeniero de plataforma a tiempo completo, con humanos aportando criterio sobre qué merece la pena optimizar y cuánto riesgo asumir. Es un enfoque que recuerda a cómo Google documentó en su día el uso de Cumulative Layout Shift para medir la estabilidad visual de una página, una métrica que en este caso resultó insuficiente y que el equipo de Anthropic tuvo que complementar accediendo directamente a la Layout Instability API del navegador para detectar saltos de interfaz que el indicador estándar no llegaba a capturar. Para cualquier medio que siga de cerca la evolución de los asistentes de IA, este tipo de publicaciones de ingeniería son tan reveladoras como los propios anuncios de producto: muestran hasta qué punto estas herramientas ya se usan para optimizarse a sí mismas, y qué guardarraíles hacen falta para que ese proceso no se descontrole.
4