El 2 de noviembre, Anthropic abrió en Claude Platform la beta pública de message threads. El desarrollador añade un parámetro thread a la solicitud de la Messages API, envía la conversación completa en el primer turno y, en los siguientes, solo los mensajes nuevos y el ID de la respuesta anterior; el servidor se encarga de recomponer la conversación.
La cifra oficial procede de Claude Code. La función ya está activada por defecto para la mayoría de sus usuarios y, en solicitudes de 500k a 1M de tokens, la mediana del tiempo hasta el primer token bajó cerca de un 35 %. El blog no detalla el efecto en otros rangos de longitud.
La beta abarca la API de Claude, Claude Platform on AWS, Microsoft Foundry y Claude alojado por Anthropic en Google Cloud. Los modelos que figuran en la documentación van desde Sonnet 4.5 y Opus 4.5 hasta Fable 5.1 y Mythos 5.1.
Lo que se ahorra es la validación y la tokenización
Sin hilos, el agente tiene que volver a subir toda la conversación en cada ronda, y la API debe validarla y tokenizarla otra vez. Cuanto más larga es la sesión, más tarda esa preparación. Los agentes de uso del equipo salen especialmente perjudicados, porque las capturas de pantalla del historial se reenvían en cada turno.
Los hilos guardan ese contenido en la memoria del servidor, de modo que lo que hay que procesar se reduce prácticamente al turno recién añadido.
Claude sigue leyendo la conversación completa en cada turno, así que los tokens del lado del modelo no disminuyen, y la facturación y los límites de uso siguen las reglas actuales. Una cuenta aproximada: en una sesión de 800.000 tokens con 2.000 tokens nuevos por turno, lo que viaja en la solicitud con hilos es aproximadamente una cuatrocientosava parte de antes, pero los tokens de entrada en la factura siguen superando los 800.000. Para ahorrar dinero sigue haciendo falta el almacenamiento en caché de prompts, que es otro interruptor: la solicitud de hilo puede incluir cache_control en el nivel superior; si no se añade, aunque solo se envíen mensajes nuevos no se guardará nada en caché.
Al integrarlo, hay que dejar una vía de retirada
La documentación define el hilo como "de mejor esfuerzo" (best effort), y eso condiciona la forma de integrarlo.
- Caducidad: el hilo caduca 5 minutos después de la última solicitud, cada respuesta almacenada reinicia el contador y, como máximo, se elimina 1 hora después del último uso.
- Invalidez: si una solicitud de continuación devuelve 404, hay que volver a enviar la conversación completa y abrir un hilo nuevo. La respuesta no indica si el turno actual se guardó correctamente; solo se sabe en la siguiente solicitud de continuación.
- Copia: la versión de referencia de la conversación sigue estando en la aplicación. Las utilidades de los SDK oficiales mantienen una copia en memoria y la reenvían automáticamente; al terminar el proceso se pierde, y quien necesite persistencia entre procesos debe guardarla por su cuenta.
- Campos fijos:
systemytoolssolo se envían al crear el hilo; incluirlos en una continuación, aunque sea como null, provoca un error 400. Campos comomodel,thinking,tool_choiceymcp_serversdeben reenviarse sin cambios en cada turno; si se modifican, se devuelvethread_fingerprint_mismatch. Para cambiar el prompt de sistema o las herramientas, solo cabe abrir un hilo nuevo.
También hay una limitación de cumplimiento normativo. El contenido de los hilos se almacena cifrado en memoria y no se escribe en almacenamiento persistente, pero la función no cumple los requisitos de cero retención de datos (ZDR). Las empresas con contrato ZDR pueden usar el resto de funciones sin problema, pero no los hilos.
Conviene además distinguir: Claude Managed Agents también tiene session threads, y son algo distinto de los message threads de esta ocasión.
Una pieza que faltaba
La Responses API de OpenAI tiene desde hace tiempo previous_response_id, que igualmente pasa un ID para continuar el contexto anterior. Anthropic exigía desde hacía mucho que el cliente enviara el historial completo en cada turno, lo que tiene la ventaja de ser sin estado y de implementación directa, a costa de latencia cuando la sesión se alarga. El enfoque actual es un punto intermedio: el estado permanece en el servidor solo un breve tiempo, si se pierde se reenvía, y la copia del lado del cliente sigue siendo imprescindible.
Por los escenarios de uso que menciona Anthropic, los destinatarios principales son los agentes de programación de larga duración, los agentes de uso del equipo y los flujos de trabajo con muchos documentos e imágenes. Anthropic también activó primero la función por defecto en su propio Claude Code y después la abrió a los usuarios de la API.
Sobre cuánto mejoran las conversaciones corrientes de menos de unos cientos de miles de tokens, Anthropic no ofrece cifras; la documentación solo dice que los hilos ayudan más en bucles largos de agentes. Los equipos que construyen sus propios agentes pueden empezar midiendo con la distribución de longitud de sus sesiones y decidir después si vale la pena escribir una capa más de código para la ruta de reenvío tras el 404.
Fuentes: blog oficial de Claude, CocoLoop, documentación para desarrolladores de Claude Platform; la reducción de latencia sigue la mediana de Claude Code publicada por la compañía, y la cuenta aproximada es una estimación de la redacción.