> ## Content Index
> Fetch the complete content index at: https://fomoera.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Claude.ai tardaba 3 segundos en dejarte escribir; Claude lo bajó a medio segundo
- URL: https://fomoera.com/anthropic-claude-ai-3x-mas-rapido-sprint/
- Published: 2026-09-24T20:00:20.000Z
- Updated: 2026-09-24T20:00:20.000Z
- Description: Anthropic dice que un modelo interno encontró cuellos de botella, creó benchmarks y envió más de 3,000 cambios en dos semanas. La mejora va de 1.5 a 19 veces según la tarea, y las cifras son de la propia empresa.
- Author: Patricia Rodriguez
- Tags: Tecnología y Ciencia, IA

Anthropic asegura que en agosto hizo que claude.ai y la app de escritorio de Claude respondan unas tres veces más rápido en un sprint de dos semanas, y que buena parte del trabajo lo hizo el propio Claude. En un post de ingeniería publicado el 23 de septiembre de 2026, la compañía explica que un modelo interno de investigación, comparable a Opus 5.5 según su descripción, encontró cuellos de botella, construyó benchmarks, propuso cambios y vigiló cada despliegue, mientras los ingenieros fijaban metas y aprobaban cada cambio. El salto más visible está en la carga de la web: en el percentil 75, el tiempo hasta que el usuario puede escribir pasó de 3.1 a 0.55 segundos. Son cifras de la propia empresa, sin auditoría independiente.

## Qué midió Anthropic y qué significa el "3x"

El equipo analizó datos de uso y se quedó con cuatro recorridos que, según Anthropic, concentran el 95% de la actividad: abrir la app, empezar una conversación, cargar una conversación existente y enviar un mensaje. Repartidos entre web, escritorio y sus productos (el chat, Claude Code y Claude Cowork), sumaron **13 mediciones** de usuarios reales, comparadas entre el 13 y el 27 de agosto de 2026.

El "3x" es la media geométrica de esas 13 cifras: **3.1 veces más rápido**. Detrás del promedio hay mejoras muy desiguales, como muestra esta selección de los datos publicados por la compañía.

__Tiempos en el percentil 75 reportados por Anthropic, 13 frente a 27 de agosto de 2026 (selección)__
| Recorrido                                           | Antes    | Después  | 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 mensaje en Claude Cowork (parte del cliente) | 928 ms   | 48 ms    | 19x    |

El rango va de una mejora de 1.5 veces al iniciar un chat en la web a una de 19 veces en la parte que corre en el cliente al enviar un mensaje en Cowork. RuntimeWire, que revisó el post, advierte que el promedio combina tareas y productos distintos, así que no significa que cada interacción se volviera tres veces más rápida. Anthropic también calcula que los cambios ahorran decenas de miles de horas de espera al día, una estimación que el post no acompaña con los volúmenes de tráfico ni el cálculo detrás.

## Cómo trabajó Claude dentro de un canal de Slack

Todo ocurrió en un solo canal de Slack con Claude Tag, la herramienta en beta que permite etiquetar a Claude en conversaciones de equipo. Los ingenieros le dieron instrucciones permanentes: vigilar regresiones de rendimiento, revisar la telemetría, mantener tableros y proponer e implementar mejoras. Claude analizó los datos de uso a través del servidor MCP de Datadog 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 de ingeniería clásica. La compañía incrustó en el HTML una versión estática de la caja de texto para que el usuario pueda escribir mientras React termina de cargar, precompiló una caché de código V8 para acelerar el arranque de escritorio, empezó a precargar conversaciones cuando el cursor pasa sobre ellas y recortó en 90% los re-renderizados de la barra lateral.

La apuesta más interesante vino después. Como el tiempo de reloj es ruidoso, el equipo buscó métricas deterministas que Claude pudiera empujar hacia abajo en laboratorio, como el conteo de instrucciones de CPU medido con Valgrind, y le exigió demostrar que seguían al tiempo real antes de conservarlas. En la rutina que arma el árbol de mensajes de una conversación, Claude descubrió que resolvía el mismo identificador tres veces; al corregirlo, las instrucciones bajaron 48% y el tiempo real, 78%. Esos conteos quedaron como "trinquetes" en la integración continua, con topes que solo pueden bajar.

![A woman analyzes data on a computer screen in a modern office setup, focusing on technological research.](https://fomoera.com/content/images/2026/09/fomoera-a-woman-analyzes-data-on-a-computer-screen-in-a-modern-office-setup-focusing-on-pexels-3862140.webp)

Imagen ilustrativa de trabajo de optimización de software. · Foto de [ThisIsEngineering](https://www.pexels.com/@thisisengineering?ref=fomoera.com) en [Pexels](https://www.pexels.com/photo/woman-using-computer-on-table-3862140/?ref=fomoera.com)

Con ese método, el equipo llegó a tener más de 150 hilos abiertos a la vez y, en los días de más actividad, más de 200 cambios integrados. Algunos hallazgos eran casi invisibles: un `location.reload()` olvidado provocaba medio millón de recargas ocultas al día, y un solo selector CSS añadía 24 milisegundos a cada cambio del DOM. Otro tenía una causa curiosa. Si una respuesta contenía una raya larga o unas comillas tipográficas, el motor 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 un segundo; un cambio de unas 20 líneas lo dejó en 0.35 segundos.

El mismo enfoque llegó al streaming de respuestas. En un solo hilo se integraron casi 60 cambios: las respuestas largas pasaron de bloquear el hilo principal unos 750 milisegundos en total a unos 200, y en una MacBook con pantalla de 120 Hz mantienen 120 cuadros por segundo de principio a fin, según Anthropic.

## Los ingenieros pusieron los frenos y el ritmo

Anthropic afirma que integró más de 3,000 cambios sin un solo incidente visible para clientes ni una reversión. Cada pull request pasó por revisión automatizada y por al menos una aprobación humana, las pruebas unitarias iban antes de cada optimización y lo que podía afectar al usuario salió detrás de banderas temporales, casi 200 en dos semanas. Los cambios de mayor riesgo se liberaron primero a empleados, luego al 1% de los usuarios y al final a todos.

El post también describe a un Claude cauteloso por defecto, que acotaba el alcance e inflaba sus estimaciones, al que los ingenieros tuvieron que empujar a ser más ambicioso. El freno también funcionó en sentido contrario: un cambio de 900 líneas se descartó porque ahorrar 2 milisegundos por envío no justificaba mantener un plugin de compilación adicional. "No me habrías podido convencer de que esto era posible ni siquiera hace seis meses", escribió Issac G., uno de los tres autores del post.

## Las dudas: el punto de partida y lo que no se audita

El post de ingeniería llegó a la portada de Hacker News, donde 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, dicen, era el problema de fondo. Otros preguntaron cuánta complejidad añaden tantos cambios al código a largo plazo. El programador Simon Willison contó ahí que la web le cargó rápido incluso con conexión compartida desde el celular, aunque notó que Firefox descarga 20.78 MB de JavaScript (6.84 MB comprimidos).

RuntimeWire subraya otra limitación: el post no publica el tamaño de la muestra de tráfico ni una auditoría externa de la comparación, y 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, y promete otro texto sobre sus aportaciones a Electron, Chromium y Node.js durante el sprint.

Para quien usa Claude a diario, el cambio se nota sobre todo al abrir la web y al trabajar con Cowork y Claude Code en escritorio. Para la industria, el caso muestra un patrón concreto de desarrollo con agentes: métricas deterministas, topes en integración continua y aprobación humana en cada cambio.

*Fuentes:* [1](https://claude.dev/blog/how-we-made-claude-ai-faster/?ref=fomoera.com), [2](https://runtimewire.com/article/anthropic-claude-app-performance-sprint?ref=fomoera.com), [3](https://news.ycombinator.com/item?id=49821196&ref=fomoera.com)