Claude Code reduce un 35% la espera con hilos de conversación

Claude Code reduce un 35% la espera con hilos de conversación

Anthropic afirma que la espera baja un 35% en solicitudes de Claude Code de entre 500.000 y un millón de tokens al evitar que el cliente retransmita toda la conversación en cada turno. La función, llamada message threads, está disponible en beta pública para la Messages API y ya se encuentra activada por defecto para la mayoría de usuarios de Claude Code.

El cambio reduce el trabajo previo a la respuesta: después de enviar el historial completo una vez, el cliente puede mandar solo los mensajes nuevos y la referencia a la respuesta anterior. Pero no reduce la cantidad de contexto que procesa Claude. La conversación completa sigue reconstruyéndose en el servidor y el modelo la lee en cada turno, por lo que el uso de tokens no cambia.

Anthropic anunció la función el 2 de noviembre. No está limitada a Claude Code: también puede usarse desde la Messages API para crear agentes propios, incluidos los que manejan llamadas repetidas a herramientas, capturas de pantalla o grandes cantidades de documentos e imágenes.

Menos historial repetido antes de cada respuesta

Hasta ahora, cada petición a la Messages API incluía el historial entero: mensajes anteriores, resultados de herramientas y cualquier otro contenido acumulado. En una sesión larga de programación, un agente puede realizar cientos de solicitudes mientras lee archivos y modifica código. Cuando la conversación llega a cientos de miles de tokens, volver a enviar todo ese material añade carga antes de que Claude empiece a responder.

Con un hilo, la primera solicitud sigue incluyendo la conversación completa, además de las instrucciones de sistema y las definiciones de herramientas. Esa petición crea el hilo en los servidores de Anthropic. En las siguientes, el cliente transmite solo lo nuevo y el identificador de la respuesta anterior. Anthropic reconstruye allí el contexto completo antes de pasárselo al modelo.

La diferencia está en lo que viaja desde la aplicación hasta la API, no en lo que Claude tiene que leer. La compañía mide el resultado con el tiempo hasta el primer token (TTFT): el tiempo que transcurre hasta que comienza a generar una respuesta. Para peticiones de Claude Code con entre 500.000 y un millón de tokens, Anthropic comunica una reducción mediana de aproximadamente el 35%.

Ese porcentaje se refiere al TTFT en ese rango de contexto, no al tiempo total de una tarea ni a todas las solicitudes. La documentación de Anthropic presenta los hilos como especialmente útiles en sesiones activas y largas, donde se acumulan resultados de herramientas, cambios en archivos u otros datos que antes se volvían a transmitir.

La mejora no rebaja la factura de tokens

Anthropic mantiene la facturación habitual porque Claude sigue procesando el historial completo en cada turno. También se mantienen las tarifas estándar de tokens y los límites de uso existentes. Message threads reduce el tamaño de las solicitudes posteriores y el trabajo de validación y tokenización de los datos que vuelven a llegar a la API, pero no elimina ese contexto del procesamiento del modelo.

La empresa señala que los hilos pueden combinarse con el prompt caching, su función de caché de prompts. Son mecanismos distintos: los hilos evitan retransmitir mensajes anteriores desde el cliente; la caché permite reutilizar contenido procesado y puede aplicar tarifas reducidas a las lecturas de caché. Anthropic indica que ambos pueden funcionar a la vez, pero activar un hilo no activa por sí solo la caché.

Los agentes que envían archivos grandes repetidamente podrían notar una diferencia especialmente visible en los datos transmitidos. Guillaume Lebedel, cofundador y CTO de StackOne, calculó en una simulación el efecto posible para agentes de uso del ordenador. Su ejemplo supone que el agente captura una imagen de 150 KB en cada paso: en la petición número 50, el método anterior acumularía unos 7,5 MB de capturas, frente a unos 0,15 MB si solo se envía la última.

“Mi apuesta: los agentes de uso del ordenador lo adoptarán antes que los agentes de programación, porque una captura por paso es lo que hace pesada la retransmisión”.

— Guillaume Lebedel, cofundador y CTO de StackOne

En ese mismo ejemplo, Lebedel estima que la cantidad acumulada de capturas transmitidas a lo largo de 50 pasos pasaría de unos 191 MB a 7,5 MB, alrededor de 25 veces menos. Son cálculos basados en una simulación, no en una prueba de la API en funcionamiento. Lebedel pronosticó que los agentes de uso del ordenador podrían impulsar la adopción de la función antes de que termine el año.

Un hilo puede caducar tras cinco minutos

La beta tiene un límite de inactividad breve: el hilo deja de poder continuarse tras cinco minutos sin actividad. Cada respuesta que la API almacena reinicia ese plazo. Si la aplicación intenta continuar un hilo que ya no está disponible, la API devuelve un error 404; el cliente debe enviar de nuevo la conversación completa y crear otro hilo.

Eso no significa que el usuario pierda necesariamente el contexto. Anthropic recomienda que la aplicación conserve su propia copia de todos los mensajes, porque el historial guardado temporalmente en el servidor no sustituye al registro local. El helper de hilos de su SDK puede volver a enviar la conversación automáticamente cuando sea necesario. En una integración propia, el desarrollador debe gestionar la caducidad y la recuperación.

Anthropic indica además que el contenido de los hilos se mantiene cifrado en memoria del servidor y no se escribe en almacenamiento persistente. Aunque la continuación caduca a los cinco minutos, los datos pueden permanecer en memoria hasta una hora después del último uso. La documentación precisa que el servidor puede borrar el hilo dentro de ese plazo máximo.

La función no cumple los requisitos de zero data retention ni los de HIPAA. Por tanto, esos límites de tratamiento de datos pueden impedir su uso en determinados entornos. Anthropic también señala que algunas capacidades de gestión de contexto, incluida la compactación bajo demanda, no son compatibles.

Cómo se activa en la Messages API

La API añade el parámetro thread. En la primera petición se usa thread: {"type": "create"} junto con el historial completo, las instrucciones de sistema y las herramientas. En las siguientes, se envían los mensajes nuevos y thread: {"type": "continue", "previous_message_id": "..."}, con el identificador de la respuesta anterior.

Al continuar un hilo, las instrucciones de sistema y las herramientas no se vuelven a enviar: se conservan las de la petición que lo creó. Las solicitudes directas deben incluir también la cabecera beta message-threads-2026-08-12. El SDK de Python ofrece un helper que gestiona el inicio, la continuación y esa cabecera. El helper conserva una copia de la conversación en memoria mientras existe el objeto; si la aplicación necesita que el historial sobreviva a un reinicio, debe guardarlo por su cuenta.

La documentación impone otras condiciones para las integraciones directas. El hilo es de solo añadido y cada identificador de respuesta puede continuarse una sola vez; hay que usar el ID más reciente. Para editar un turno anterior o abrir una rama, se crea otro hilo a partir de la copia local. Si una continuación ya no es posible, la aplicación debe reproducir el historial completo en una nueva petición de creación.

La función está en beta pública para todos los modelos Claude y puede usarse en Claude Platform, Claude Platform en AWS, Claude en Microsoft Foundry y los modelos Claude gestionados por Anthropic en Google Cloud. Anthropic no ha anunciado en estos materiales una fecha para que salga de beta.

Fuentes: The New Stack, The Decoder, Claude, Claude Platform Docs, TNW | Anthropic, TechRounder, Times of AI