Hilos de mensajes de Claude: cuándo reducen la latencia de los agentes y cuándo no

Cada turno de un bucle largo de un agente de Claude vuelve a enviar a la API la conversación completa, incluidos todos los mensajes y resultados de herramientas anteriores, aunque la API ya procesó todo ese historial un turno antes. Los hilos de mensajes de Claude, una función en beta pública de la Claude Messages API, están diseñados para eliminar esa repetición.

Los hilos reducen cuánto envía tu cliente en cada turno y cuánto vuelve a procesar la API, lo que puede bajar el tiempo hasta el primer token en sesiones muy largas. El uso de tokens, el costo y el consumo de límites de tasa siguen igual, y la copia de la conversación en el servidor puede desaparecer en cualquier momento. Esa combinación es la razón por la que recomendamos un enfoque que llamamos Transcript-First Threading (hilos con la transcripción primero): tu lado conserva la conversación completa, y el hilo del servidor es una aceleración que estás preparado para perder.

Qué cambian los hilos de mensajes en un bucle de agente de Claude

Sin un hilo, cada turno vuelve a subir la conversación completa, y la API vuelve a validarla y tokenizarla por completo, tal como describe la documentación oficial de los hilos de mensajes.

En las cargas de trabajo de agentes, esa sobrecarga se acumula. Un agente de programación puede hacer cientos de solicitudes en una sola sesión, y cada solicitud reenvía todos los mensajes y resultados de herramientas anteriores.

Con un hilo, la API mantiene la conversación en la memoria del servidor entre turnos. El anuncio de lanzamiento de Anthropic describe el lado del cliente sin rodeos: en lugar de reenviar la conversación completa, envías solo los mensajes nuevos y el ID del mensaje anterior.

Los hilos de mensajes se lanzaron en beta pública en la Messages API el 2 de noviembre de 2026, con el encabezado beta message-threads-2026-08-12, según las notas de la versión de Claude Platform. Ten en cuenta que la fecha incluida en el nombre del encabezado no es la fecha de lanzamiento.

Los hilos son una optimización de transporte y preprocesamiento. Cambian cuántos datos viajan y cuánto trabajo repite la API antes de que empiece la generación, pero no tocan la entrada del modelo: Claude sigue leyendo la conversación completa en cada turno.

Cómo empieza, continúa y caduca un hilo

Activación

Para activarlos, añades el encabezado beta a una solicitud de la Messages API que por lo demás es normal. Los nombres de los campos y la forma de las solicitudes pueden cambiar durante una beta, así que toma la sintaxis exacta de la documentación oficial y vuelve a comprobarla cuando las notas de la versión mencionen cambios.

Caducidad

Un hilo funciona según el principio de mejor esfuerzo. Caduca 5 minutos después de su última solicitud, y cada respuesta que la API almacena reinicia el temporizador de 5 minutos. En la práctica, un hilo vive mientras tu agente mantenga un ritmo constante de solicitudes.

Almacenamiento y eliminación

La API mantiene un hilo en memoria, cifrado con una clave gestionada por el servidor, nunca lo escribe en almacenamiento duradero y lo elimina como máximo 1 hora después de su último uso. Es posible que tu revisión de tratamiento de datos aún deba registrar esta retención breve, y nada duradero en tu sistema debería depender de ella.

La señal que falta

Ni la solicitud de creación que inicia un hilo ni las solicitudes de continuación que se apoyan en él indican en su respuesta si la API almacenó ese turno. Solo lo descubres en la siguiente solicitud de continuación. La consecuencia práctica es fácil de pasar por alto: una respuesta correcta te dice que el turno se completó, no que el hilo seguirá ahí cuando vuelvas, así que cada solicitud de continuación necesita una ruta alternativa lista antes de enviarse.

Qué se vuelve más rápido y qué sigue igual

El anuncio de lanzamiento de Anthropic, según la cobertura de The New Stack, informa que, con los hilos de mensajes activados por defecto para la mayoría de los usuarios de Claude Code, las solicitudes de 500k a 1M tokens registran una caída de alrededor del 35% en la mediana del tiempo hasta el primer token. The New Stack define el tiempo hasta el primer token (TTFT) como el tiempo que tarda Claude en empezar a generar una respuesta.

El mismo patrón aparece en el tamaño de las solicitudes: AlphaSignal informa que la mediana de la carga útil de las solicitudes en sesiones largas de Claude Code se redujo de aproximadamente 800 KB a 1.8 KB. Nuestra interpretación de esa diferencia, y no algo que se haya publicado, es que en la parte final de una sesión larga casi todo lo que un cliente sin hilos envía por la red es historial que la API ya procesó.

Ambas cifras necesitan contexto antes de entrar en un documento de planificación. La cifra de latencia es una medición propia de Anthropic, tomada en solicitudes muy grandes de Claude Code, y la cifra de carga útil proviene de información secundaria. Juntas muestran que el efecto es real a esa escala. Dicen mucho menos sobre agentes con contextos modestos, sesiones cortas o largas pausas entre turnos, y esas son precisamente las cargas de trabajo en las que la sobrecarga que eliminan los hilos es menor. Trata las cifras publicadas como prueba de que el mecanismo funciona, y tus propias mediciones, que se explican en la guía práctica más abajo, como la prueba de que funciona para ti.

Sin embargo, cargas útiles más pequeñas no significan una factura más pequeña. El uso de tokens sigue igual con los hilos, porque la entrada del modelo no cambia. The Next Web describió la función como una que ahorra tiempo pero deja el gasto donde estaba, y Anthropic afirma que los precios y los límites de tasa no cambian. Cualquier reducción del trabajo de red o de serialización en tu lado es algo que hay que medir, no suponer.

Dónde no se aplican los hilos: exclusiones e incompatibilidades

No todas las partes de la plataforma funcionan con hilos. La cobertura de Unite.AI resume las principales exclusiones: los hilos no admiten Message Batches, el conteo de tokens, la compactación bajo demanda ni la mayor parte de la edición de contexto, y no están disponibles para organizaciones que tengan activados los Inference hooks. Las restricciones de una beta cambian, así que confirma cada punto en la documentación oficial de los hilos de mensajes, que es la lista de referencia.

Si manejas datos regulados, la lista oficial no es lo único que debes revisar. Un comentario de un desarrollador en DEV Community aconseja no usar hilos cuando los turnos están separados por más de 5 minutos o cuando se aplican normas de ZDR o HIPAA. Es el consejo de un profesional, no una declaración de elegibilidad de Anthropic, así que confirma la situación de tu organización en la documentación oficial y directamente con Anthropic.

Si has ajustado con cuidado el almacenamiento en caché de prompts, revisa un límite antes de migrar: una solicitud con hilo puede llevar como máximo 4 puntos de interrupción cache_control, y el cache_control de nivel superior cuenta como uno. Las configuraciones que ya estén cerca de ese techo tendrán que rehacer sus puntos de interrupción.

El último punto está fuera de la plataforma de Anthropic. Si tu tráfico pasa por un gateway o un proxy, confirma que reenvía intactos el encabezado beta y la forma ligera de la solicitud de continuación, y que su lógica de reintentos y alternativas no supone que cada solicitud lleva el historial completo. Nuestra guía de producción de Vercel AI Gateway aborda las cuestiones de enrutamiento y control de proveedores que suelen surgir aquí.

Lista de decisión: ¿debería tu agente usar los hilos de mensajes de Claude?

Los argumentos a favor de los hilos se apoyan en que se cumplan tres condiciones a la vez: sesiones largas, contextos que crecen mucho a lo largo de muchas solicitudes y turnos que llegan muy seguidos. Si falla cualquiera de ellas, los argumentos se debilitan, como muestran las filas siguientes. Las filas marcadas como inferencia reflejan nuestro razonamiento a partir de cómo funciona la función, no una guía publicada.

La comprobación de preparación para Transcript-First Threading

Somete a cada agente candidato a estas preguntas:

• [ ] ¿Una sesión típica hace muchas solicitudes y acumula un contexto muy grande?
• [ ] ¿La conversación sigue una sola ruta, sin ramas que necesiten cada una su propio historial?
• [ ] ¿La mayoría de los turnos llegan con holgura dentro de la ventana de caducidad, con un reenvío planificado para cada pausa larga conocida, como suites de pruebas lentas o pasos de aprobación humana?
• [ ] ¿Tu transcripción local captura cada mensaje y resultado de herramienta, de modo que siempre sea posible un reenvío?
• [ ] ¿Tu pipeline está libre de las exclusiones anteriores, con la elegibilidad confirmada para cualquier carga de trabajo regulada?
• [ ] ¿Tu almacenamiento en caché de prompts cabe dentro del límite de puntos de interrupción, contando el de nivel superior?
• [ ] ¿El tiempo hasta el primer token en bucles largos es hoy un problema real de experiencia de usuario o de rendimiento?

La última pregunta es la más importante. Adopta los hilos cuando la latencia en los bucles largos esté perjudicando a tus usuarios o tu rendimiento. Si la motivación es una factura más pequeña, los hilos no la lograrán, y es mejor invertir el esfuerzo de ingeniería en otra cosa.

Guía práctica: cómo adoptar Transcript-First Threading

Con Transcript-First Threading, tu cliente es dueño de la conversación y el hilo del servidor es un acelerador temporal. The Next Web plantea lo mismo desde la dirección contraria: como los hilos caducan cinco minutos después de la última solicitud, los desarrolladores deben conservar su propia copia de cada conversación.

Paso 1: Mantén una transcripción local completa

Registra localmente cada mensaje y resultado de herramienta, sea cual sea el estado del hilo. Esa transcripción es tu fuente de verdad para reenvíos, depuración y auditoría, y el hilo del servidor nunca debería tener la única copia de nada. Si tu agente se ejecuta en un runtime de flujos de trabajo duraderos, guarda la transcripción junto con el resto del estado de la ejecución; nuestra lista de verificación para elegir el runtime de agentes de IA duraderos explica cómo elegir esa capa.

Paso 2: Envía solicitudes de continuación ligeras

Una vez que exista un hilo, envía solo el turno nuevo más el ID del mensaje anterior. Deja en su sitio el código que construye una solicitud completa y mantenlo cubierto por pruebas, porque tu ruta de reenvío depende de él.

Paso 3: Supón que cualquier continuación puede fallar

Como la API no confirma el almacenamiento, una solicitud de continuación puede fallar porque el hilo caducó o porque un turno nunca se almacenó. Escribe primero la alternativa: cuando una continuación falle por motivos del hilo, reenvía la transcripción local completa como una solicitud normal y empieza de nuevo. Después pruébalo de forma deliberada, por ejemplo dejando que un hilo caduque en staging, para saber que la salida del agente y el comportamiento de sus herramientas se mantienen tras un reenvío.

Paso 4: Controla el tiempo de inactividad entre turnos

Un agente que espera a una suite de pruebas lenta, o a que una persona apruebe una llamada a una herramienta, puede volver y encontrarse con un hilo muerto. Controla el tiempo transcurrido desde la última respuesta almacenada y, si una llamada a herramienta o una aprobación pendiente probablemente vaya a superar la ventana de caducidad, programa el reenvío en lugar de confiar en que el hilo aguante.

Paso 5: Audita tu almacenamiento en caché de prompts

Cuenta tus puntos de interrupción cache_control, incluido el de nivel superior, y asegúrate de que las solicitudes con hilo no superen el límite de 4. Es mucho mejor descubrir un exceso en una revisión que en una solicitud de producción rechazada.

Paso 6: Mide con tu propia carga de trabajo

Registra el tiempo hasta el primer token y el tamaño de las solicitudes antes y después de activar los hilos, desglosados por duración de la sesión. Registra también si cada turno se envió como solicitud de continuación o como reenvío completo, para ver con qué frecuencia sobreviven realmente los hilos en tu bucle. Si ya trazas las llamadas al modelo, nuestra guía de trazado GenAI con OpenTelemetry muestra un lugar práctico para capturar estas cifras. Cuando los turnos con hilo rara vez sobreviven, o el TTFT apenas cambia con tus duraciones de sesión reales, es una señal clara para limitar el uso de los hilos o desactivarlos. Las previsiones de facturación y de límites de tasa pueden quedarse como están, ya que los hilos no cambian el consumo.

Errores comunes al implantar los hilos de mensajes

El error más costoso ocurre en el caso de negocio, antes de escribir una sola línea de código. Una propuesta que promete ahorros de tokens, de precio o de límites de tasa gracias a los hilos es errónea y, una vez aprobada, el proyecto se juzgará con una cifra que nunca podrá alcanzar. Es posible obtener mejoras de ancho de banda o de serialización, pero solo deben entrar en un plan después de haberlas medido.

Muy cerca le sigue tratar una respuesta correcta como prueba de almacenamiento. Es una suposición fácil de hacer, y la documentación deja claro que no se cumple.

La mayoría de los errores restantes son pasos de la guía práctica que se saltan bajo la presión de los plazos: eliminar el historial local porque parece que el servidor lo tiene, dejar las herramientas lentas y las aprobaciones humanas sin un reenvío planificado, o descubrir una configuración de caché que excede el límite o una dependencia de Batches, del conteo de tokens, de la compactación bajo demanda o de la edición de contexto solo cuando el tráfico ya está en producción.

Advertencias y preguntas abiertas

Se trata de una beta pública. Los nombres de los encabezados, los límites y el comportamiento pueden cambiar, así que ancla tu implementación a la documentación oficial y sigue de cerca las notas de la versión.

Algunas preguntas merecen pruebas antes de que te apoyes en las respuestas. ¿Cómo se comportan los hilos cuando un agente ramifica una conversación? ¿Qué configuraciones reguladas son elegibles? ¿Cómo tratan tus proxies y gateways la forma ligera de la solicitud? Sobre la elegibilidad regulada, la recomendación citada en este artículo es un comentario de un desarrollador y no una declaración de Anthropic, así que acude directamente a Anthropic. Las otras dos se responden mejor ejecutando tus propios agentes con los hilos activados en un entorno de staging.