Anthropic suma hilos de mensajes a la API de Claude para que los agentes largos no reenvíen todo

Anthropic lanzó el 2 de noviembre, en beta pública, los hilos de mensajes (message threads). La función apunta a un problema poco vistoso de la ingeniería de agentes: la Messages API no guarda estado, así que un agente que trabaja durante mucho tiempo vuelve a subir la conversación entera en cada turno, y la API tiene que recibirla, validarla y tokenizarla de nuevo antes de que el modelo empiece a responder. Cuanto más avanza el agente en una tarea, más de cada turno se va en ese trabajo extra.

Cómo funciona

Según la documentación, alcanza con agregar un campo `thread` a un pedido normal de la Messages API. El primer pedido manda la conversación completa, con el system prompt y las herramientas, y marca el hilo como "create". La API guarda esa conversación, incluida la respuesta de Claude, bajo el ID de la respuesta. Cada pedido posterior usa el tipo "continue", pasa el ID de la respuesta anterior y lleva solo los mensajes nuevos. El system prompt y las herramientas no se vuelven a mandar: el hilo conserva los del primer pedido.

La función usa el encabezado beta `message-threads-2026-08-12`, y los SDK de Anthropic traen un helper que arma estos pedidos y se encarga de la recuperación. Está disponible en la API de Claude, Claude Platform on AWS, Claude Models on Google Cloud (operado por Anthropic) y Claude in Microsoft Foundry, según las notas de versión.

Qué ahorra y qué no

La ganancia es de latencia, no de costo. El anuncio de Anthropic aclara que Claude sigue leyendo la conversación completa en cada turno, así que el consumo de tokens no cambia, y se mantienen los precios y los límites de uso de siempre. El prompt caching tampoco cambia: los hilos no cachean nada por su cuenta, y sos vos quien decide dónde van los puntos de caché, con un máximo de cuatro por pedido con hilo.

La cifra principal es de la propia Anthropic. La empresa dice que los hilos ya vienen activados por defecto para la mayoría de los usuarios de Claude Code, y que en pedidos de 500.000 a 1 millón de tokens la mediana del tiempo hasta el primer token baja cerca de 35%. No da números para contextos más cortos; solo dice que el beneficio crece con la cantidad de contexto que carga el agente. Todavía no hay una medición independiente.

Las limitaciones

Los hilos duran poco a propósito. Un hilo vence 5 minutos después del último pedido y se borra, como máximo, una hora después de su último uso. El contenido se guarda en memoria, cifrado, y nunca se escribe en almacenamiento persistente. Cuando un hilo ya no se puede continuar, la API devuelve un 404 y hay que reenviar toda la conversación en un nuevo pedido "create". La documentación pide guardar una copia propia de cada mensaje y construir ese camino de recuperación desde el principio.

• Los hilos solo crecen. Para compactar una conversación, tenés que escribir vos el resumen y arrancar un hilo nuevo con él; la compactación integrada no funciona con hilos.
• No son compatibles con Message Batches, el conteo de tokens ni la mayor parte de la edición de contexto, y un pedido que los use se rechaza.
• Campos como el modelo, la configuración de thinking o tool_choice tienen que ser idénticos en todo el hilo; si cambian, la API devuelve un error 400.
• Después de un rechazo, o de una respuesta escrita por un modelo de respaldo, el hilo no puede seguir desde esa respuesta y hay que empezar otro.
• La función no es elegible para retención cero de datos, y las organizaciones con HIPAA readiness activado no la pueden usar.

Qué cambia para quien desarrolla

Si corrés agentes de código, agentes de uso de computadora o flujos con muchos documentos sobre Claude, esto es sobre todo una optimización de latencia y de ancho de banda que convive con el prompt caching en lugar de reemplazarlo. El caché reduce lo que pagás por el contexto repetido y puede acelerar su procesamiento; los hilos evitan directamente tener que reenviarlo. El vencimiento de 5 minutos encaja con el ritmo de un agente activo, pero los agentes que se frenan a esperar una revisión humana o herramientas lentas van a caer seguido en el reenvío completo. Por eso la lógica de recuperación es obligatoria, no un caso borde.

También hay un trade-off de diseño. Hoy muchos frameworks de agentes reescriben el historial en cada turno: recortan salidas de herramientas o reemplazan turnos viejos por resúmenes. Un hilo solo agrega, así que ese manejo del contexto tiene que hacerse en cortes deliberados, arrancando un hilo nuevo. Los equipos que editan el historial de forma agresiva pueden sacarle menos provecho que los que dejan crecer el loop sin tocarlo.