LO ESENCIAL EN 30 SEGUNDOS

  • Con un thread, el desarrollador envía una vez la conversación completa y después solo los mensajes nuevos y el ID de la respuesta anterior; el prompt de sistema y las herramientas se conservan.
  • Anthropic informa de un tiempo hasta el primer token cerca de un 35 % menor en peticiones de 500.000 a un millón de tokens, según The Decoder.
  • Los threads caducan cinco minutos después de la última petición, no cambian precios ni límites de uso y no admiten la retención cero de datos.

Anthropic ha publicado Message Threads, una función en beta pública de su API Messages orientada a agentes que trabajan durante mucho tiempo. Hasta ahora, cada llamada tenía que incluir todo el historial de la conversación, que el servicio volvía a validar y tokenizar en cada turno. Un thread permite que el servidor guarde ese historial durante un rato, así que cada petición nueva solo contiene lo que ha cambiado.

Cómo funcionan los threads

Según la documentación de Anthropic, el desarrollador abre un thread enviando la primera petición como siempre, con la conversación completa, el prompt de sistema y las herramientas, y añadiendo un nuevo parámetro thread en modo de creación. En los turnos siguientes solo se mandan los mensajes nuevos y el ID de la respuesta anterior. El prompt de sistema y las herramientas no se reenvían, porque el thread conserva los de la primera llamada, y algunos ajustes, como el modelo, deben mantenerse iguales o la API devuelve un error. Los SDK de Anthropic incluyen un asistente que construye estas peticiones.

La ventaja principal que señala la empresa es la latencia. Como informa The Decoder, Anthropic midió una reducción de aproximadamente el 35 % en el tiempo hasta el primer token para peticiones de entre 500.000 y un millón de tokens. El consumo de tokens no baja, ya que el modelo sigue leyendo todo el historial, y la documentación aclara que los threads no modifican los precios ni los límites de uso. El almacenamiento en caché de prompts sigue teniendo que pedirse aparte.

Límites y tratamiento de datos

Los threads funcionan según disponibilidad. Cada uno caduca cinco minutos después de su última petición y, si ya no puede continuarse, la API devuelve un error 404. Por eso los desarrolladores deben guardar su propia copia de la conversación y poder reenviarla completa, algo que la documentación pide preparar desde el principio.

La función no es compatible con Message Batches, el conteo de tokens, la compactación ni con la mayoría de opciones de edición de contexto, y no está disponible para organizaciones que tengan activada la preparación para HIPAA. Anthropic afirma que el contenido de un thread se guarda en memoria, cifrado con una clave gestionada por el servidor, nunca se escribe en almacenamiento duradero y se elimina como máximo una hora después de su último uso. Aun así, no es elegible para la retención cero de datos, lo que puede pesar para clientes con acuerdos estrictos.

La beta funciona en la API de Anthropic y también en AWS, Google Cloud y Microsoft Foundry, y está pensada sobre todo para agentes de programación y agentes que manejan un ordenador.