Anthropic reduce aproximadamente un 35% la latencia de Claude en conversaciones largas

Las conversaciones largas con Claude presentan una característica de ingeniería poco conveniente: el historial crece constantemente y la aplicación vuelve a enviarlo una y otra vez junto con cada mensaje nuevo. Imaginemos un agente que ya ha discutido los requisitos con el usuario, ha leído varios archivos y ha ejecutado una decena de acciones. Para pedirle que dé el siguiente paso, el desarrollador tiene que transmitir de nuevo toda la conversación acumulada. Esto aumenta el tamaño de la solicitud y el tiempo que transcurre hasta que comienza la respuesta.

Anthropic ha presentado los message threads para estos casos: flujos de mensajes disponibles en beta pública a través de la API. El historial completo se transmite una sola vez y, a partir de entonces, la aplicación envía únicamente los mensajes nuevos. La empresa afirma que, en sesiones muy largas, esto reduce aproximadamente un 35% la espera antes de la respuesta de Claude. Para el desarrollador, la ventaja es sencilla: se retransmite menos veces el mismo contexto, especialmente en agentes que permanecen activos durante más de una solicitud.

Cómo funciona en la práctica

Supongamos que un agente ayuda a un desarrollador a corregir un error. Primero recibe la descripción de la tarea, estudia el código, analiza una posible causa y propone cambios. Después, el usuario escribe: «Ejecuta las pruebas y comprueba el resultado». Con el esquema convencional, la aplicación puede volver a recopilar y enviar toda la conversación, desde el primer mensaje hasta el último. Con los message threads, la conversación original ya está vinculada al hilo, por lo que solo se añade la nueva instrucción.

Esto no significa que el modelo haya adquirido una memoria infinita ni que haya dejado de estar sujeto a la ventana de contexto. El cambio afecta principalmente a la forma en que la API transmite y almacena la secuencia de mensajes. Para un chatbot con un intercambio breve de dos mensajes, la diferencia puede ser imperceptible. En cambio, para un agente de investigación, un asistente de programación o un asistente corporativo interno con una sesión de trabajo larga, la mejora puede influir en la velocidad percibida del producto.

Dónde está la utilidad y dónde empieza el marketing

El 35% anunciado se refiere a la espera de la respuesta en sesiones muy largas, no a que todas las llamadas a Claude sean un tercio más rápidas. Anthropic no promete el mismo resultado para conversaciones cortas. Por eso, la cifra no puede extrapolarse a todo el producto: el efecto debe medirse en los flujos de trabajo propios, con una longitud de historial, un conjunto de herramientas y un tipo de solicitudes realistas.

Los precios y límites de la API permanecen sin cambios en el lanzamiento de la función. Por tanto, los message threads no deben interpretarse como un descuento automático. Aunque la aplicación transmita menos datos repetidos, la descripción publicada no permite concluir que la factura por procesar el contexto vaya a reducirse necesariamente. Por ahora, la principal ventaja anunciada es la latencia, no el coste.

También hay cuestiones operativas que la beta pública no elimina. El equipo necesita saber cuánto tiempo permanece disponible un hilo, qué ocurre si el historial asociado deja de estar accesible, cómo restaurar una conversación después de un fallo y cómo evitar mezclar los contextos de distintos usuarios. En el caso de datos sensibles, son especialmente importantes las reglas de conservación, eliminación y registro. Confiar en el identificador del hilo como única fuente del estado resulta arriesgado mientras el comportamiento de la función no se haya probado con carga real.

Qué deben hacer los desarrolladores

Es mejor empezar con un pequeño experimento que migrar el producto completo. Elija un flujo realmente largo —por ejemplo, un agente que trabaje con código— y compare la transmisión convencional del historial con los message threads. Mida el tiempo hasta el primer fragmento de la respuesta, la duración total de la solicitud, la frecuencia de errores y la calidad de la conservación del contexto. Pruebe por separado los reintentos, los mensajes simultáneos y la recuperación tras la interrupción de una sesión.

Si la latencia se reduce de forma apreciable sin introducir nuevos problemas de estado, la función puede ampliarse gradualmente a otros procesos con agentes. Si sus conversaciones son cortas, no hay motivo para cambiar la arquitectura con urgencia. Los message threads resuelven un problema concreto de las sesiones largas: eliminan el reenvío constante de conversaciones que ya son conocidas. Es una mejora útil de infraestructura, pero su valor debe determinarse mediante mediciones dentro de su producto, no por una cifra llamativa.