Los hilos de mensajes aceleran Claude Code entre 2 y 4 minutos por sesión de trabajo

Una sesión larga con un agente de código no es muy económica: usted añade una réplica corta y el cliente vuelve a enviar al servidor todo el historial acumulado. Cuando el contexto crece hasta cientos de miles de tokens, la carga repetida empieza a afectar al tiempo de espera. Los hilos de mensajes en Claude cambian justo este tramo: tras la primera solicitud, el cliente envía solo los datos nuevos, mientras que el historial anterior queda asociado al hilo en el lado del servicio.

El efecto práctico es perceptible, pero no hay milagros. Anthropic informa de una reducción del 35 % en la mediana del tiempo hasta el primer token para solicitudes de entre 500.000 y 1 millón de tokens. El autor de ZDNET tomó los registros de unas 980 solicitudes a Claude Code y estimó cuánto habría ganado con el nuevo esquema. El resultado fue de dos a cuatro minutos en una sesión de trabajo de cuatro horas con 100–225 llamadas al modelo.

Dónde desaparece el retraso

Imaginemos un agente que lleva varias horas analizando un repositorio grande. Su historial contiene código fuente, resultados de pruebas, respuestas de herramientas y decenas de decisiones anteriores. Antes, una orden como «corrige los dos errores restantes» podía ir acompañada del reenvío de todo ese paquete. Ahora por la red viaja sobre todo la nueva orden y los cambios posteriores a la solicitud anterior.

Esto reduce el retraso hasta que aparece el primer token, pero no acelera el razonamiento del modelo una vez que empieza a responder. Tampoco hace a Claude más inteligente ni amplía su ventana de contexto. Simplemente elimina el transporte repetido de contenido que el servidor ya conoce. Este enfoque resulta especialmente útil para agentes con muchos pasos consecutivos, así como para tareas con documentos, imágenes y capturas de pantalla: los adjuntos pesados no hay que cargarlos de nuevo en cada turno.

También es importante que los 2–4 minutos citados no son el resultado de una comparación directa de sesiones idénticas antes y después de la actualización. Es un cálculo sobre registros antiguos aplicando la reducción de latencia declarada por Anthropic. Muestra bien el orden de magnitud de la ganancia, pero no sustituye una medición controlada. La red, la región del servidor, el tamaño del contexto y el tipo de llamadas pueden cambiar el resultado de forma notable.

Más rápido no significa más barato

Los hilos de mensajes reducen el volumen de datos retransmitidos, pero el modelo sigue procesando todo el historial de la conversación. Por eso el número de tokens facturables y los límites de la API no cambian. Para reducir el coste hace falta otro mecanismo: el almacenamiento en caché de prompts, que permite no pagar la tarifa normal por reprocesar la parte inalterada del contexto. Los hilos y la caché pueden usarse juntos: los primeros reducen la latencia de red, la segunda ayuda con los gastos.

También hay limitaciones. Una solicitud aislada casi no gana nada: aún no hay historial que reenviar. Según el material de origen, tras una pausa de más de cinco minutos el cliente puede volver a enviar el contenido completo. Tampoco desaparecen los viejos problemas de las sesiones largas: desbordamiento del contexto, compresión del historial y pérdida gradual de detalles importantes por parte del modelo.

Qué debe comprobar el desarrollador

Si Claude Code se usa en tandas cortas de pocas solicitudes, puede que ni se note el cambio. Si un agente trabaja durante horas con un repositorio grande, llama constantemente a herramientas o envía imágenes, la ganancia se suma a partir de decenas de pequeñas reducciones de latencia.

La conclusión práctica es sencilla: conviene evaluar la función no por el porcentaje del anuncio, sino por el tiempo total de la tarea. Recopile los registros de al menos unas cuantas sesiones típicas y mida por separado el tiempo hasta el primer token y la duración total de la ejecución. Y no incluya un ahorro de costes en su modelo financiero: los hilos hacen el intercambio de datos más rápido, pero por sí solos no reducen el consumo de tokens.