Hilos de mensajes

Con un “message thread” (hilo de mensajes), las solicitudes son más pequeñas, y el “time to first token” (tiempo hasta el primer token) se mantiene más bajo y más estable a medida que crece la conversación. Los hilos son más útiles en bucles de agente largos. Sin un hilo, cada turno vuelve a subir toda la conversación, y la API vuelve a validarla y tokenizarla por completo. Con un hilo, la mayor parte de ese trabajo abarca solo el turno nuevo.

Un “message thread” (hilo de mensajes) mantiene una conversación en el servidor durante un tiempo breve. Envías la conversación completa una vez, con tu indicación del sistema y tus herramientas. En cada turno posterior, envías solo los mensajes nuevos y el id de la respuesta anterior. La API reconstruye la conversación antes de llamar al modelo. Agregas un parámetro, thread, a una solicitud de la Messages API. La respuesta es el mensaje habitual.

Cómo funcionan los hilos de mensajes

• Crear. Envía tu primera solicitud como lo haces hoy, con la conversación completa, system y tools, y agrega "thread": {"type": "create"}. La API almacena la conversación, incluida la respuesta de Claude, bajo el id de la respuesta.
• Continuar. Envía solo los mensajes posteriores a la respuesta anterior y agrega "thread": {"type": "continue", "previous_message_id": "<previous id>"}. Deja system y tools fuera de la solicitud. El hilo conserva los valores de la solicitud de creación. Usa cada nuevo id de respuesta para el siguiente turno.
• Reproducir. Un hilo funciona según el mejor esfuerzo. Expira 5 minutos después de su última solicitud, y la API lo elimina como máximo 1 hora después de su último uso. Cada respuesta que la API almacena reinicia los 5 minutos. Si la API ya no puede continuar el hilo, una solicitud de continuación devuelve un error 404. Envía de nuevo la conversación completa en una nueva solicitud de creación y continúa desde el id de esa respuesta. El helper de hilos del SDK hace esta reproducción por ti (consulta Cómo se comporta el helper del SDK). Después de una respuesta de un modelo de respaldo, consulta Usar respaldos con un hilo.

Tu aplicación sigue siendo la fuente de verdad de la conversación. Conserva tu propia copia de cada mensaje y construye la ruta de reproducción desde el principio. Ninguna respuesta, ya sea a una solicitud de creación o de continuación, indica si la API almacenó ese turno. Lo descubres en la siguiente solicitud de continuación. El helper de hilos del SDK mantiene esta copia en memoria mientras existe el objeto helper, y no la guarda en ningún otro lugar. Si la conversación tiene que sobrevivir a tu proceso, conserva tu propia copia.

Usar un hilo con un SDK

El SDK tiene un helper de hilos que construye las solicitudes del hilo por ti. Créalo con los mismos campos que una solicitud de Messages y luego envíale un turno a la vez. El helper mantiene la conversación completa en memoria.

Este ejemplo tiene dos turnos. El helper crea un hilo en el primer turno y lo continúa en el segundo, y agrega el encabezado beta por ti. El cache_control de nivel superior es opcional. Solicita el “prompt caching” (almacenamiento en caché de prompts) en cada turno (consulta Almacenamiento en caché de prompts en un hilo). Sin él, cada turno posterior sigue enviando solo los mensajes nuevos, pero no se almacena nada en caché a menos que agregues puntos de interrupción de caché tú mismo.

client = anthropic.Anthropic()

# Crea el helper. Esta llamada no envía ninguna solicitud.
thread = client.beta.messages.thread(
    model="claude-opus-5-5",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    system="You are a support agent for Acme. Keep replies short.",
)

# Turno 1: el helper crea un hilo y envía la conversación completa
thread.send({"role": "user", "content": "Hi! I have a question about an order."})

# Turno 2: el helper continúa el hilo y envía solo el mensaje nuevo
second = thread.send(
    {"role": "user", "content": "How long does standard shipping usually take?"}
)

for block in second.content:
    if block.type == "text":
        print(block.text)

Enviar el campo thread tú mismo

Para construir las solicitudes del hilo tú mismo, por ejemplo con cURL, la CLI o el método create habitual de un SDK, agrega el campo thread a cada solicitud.

Envía el encabezado beta message-threads-2026-08-12 en cada solicitud de un hilo.

Este ejemplo crea un hilo en el primer turno y lo continúa en el segundo. El cache_control de nivel superior solicita el almacenamiento en caché de prompts en cada turno. Surte efecto una vez que la conversación supera la longitud mínima almacenable en caché.

client = anthropic.Anthropic()

# Turno 1: envía la conversación completa y crea un hilo
first = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    system="You are a support agent for Acme. Keep replies short.",
    messages=[{"role": "user", "content": "Hi! I have a question about an order."}],
    thread={"type": "create"},
    betas=["message-threads-2026-08-12"],
)

# Turno 2: envía solo el mensaje nuevo y el id de la respuesta del turno 1.
# Omite system y tools: el hilo los conserva.
second = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    messages=[
        {"role": "user", "content": "How long does standard shipping usually take?"}
    ],
    thread={"type": "continue", "previous_message_id": first.id},
    betas=["message-threads-2026-08-12"],
)

for block in second.content:
    if block.type == "text":
        print(block.text)

Qué enviar en cada solicitud

La API no almacena las URL de los servidores MCP, los tokens de autorización de MCP ni el id del contenedor. Envía mcp_servers y container en cada solicitud que los use. Un token de autorización de MCP puede cambiar entre solicitudes.

El helper de hilos del SDK deja system y tools fuera de las solicitudes de continuación por ti y vuelve a enviar los campos fijos en cada turno.

Si usas el respaldo del lado del servidor, envía el campo fallbacks en todas las solicitudes de un hilo o en ninguna. Consulta Usar respaldos con un hilo.

Para cambiar un campo solo de creación o fijo, inicia un nuevo hilo: envía la conversación completa en una solicitud de creación con los nuevos valores.

En Claude Fable 5.1, Claude Mythos 5.1, Claude Opus 5.5, Claude Sonnet 5.5 y Claude Haiku 5.5, cambiar system o tools invalida los bloques thinking y redacted_thinking que ya están en la conversación, y la solicitud de creación puede devolver un error 400. Para evitarlo, deja fuera todos los bloques thinking y redacted_thinking de la conversación que envías. El modelo responde entonces sin ese razonamiento anterior. Consulta Qué cuenta como una edición, Cuando prefix_mismatch_behavior no está establecido y Qué hace la API con un bloque no válido.

Envía solo los mensajes nuevos en una solicitud de continuación. La API no los compara con los mensajes que ya tiene. Un mensaje que vuelvas a enviar puede aparecer dos veces en la conversación, o la solicitud puede devolver un error. Por ejemplo, una solicitud de continuación que empieza con la respuesta anterior devuelve un error.

Los mensajes nuevos suelen comenzar con un mensaje user: tu siguiente turno de usuario, o los bloques tool_result que responden a un tool_use en la respuesta anterior. Si una respuesta se detiene con stop_reason: "pause_turn", reanúdala con una solicitud de continuación desde el id de esa respuesta y una lista messages vacía ("messages": []). Si esa solicitud devuelve un error 404, reproduce la conversación completa, incluida la respuesta pausada, en una nueva solicitud de creación. No envíes un nuevo mensaje user mientras el turno está pausado: la API lo rechaza. Con el helper de hilos del SDK, llama a send() sin mensajes: el helper envía esta solicitud y reproduce la conversación ante un error 404.

Un hilo es de solo anexado, y cada id de respuesta se puede continuar una vez. Continúa siempre desde el id de respuesta más reciente del hilo. Para editar o ramificar un mensaje anterior, inicia un nuevo hilo con una solicitud de creación. Para reemplazar turnos anteriores con un resumen, consulta Compactar una conversación.

Almacenamiento en caché de prompts en un hilo

Un hilo no almacena tu prompt en caché por ti. El almacenamiento en caché de prompts funciona igual que sin un hilo: tú eliges dónde van los puntos de interrupción de caché.

Para almacenar en caché cada turno, envía un cache_control de nivel superior en cada solicitud del hilo, como en el ejemplo anterior. La API lo aplica al último bloque de los messages de cada solicitud que se pueda almacenar en caché. Así, cada turno lee la conversación anterior desde la caché y escribe el turno nuevo en ella. El cache_control de nivel superior es un campo fijo: envía el mismo valor en cada solicitud.

También puedes colocar puntos de interrupción cache_control en bloques tú mismo:

• Los puntos de interrupción que envías en la solicitud de creación siguen funcionando en cada turno posterior si están en tools, en system o en un bloque de mensaje anterior al último. Un punto de interrupción en el último bloque de los messages de una solicitud escribe la caché en esa solicitud. Para almacenar en caché cada turno nuevo, envía un punto de interrupción en cada solicitud. Una solicitud sin un punto de interrupción aún podría leer parte de la conversación desde la caché.
• No puedes mover ni eliminar un punto de interrupción después de enviarlo, porque una solicitud de continuación no puede volver a enviar un mensaje anterior.
• Una solicitud con thread puede llevar como máximo 4 puntos de interrupción cache_control. El cache_control de nivel superior cuenta como uno. Los puntos de interrupción en system y tools de la solicitud de creación vuelven a contar en cada solicitud de continuación. Los puntos de interrupción en mensajes anteriores almacenados no cuentan. Un punto de interrupción de más devuelve un error 400 con el código thread_unsupported_request.
• Si colocas tú mismo puntos de interrupción en bloques de mensajes, elimínalos de los mensajes anteriores cuando reproduzcas la conversación en una nueva solicitud de creación, y conserva uno en el último bloque, para que la solicitud se mantenga dentro del límite de 4.

Streaming

Los hilos funcionan con streaming. El id de la respuesta llega en el evento message_start, pero continúa desde él solo después de recibir el evento message_stop. Una solicitud de continuación enviada antes puede devolver un error 404.

Si el stream de una solicitud de continuación se interrumpe antes de message_stop, vuelve a enviar la misma solicitud de continuación. Si esa solicitud devuelve un error thread_already_continued o thread_continue_in_flight, reenvía la conversación completa en una nueva solicitud de creación.

Es posible que tu conexión se haya interrumpido mientras el servidor todavía generaba la respuesta, o después de que el servidor la guardara. Por eso la API puede rechazar el reintento. Reenviar siempre es seguro.

El helper de hilos del SDK no reintenta la solicitud de continuación después de un stream interrumpido. Consulta Cómo se comporta el helper del SDK.

Recuperarse cuando un hilo no se puede continuar

Una solicitud de continuación devuelve un error 404 con error.details.error_code establecido en thread_not_found cuando la API no puede continuar el hilo. La respuesta no indica el motivo. Las causas incluyen las siguientes:

• El hilo expiró.
• La API sirvió el turno anterior pero no lo almacenó. Por ejemplo, la API no almacena una respuesta que termina en una llamada a herramienta cortada por max_tokens.
• Un modelo de respaldo escribió la respuesta anterior. Consulta Usar respaldos con un hilo.
• La respuesta anterior todavía se está generando.
• La solicitud proviene de una organización o un espacio de trabajo diferente.
• La solicitud proviene de un usuario o una cuenta de servicio diferente de la que creó el hilo. Un hilo creado con una clave de espacio de trabajo (heredada) permanece con esa clave, así que usa la misma clave para todo el hilo.
• Los mensajes nuevos agregan algo que la conversación almacenada no puede aceptar. Por ejemplo, la primera imagen en una conversación que no tenía ninguna puede devolver este error.

Para recuperarte, envía la conversación completa desde tu propia copia en una nueva solicitud de creación, con system y tools. El helper de hilos del SDK envía esta solicitud de creación una vez por sí mismo, y omite los puntos de interrupción cache_control de turnos anteriores al hacerlo. Si los mensajes anteriores de tu copia llevan puntos de interrupción cache_control, elimínalos primero (consulta Almacenamiento en caché de prompts en un hilo). Luego continúa a partir del id de la nueva respuesta. Si un modelo de respaldo escribió la respuesta anterior, consulta Usar respaldos con un hilo. Para descartar las causas relacionadas con la propiedad, usa la misma clave de API y el mismo espacio de trabajo para cada solicitud de un hilo. En Claude Platform on AWS, firma cada solicitud de un hilo con credenciales del rol de IAM o del usuario de IAM que lo creó.

Una solicitud para un modelo que no existe también devuelve un error 404, así que revisa error.details.error_code antes de reenviar.

Si una solicitud de continuación sigue devolviendo un error 404 justo después de reproducir la conversación, es posible que la API no pueda almacenar esa conversación, por ejemplo una muy grande. Envíala sin thread. El helper de hilos del SDK hace esto cuando lo creas con unsupported_request_behavior establecido en continue_unthreaded. De lo contrario, reproduce la conversación en cada turno.

Después de un rechazo

Cuando una respuesta tiene stop_reason: "refusal", no continúes el hilo. Es posible que la API ya contenga el turno rechazado, y una solicitud de continuación no puede eliminarlo. Inicia un nuevo hilo con una solicitud de creación que omita o reformule el turno que provocó el rechazo. Consulta Rechazos y respaldo. El helper de hilos del SDK hace esto por ti: no conserva el turno rechazado, y su siguiente turno inicia un nuevo hilo.

Usar respaldos con un hilo

El respaldo del lado del servidor está disponible con hilos en la Claude API. Decide al crear el hilo: envía fallbacks en todas las solicitudes del hilo, o en ninguna. El valor de fallbacks puede cambiar entre solicitudes. Una solicitud de continuación que agrega o quita fallbacks devuelve un error 400 con el código thread_fingerprint_mismatch.

Un hilo conserva un solo modelo, por lo que la API no almacena un turno escrito por un modelo de respaldo. Recibes la respuesta como de costumbre, pero no puedes continuar desde su id. Después de cada respuesta, sigue estos pasos:

1. Si stop_reason es "refusal", sigue Después de un rechazo.
2. De lo contrario, busca una entrada fallback_message en usage.iterations. En un stream, léela del evento message_delta final. Si no hay ninguna, continúa el hilo como de costumbre.
3. Si hay una, un modelo de respaldo escribió la respuesta. Envía la conversación completa, incluida esa respuesta y tu siguiente mensaje, en una nueva solicitud de creación. Mantén el encabezado beta server-side-fallback-2026-07-01 en ella. Elige una de estas dos solicitudes:
   • La misma solicitud de nuevo. Mantén model, fallbacks y tus demás parámetros como estaban. Si responde el modelo que solicitaste, la API almacena el nuevo hilo. Si responde un modelo de respaldo, la respuesta vuelve a tener una entrada fallback_message y la API no la almacena, así que repite este paso en el siguiente turno. El enrutamiento persistente podría enviar estas solicitudes directamente al modelo de respaldo, por lo que cada turno podría enviar la conversación completa. El helper de hilos del SDK funciona de esta manera.
   • Un nuevo hilo en el modelo de respaldo. Establece model en el model de esa entrada fallback_message, omite fallbacks y usa parámetros que este modelo acepte. La API almacena este hilo de inmediato, y permanece en el modelo de respaldo. Es posible que el intento de respaldo se haya ejecutado con una configuración diferente a la que enviaste, por lo que la API podría rechazar valores copiados de tu primera solicitud.
4. Vuelve al paso 1 con la respuesta a esa solicitud. Cuando no tenga ninguna entrada fallback_message, continúa el nuevo hilo a partir de su id.

El enrutamiento persistente comienza después de que una solicitud recurre al respaldo (una solicitud de creación, o una solicitud sin thread). Durante aproximadamente una hora, podría enviar las solicitudes de creación posteriores de la misma conversación que incluyan fallbacks directamente al modelo de respaldo, sin intentar el modelo que solicitaste. La API no almacena ninguno de esos turnos, y cada uno que recibe respuesta reinicia ese plazo de una hora. Una solicitud de continuación nunca inicia este enrutamiento ni lo usa. El enrutamiento persistente no se aplica si tu organización o espacio de trabajo usa retención de datos cero o claves de cifrado administradas por el cliente.

Compactar una conversación

Un hilo es de solo anexado, así que no puedes reemplazar sus turnos anteriores con un resumen. Para compactar una conversación, inicia un nuevo hilo a partir del resumen. Escribe el resumen en tu código y envíalo como un mensaje normal en una nueva solicitud de creación, con system y tools. La compactación bajo demanda no está disponible con hilos (consulta Funciones que los hilos no admiten).

Cómo se comporta el helper del SDK

Lo que el helper hace por ti:

• Agrega el encabezado beta message-threads-2026-08-12 a cada solicitud que usa el hilo.
• Crea un hilo en el primer turno y lo continúa después de eso, enviando solo los mensajes nuevos y omitiendo system y tools.
• Reproduce la conversación completa una vez en una nueva solicitud de creación cuando una solicitud de continuación devuelve thread_not_found, thread_already_continued o thread_continue_in_flight.
• Reanuda una respuesta pause_turn cuando llamas a send() sin mensajes.
• Inicia un nuevo hilo después de un rechazo. Recibes la respuesta stop_reason: "refusal" como de costumbre, pero el helper no conserva ese turno: retira los mensajes que le diste a esa llamada. Los mensajes que agregaste con thread.append(...), o que proporcionaste al crear el helper, permanecen preparados. Tu siguiente turno los envía junto con la conversación anterior al turno rechazado, en una nueva solicitud de creación. Envía un mensaje reformulado o, si un mensaje preparado provocó el rechazo, inicia un nuevo hilo a partir de los params sin él.
• Envía una nueva solicitud de creación después de una respuesta de un modelo de respaldo. Cuando una respuesta tiene una entrada fallback_message en usage.iterations, el helper conserva la respuesta y envía la conversación completa en una nueva solicitud de creación en el siguiente turno. No espera un error 404. Esa solicitud conserva el model y los fallbacks que configuraste.
• Omite los puntos de interrupción cache_control de turnos anteriores cada vez que los vuelve a enviar, por ejemplo en una reproducción o en el primer turno de una bifurcación. Tus mensajes más recientes, system, tools y el cache_control de nivel superior se envían tal como los proporcionaste.

Lo que manejas tú mismo:

• Respaldos. Mientras la API siga respondiendo desde un modelo de respaldo, el helper envía la conversación completa en una nueva solicitud de creación en cada turno, porque la API no almacena ninguno de esos turnos. Vuelve a las solicitudes de continuación después de una respuesta del modelo que solicitaste. Para mover la conversación al modelo de respaldo en su lugar, inicia un nuevo hilo a partir de los params con ese model y sin fallbacks, como en Usar respaldos con un hilo.
• Streams interrumpidos. Si un stream termina a mitad de una respuesta, el helper conserva los bloques terminados y cualquier texto que haya llegado, y el siguiente turno envía la conversación completa en una nueva solicitud de creación. El helper no reintenta por sí mismo: para volver a enviar el turno interrumpido, llama a send() sin mensajes. Si la parte conservada termina en llamadas a herramientas, respóndelas en tu siguiente mensaje. Si dejas de leer un stream después de que muestra stop_reason: "refusal", el helper trata ese turno como un rechazo.
• Otros errores. Los errores thread_fingerprint_mismatch y thread_unsupported_request llegan a tu código. Para continuar sin thread después de un error thread_unsupported_request, crea el helper con unsupported_request_behavior establecido en continue_unthreaded. Con esa configuración, el helper también deja de usar thread cuando la primera solicitud de continuación después de una reproducción vuelve a devolver thread_not_found. Es posible que la API no pueda almacenar esa conversación. Sin esa configuración, el helper reproduce la conversación en cada turno. Un ejecutor de herramientas que crea su propio hilo usa esa configuración de forma predeterminada.

El ejecutor de herramientas beta del SDK también usa un hilo de forma predeterminada, lo cual puedes desactivar al crear el ejecutor.

Otros métodos del helper

Streaming. El helper registra la respuesta cuando el stream llega a message_stop, así que lee el stream hasta el final. Si dejas de leer antes, finaliza el stream para que el hilo quede libre para el siguiente turno:

• Python: sal del bloque with.
• TypeScript: sal del bucle o llama a abort().
• Go: llama a Close.
• Java y Ruby: llama a close().
• C#: libera el enumerador. Salir de await foreach hace esto.
• PHP: llama a close().

En C#, la solicitud se envía cuando empiezas a leer el stream.

En C#, Go, Java y PHP, después de un rechazo thread.LastMessage sigue devolviendo la respuesta del turno anterior, o nada en un primer turno. Lee el rechazo desde los eventos del stream.

Cambiar campos. Una actualización no envía nada y se aplica a cada turno posterior. Una vez que un hilo tiene una respuesta, el helper rechaza un turno que cambie system o tools, y la API rechaza un cambio en cualquier otro campo fijo (consulta Qué enviar en cada solicitud). Para cambiar uno de estos campos, inicia un nuevo hilo a partir de los params, o bifurca el hilo y actualiza la bifurcación antes de su primer turno.

Bifurcar. Una bifurcación copia la conversación, los campos y las opciones de solicitud, y no envía nada. Su primer turno envía la conversación completa en una nueva solicitud de creación, y los dos hilos son independientes a partir de ahí. Una bifurcación siempre parte de toda la conversación, no de una respuesta anterior.

Params. Los params contienen los campos del helper y la conversación completa. Pásalos al método que crea un helper para iniciar un nuevo hilo, por ejemplo con un system diferente (consulta Qué enviar en cada solicitud), o con messages recortado para descartar turnos posteriores. Un hilo que inicias a partir de los params envía cada mensaje tal como lo proporcionaste, incluidos los puntos de interrupción de cache_control, así que mantente dentro del límite de 4 (consulta Almacenamiento en caché de prompts en un hilo). Excepto en Ruby, los params omiten las opciones de solicitud, así que pásalas de nuevo.

Salida estructurada. Indica el formato de salida al crear el helper. Un turno posterior no puede cambiarlo. La forma de obtener el resultado analizado depende del SDK:

• Python y TypeScript: llama a thread.parse(...).
• C#: crea el helper con client.Beta.Messages.Thread<T>(...).
• Go: Send deserializa en la estructura a la que apunta Params.OutputConfig.Format.Schema.
• Java: crea el helper con thread(...) y outputConfig(MyClass.class).
• PHP: send() establece parsed en los bloques de texto cuando outputConfig nombra una clase de modelo.
• Ruby: pasa output_config: {format: MyModel} a thread(...) y luego lee reply.parsed_output.

Errores

La API devuelve los errores de esta tabla antes de que se ejecute el modelo. La solicitud no usa tokens, y el hilo y su tiempo de expiración no cambian. error.type es invalid_request_error para los errores 400 y not_found_error para el error 404.

Algunos errores 400 de solicitudes de hilo no llevan error_code, por ejemplo una solicitud de continuación sin previous_message_id, o una que incluye system o tools.

El siguiente ejemplo muestra el cuerpo de un error:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "thread: a maximum of 4 blocks with cache_control may be provided when `thread` is set. Found 5.",
    "details": {
      "error_code": "thread_unsupported_request",
      "unsupported": ["cache_control"]
    }
  },
  "request_id": "req_011CSHoEeqs5C35K2UUqR7Fy"
}

Funciones que los hilos no admiten

Los hilos no admiten estas funciones:

• Message Batches. Un elemento de solicitud que incluye thread termina con un invalid_request_error en los resultados del lote.
• Conteo de tokens. Una solicitud de conteo de tokens que incluye thread devuelve un error 400. En su lugar, cuenta la conversación completa, con system y tools.
• Compactación. La compactación bajo demanda no está disponible con hilos. Una solicitud que incluye thread devuelve un error 400 si establece el parámetro compaction, o si envía un bloque compaction con el encabezado beta compact-2026-09-04. Consulta Compactar una conversación.
• Edición de contexto, excepto clear_thinking_20251015 con keep: "all".
• Organizaciones que tienen habilitada la preparación para HIPAA.
• Organizaciones que tienen activados los Inference hooks.

La API rechaza la mayoría de las solicitudes que los hilos no admiten con un error 400 y el código thread_unsupported_request. Cuando error.details.unsupported está presente, contiene uno de estos valores:

La API puede agregar valores a esta lista. Si recibes un valor que no reconoces, envía la conversación completa sin thread. Una solicitud que cumple varias de estas condiciones recibe un error que nombra solo una.

Limitaciones

• No hay ninguna API para listar, leer o eliminar un hilo.
• Los hilos están disponibles en la Claude API, Claude Platform on AWS, Claude Models on Google Cloud (Anthropic managed), y Claude in Microsoft Foundry.

Precios y límites de velocidad

Los hilos no cambian los precios ni los límites de velocidad.

Retención de datos

Los hilos de mensajes no son elegibles para ZDR. Usar esta función no afecta tu uso de otras funciones elegibles para ZDR. La API mantiene un hilo en memoria, cifrado con una clave administrada por el servidor, nunca lo escribe en almacenamiento duradero y lo elimina como máximo 1 hora después de su último uso.

Un hilo contiene la conversación que la API envía al modelo, el system y las tools de la solicitud de creación, y una huella de los campos fijos, que usa para verificar las solicitudes posteriores. Contiene los archivos por referencia, así que mantén disponibles todos los archivos que usa la conversación mientras uses el hilo.

Para conocer la elegibilidad para ZDR de todas las funciones, consulta API y retención de datos.

Consulta también

• Almacenamiento en caché de prompts
• Streaming
• Errores

Disponibilidad

Estado de Hilos de mensajes: en beta en todos los modelos.

Compatibilidad con la API

Los encabezados beta te permiten acceder a funciones experimentales y nuevas capacidades de los modelos antes de que formen parte de la API estándar.