Claude ya no necesita que le reenvíes toda la conversación: llegan los message threads

Anthropic lanzó el 2 de noviembre de 2026, en beta pública, los message threads de la Messages API. Con ellos, una conversación larga ya no tiene que reenviarse completa en cada turno: el servidor la guarda por un rato y tu código manda solo los mensajes nuevos. La promesa es menor tiempo hasta el primer token (TTFT) en sesiones largas. Según Anthropic, en Claude Code baja cerca de 35% en solicitudes de 500,000 a un millón de tokens. Si tienes un agente que da cientos de vueltas con herramientas, o un bot que arrastra historial, esto te toca. Ojo: no te baja la factura.

El problema que ataca

La Messages API es stateless: el servidor no recuerda nada entre solicitudes. Cada turno de un agente manda otra vez el system prompt, las definiciones de herramientas y todo el historial, incluidos los resultados de herramientas y las capturas de pantalla. La documentación lo explica así: sin un hilo, cada turno vuelve a subir la conversación entera y la API la valida y la tokeniza otra vez.

Con 20,000 tokens de historial eso casi no se nota. Con 500,000 sí. Anthropic pone el ejemplo de un agente de programación que hace cientos de solicitudes en una sola sesión: cada una carga con todo lo anterior, y ese reenvío agrega tiempo antes de que Claude empiece a contestar.

Cómo funciona

El mecanismo es sencillo y cabe en un parámetro nuevo, thread, más el encabezado beta message-threads-2026-08-12, que va en todas las solicitudes del hilo:

Crear. La primera solicitud va como siempre, con la conversación completa, system y tools, y se le agrega "thread": {"type": "create"}. La API guarda la conversación, incluida la respuesta de Claude, bajo el id de esa respuesta.
Continuar. En los turnos siguientes mandas solo los mensajes nuevos y "thread": {"type": "continue", "previous_message_id": "<id anterior>"}. No se vuelven a enviar system ni tools: si los mandas, aunque sea como null, la API responde con un error 400.
Repetir desde cero. El hilo es best-effort. Expira 5 minutos después de la última solicitud y se borra a más tardar una hora después de su último uso. Si ya no se puede continuar, la API responde 404 con el código thread_not_found y te toca reenviar toda la conversación en un nuevo create.

Diagrama que compara qué se envía en cada turno sin thread, donde la solicitud crece con todo el historial, y con thread, donde solo viaja el mensaje nuevo

Los SDK traen un helper (client.beta.messages.thread(...) en Python) que arma estas solicitudes, agrega el encabezado y hace solo la repetición cuando el hilo se pierde. También el tool runner beta del SDK usa hilo por defecto. Un detalle importante: el helper guarda la conversación solo en memoria, mientras existe el objeto. Si tu proceso se reinicia, la copia se va con él.

Lo que no cambia: el costo

Aquí está la letra chica que más importa. Anthropic dice que, aunque cada solicitud sea más pequeña, Claude sigue leyendo la conversación completa en cada turno, así que el consumo de tokens es el mismo. La documentación lo confirma: los hilos no cambian precios ni límites de uso.

Tampoco te cachean nada solos. El prompt caching funciona igual que sin hilo: tú decides dónde van los puntos de caché. Para cachear cada turno hay que mandar un cache_control en el nivel superior de cada solicitud del hilo, y hay un tope de 4 puntos de caché por solicitud. Si quieres ahorrar dinero, el camino sigue siendo el caché. El hilo ahorra tiempo.

Las reglas que te pueden morder

La documentación separa los campos en tres grupos, y conviene tenerlo claro antes de migrar:

Grupo	Campos	Regla
Solo en el `create`	`system`, `tools`	Mandarlos en un `continue` da error 400
Fijos	`model`, `tool_choice`, `thinking`, `mcp_servers`, `output_config`, `cache_control` superior, encabezados beta, entre otros	Deben llevar el mismo valor en todo el hilo; si cambian, error `thread_fingerprint_mismatch`
Libres	`max_tokens`, `stop_sequences`, `stream`, `metadata`, `service_tier`	Pueden cambiar entre turnos

Otras reglas que salen de la misma documentación:

El hilo solo crece. Cada id se puede continuar una sola vez y no se puede editar ni ramificar un mensaje viejo. Para corregir, compactar con un resumen o cambiar de herramientas, hay que abrir un hilo nuevo.
La API no revisa duplicados. Si reenvías un mensaje que ya estaba, puede aparecer dos veces en la conversación o devolver un error.
Streaming: el id llega en message_start, pero solo puedes continuar después de message_stop.
Rechazos y modelos de respaldo: después de un stop_reason: "refusal" no se continúa el hilo, y un turno que escribió un modelo de fallback no se guarda.
Mismo dueño: el hilo solo se puede continuar con la misma organización, el mismo espacio de trabajo y la misma llave o cuenta de servicio que lo creó.
Sin soporte para Message Batches, conteo de tokens, compactación bajo demanda, la mayor parte de context editing, organizaciones con HIPAA ni las que tienen inference hooks activados.
No hay API para listar, leer ni borrar hilos.

Privacidad

Anthropic dice que guarda el hilo en memoria, cifrado con una llave que administra el servidor, que nunca lo escribe en disco y que lo borra a más tardar una hora después de su último uso. Aun así, la función no es elegible para Zero Data Retention ni para HIPAA. Si tu organización tiene ZDR por contrato, revisa esto antes de prenderlo.

Dónde está disponible

Según las notas de la versión, la beta funciona en la API de Claude, en Claude Platform on AWS, en Claude Models on Google Cloud (administrado por Anthropic) y en Claude in Microsoft Foundry, con todos los modelos. Anthropic ya lo tiene activado por defecto para la mayoría de los usuarios de Claude Code.

Lo que esto significa

Mi lectura: es una optimización de transporte, no de inteligencia. El modelo no recuerda más ni razona mejor; tu solicitud simplemente pesa menos y llega antes. Anthropic dice que donde más se nota es en agentes de programación, agentes de computer use (las capturas se quedan en el hilo en lugar de subirse en cada turno) y flujos con muchos documentos o imágenes.

Para un bot de WhatsApp con conversaciones cortas y espaciadas, la ganancia es poca: si el cliente tarda más de 5 minutos en contestar, el hilo ya expiró y vuelves a mandar todo. Donde sí cambia la experiencia es en agentes que encadenan herramientas sin parar y acumulan cientos de miles de tokens.

La regla de oro que repite la documentación es que tu aplicación sigue siendo la fuente de verdad: guarda tu propia copia de cada mensaje y construye desde el principio la ruta para repetir la conversación completa. Ninguna respuesta te dice si el turno quedó guardado; te enteras hasta el siguiente continue. Quien trate el hilo como una base de datos va a tener sorpresas.

No lo probé; todo esto sale de la documentación oficial de Claude Platform, el anuncio de Anthropic y la cobertura citada abajo.