✨︎ Resumen (TL;DR):
- Un modelo interno de Anthropic localizó cuellos de botella y ayudó a optimizar Claude.ai y la app de escritorio en un sprint de dos semanas.
- En la web, el tiempo hasta poder escribir cayó de 3.1 segundos (3,085 ms) a 0.55 segundos (550 ms) en el percentil 75.
- Las 13 mediciones dieron una media geométrica de 3.1x, pero las mejoras individuales fueron de 1.5x a 19x y las cifras no tienen auditoría independiente.
Anthropic reportó una mejora promedio de 3.1x en 13 mediciones de Claude.ai, su app de escritorio, Claude Code y Claude Cowork tras un sprint de dos semanas en agosto de 2026. En la web, el tiempo hasta poder escribir cayó de 3.1 a 0.55 segundos en el percentil 75. Un modelo interno, que Anthropic describe como comparable con Opus 5.5, encontró cuellos de botella y propuso cambios para recortar la espera, mientras los ingenieros fijaron metas y aprobaron cada modificación. Las cifras pertenecen a la empresa y no tienen auditoría independiente.
El 3x no significa que todo cargue tres veces más rápido
Anthropic publicó el post de ingeniería el 23 de septiembre de 2026. Para calcular el resultado, tomó datos de uso y seleccionó cuatro recorridos que, según la empresa, concentran 95% de la actividad: abrir la app, iniciar una conversación, cargar una conversación existente y enviar un mensaje.
Los recorridos cubrieron la web, el escritorio y tres productos: el chat, Claude Code y Claude Cowork. En total, el equipo comparó 13 mediciones de usuarios reales entre el 13 y el 27 de agosto de 2026.
La cifra de 3x es la media geométrica de esas 13 cifras y quedó en 3.1 veces. No significa que cada interacción se haya vuelto tres veces más rápida.
Estos son algunos de los tiempos en el percentil 75 que publicó Anthropic:
| Recorrido | Antes (ms) | Después (ms) | Mejora |
|---|---|---|---|
| Abrir claude.ai en web, carga nueva | 3,085 ms | 550 ms | 5.6x |
| Arranque en frío de la app de escritorio | 6,310 ms | 3,328 ms | 1.9x |
| Iniciar un chat en web | 416 ms | 273 ms | 1.5x |
| Iniciar sesión de Claude Code en escritorio | 837 ms | 347 ms | 2.4x |
| Cargar sesión de Claude Cowork en la nube | 2,566 ms | 728 ms | 3.5x |
| Enviar un mensaje en Claude Cowork, parte del cliente | 928 ms | 48 ms | 19x |
La selección muestra por qué el promedio necesita contexto. La mejora va de 1.5x al iniciar un chat en web a 19x en la parte del cliente al enviar un mensaje en Cowork. RuntimeWire advirtió que la media mezcla tareas y productos diferentes, así que no implica que cada interacción se haya acelerado 3.1 veces.
Anthropic también calcula que los cambios ahorran decenas de miles de horas de espera al día, pero el post no publica los volúmenes de tráfico ni el cálculo que sostiene esa estimación.
Claude trabajó dentro de un canal de Slack
Claude Tag es una herramienta en beta que permite etiquetar a Claude en conversaciones de equipo. Anthropic concentró el sprint en un solo canal de Slack con esa herramienta.
Los ingenieros le dieron instrucciones permanentes: vigilar regresiones de rendimiento, revisar la telemetría, mantener tableros y proponer e implementar mejoras. A través del servidor MCP de Datadog, Claude analizó los datos de uso y estimó en milisegundos el impacto de unos 20 proyectos iniciales. Anthropic dice que cumplió 12 de las 13 metas al tercer día.
Los primeros cambios fueron directos:
- Anthropic incrustó en el HTML una versión estática de la caja de texto para que el usuario pudiera escribir mientras React terminaba de cargar.
- La compañía precompiló una caché de código de V8 para acelerar el arranque en frío de la app de escritorio.
- También empezó a precargar conversaciones cuando el cursor pasaba sobre ellas.
- Además, recortó en 90% los re-renderizados de la barra lateral.
Métricas deterministas para encontrar cuellos de botella
El tiempo de reloj resultaba ruidoso, así que el equipo buscó métricas deterministas que Claude pudiera reducir en laboratorio. Una de ellas fue el conteo de instrucciones de CPU medido con Valgrind. Antes de conservar una métrica, Claude tenía que demostrar que reflejaba el tiempo real.
En la rutina que arma el árbol de mensajes de una conversación, Claude encontró que el sistema resolvía el mismo identificador tres veces. Al corregirlo, la cantidad de instrucciones bajó 48% y el tiempo real se redujo 78%. El equipo dejó esos conteos como trinquetes en la integración continua, con topes que solo pueden bajar.
El equipo llegó a mantener más de 150 hilos abiertos a la vez y, en los días de mayor actividad, más de 200 cambios integrados. Un location.reload() olvidado provocaba 500,000 recargas ocultas al día. Un solo selector CSS añadía 24 milisegundos a cada cambio del DOM.
Otro hallazgo apareció en el manejo de texto. Si una respuesta contenía una raya larga o unas comillas tipográficas, V8 guardaba todo el texto en UTF-16 y el resaltado de un bloque de código podía congelar la página cerca de 1 segundo. Un cambio de unas 20 líneas redujo ese tiempo a 0.35 segundos.
El streaming de respuestas recibió casi 60 cambios en un solo hilo. Las respuestas largas pasaron de bloquear el hilo principal unos 750 milisegundos en total a unos 200 milisegundos. Anthropic reporta que, en una MacBook con pantalla de 120 Hz, las respuestas mantuvieron 120 cuadros por segundo de principio a fin.
Más de 3,000 cambios con aprobación humana
Anthropic afirma que integró más de 3,000 cambios sin un solo incidente visible para los clientes ni una reversión. Cada pull request pasó por revisión automatizada y por al menos una aprobación humana; las pruebas unitarias corrían antes de cada optimización.
La empresa puso los cambios que podían afectar al usuario detrás de banderas temporales, casi 200 en dos semanas. Anthropic liberó los cambios de mayor riesgo primero a empleados, luego a 1% de los usuarios y finalmente a todos.
El post describe a Claude como cauteloso por defecto: acotaba el alcance e inflaba sus estimaciones, así que los ingenieros tuvieron que empujarlo a ser más ambicioso. En sentido contrario, Anthropic descartó un cambio de 900 líneas porque ahorrar 2 milisegundos por envío no justificaba conservar un plugin de compilación adicional.
Issac G., uno de los tres autores del post, escribió: “No me habrías podido convencer de que esto era posible ni siquiera hace seis meses”.
El punto de partida y lo que todavía falta medir
La publicación llegó a la portada de Hacker News. Varios comentarios cuestionaron más el punto de partida que el método: una web que tardaba más de 3 segundos en dejar escribir ya tenía un problema de fondo, según ellos. Otros preguntaron cuánta complejidad pueden acumular tantos cambios en el código a largo plazo.
Simon Willison contó que la web le cargó rápido incluso con una conexión compartida desde el celular, aunque observó que Firefox descarga 20.78 MB de JavaScript, de los cuales 6.84 MB están comprimidos.
RuntimeWire señaló que el post no publica el tamaño de la muestra de tráfico ni una auditoría externa de la comparación. Tampoco muestra si una app más rápida cambió la retención o los ingresos.
Anthropic reconoce que el percentil 95, otros recorridos y las conversaciones muy largas todavía tienen margen de mejora. La empresa promete otro texto sobre sus aportaciones a Electron, Chromium y Node.js durante el sprint.
Para quien usa Claude a diario, Anthropic sitúa la diferencia más visible al abrir la web y trabajar con Cowork y Claude Code en escritorio. El proceso que describe deja un patrón concreto de desarrollo con agentes: métricas deterministas, topes en integración continua y aprobación humana en cada cambio. La muestra de tráfico y el efecto sobre retención o ingresos, sin embargo, todavía no aparecen en los datos publicados.
