Arquitectura de agentes
Claude añade hilos temporales para enviar menos historial en los agentes
Message Threads reduce lo que envía cada turno, pero no cambia las tarifas. Cómo funciona la beta, cuándo caduca y cómo recuperar la conversación.
Menos historial viajando en cada petición
Claude permite continuar una conversación enviando solo los mensajes nuevos y el identificador de la respuesta anterior. Message Threads, anunciado el 2 de noviembre y todavía en beta, apunta a reducir el tiempo hasta el primer token en conversaciones largas. No cambia las tarifas ni los límites de uso: transportar menos texto no significa que el modelo deje de recibir el contexto anterior.
La mejora interesa cuando un agente encadena muchas consultas y herramientas. Antes de cambiar de modelo para ganar velocidad, conviene separar cuánto tarda la petición en llegar y prepararse de cuánto tarda la generación. Si el cuello de botella está en una herramienta externa, esta optimización puede dejar casi intacta la espera que percibe el usuario.
El hilo temporal no sustituye al historial propio
La primera petición crea el hilo con la conversación, las instrucciones y las herramientas. Las siguientes añaden mensajes; no vuelven a enviar system ni tools. Hay que activar la cabecera message-threads-2026-08-12 y continuar desde el último identificador. La disponibilidad anunciada incluye Claude API, Claude Platform on AWS, Google Cloud gestionado por Anthropic y Microsoft Foundry.
Un asistente de soporte podría consultar un pedido y después recibir una pregunta sobre la entrega. Es un ejemplo de diseño, no una prueba ejecutada aquí: el segundo turno enviaría la pregunta nueva, mientras la aplicación conservaría también la conversación completa. Así la experiencia no dependería de que una copia temporal del proveedor siguiera disponible.
El hilo solo admite añadir mensajes y cada respuesta puede continuarse una vez. Para bifurcar o editar el historial hay que crear otro hilo. Conviene resolver esa coordinación antes de lanzar varias ramas del agente sobre la misma conversación.
| Situación | Comportamiento documentado |
|---|---|
| Continuación normal | Enviar mensajes nuevos y el último identificador. |
| Cinco minutos sin uso | El hilo caduca; una continuación puede devolver 404. |
| Recuperación | Crear otro hilo con la conversación completa. |
| Retención del hilo | Borrado como máximo una hora después del último uso. |
La caché resuelve otra parte del coste
Prompt caching permite reutilizar prefijos y tiene su propio esquema de lecturas y escrituras. Un hilo no activa esa caché por sí solo. Son decisiones complementarias: una reduce el trabajo de reenviar la conversación y la otra permite aprovechar contenido ya procesado, cuando se cumplen sus condiciones.
Para evaluar el cambio mediría por separado el tamaño enviado, el tiempo hasta el primer token, el tiempo total y el coste de una tarea resuelta. Un resultado más rápido que necesita repetir una operación puede acabar saliendo peor. Tampoco usaría una reducción del tráfico como porcentaje de ahorro de inferencia: son magnitudes distintas.
La prueba útil incluye una pausa larga y un reinicio del proceso cliente. Si ambos rompen el flujo, falta recuperación. Guardar el historial permite reconstruir la conversación, pero una acción externa necesita además su propio control de duplicados: volver a enviar mensajes no debería volver a cobrar, reservar o modificar el mismo registro.
Cuándo lo incorporaría a un agente
Lo probaría en un bucle conversacional largo que ya guarde sus mensajes y pueda recuperar el estado. Compararía el mismo conjunto de tareas con y sin hilos antes de convertirlo en la ruta habitual. Mantendría la versión anterior como alternativa mientras se valida la beta; la novedad es una opción de transporte, no una razón para rediseñar todo el asistente.
Hay además una condición de tratamiento de datos que cambia la decisión: Anthropic indica que Message Threads no es elegible para Zero Data Retention ni HIPAA. Cifrar el hilo en memoria y borrarlo después no equivale a retención cero. Si el proyecto exige ese tratamiento, esta función no encaja aunque mejore la latencia.
El criterio sería sencillo: introducirlo si reduce una espera medida y la recuperación conserva el comportamiento esperado. La copia del historial y el registro de acciones siguen perteneciendo a la aplicación. Esa separación permite aprovechar una optimización temporal sin convertirla en la única memoria del producto.