Almacenamiento en caché de prompts

El almacenamiento en caché de prompts optimiza el uso de tu API al permitir reanudar desde prefijos específicos en tus prompts. Esto reduce significativamente el tiempo de procesamiento y los costos para tareas repetitivas o prompts con elementos consistentes.

Hay dos formas de habilitar el almacenamiento en caché de prompts:

• Almacenamiento en caché automático: Agrega un único campo cache_control en el nivel superior de tu solicitud. El sistema aplica automáticamente el punto de interrupción de caché al último bloque almacenable en caché y lo mueve hacia adelante a medida que las conversaciones crecen. Ideal para conversaciones de múltiples turnos donde el historial de mensajes creciente debe almacenarse en caché automáticamente.
• Puntos de interrupción de caché explícitos: Coloca cache_control directamente en bloques de contenido individuales para un control detallado sobre exactamente qué se almacena en caché.

La forma más sencilla de comenzar es con el almacenamiento en caché automático:

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-4-6",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.",
    "messages": [
      {
        "role": "user",
        "content": "Analyze the major themes in Pride and Prejudice."
      }
    ]
  }'

Con el almacenamiento en caché automático, el sistema almacena en caché todo el contenido hasta e incluyendo el último bloque almacenable en caché. En solicitudes posteriores con el mismo prefijo, el contenido en caché se reutiliza automáticamente.

Cómo funciona el almacenamiento en caché de prompts

Cuando envías una solicitud con el almacenamiento en caché de prompts habilitado:

1. El sistema verifica si un prefijo de prompt, hasta un punto de interrupción de caché especificado, ya está almacenado en caché desde una consulta reciente.
2. Si se encuentra, utiliza la versión en caché, reduciendo el tiempo de procesamiento y los costos.
3. De lo contrario, procesa el prompt completo y almacena en caché el prefijo una vez que comienza la respuesta.

Esto es especialmente útil para:

• Prompts con muchos ejemplos
• Grandes cantidades de contexto o información de fondo
• Tareas repetitivas con instrucciones consistentes
• Conversaciones largas de múltiples turnos

Por defecto, el caché tiene una vida útil de 5 minutos. El caché se actualiza sin costo adicional cada vez que se utiliza el contenido en caché.

Precios

El almacenamiento en caché de prompts introduce una nueva estructura de precios. La tabla a continuación muestra el precio por millón de tokens para cada modelo compatible:

Modelos compatibles

El almacenamiento en caché de prompts (tanto automático como explícito) está actualmente disponible en:

• Claude Opus 4.6
• Claude Opus 4.5
• Claude Opus 4.1
• Claude Opus 4
• Claude Sonnet 4.6
• Claude Sonnet 4.5
• Claude Sonnet 4
• Claude Sonnet 3.7 (obsoleto)
• Claude Haiku 4.5
• Claude Haiku 3.5 (obsoleto)
• Claude Haiku 3

Almacenamiento en caché automático

El almacenamiento en caché automático es la forma más sencilla de habilitar el almacenamiento en caché de prompts. En lugar de colocar cache_control en bloques de contenido individuales, agrega un único campo cache_control en el nivel superior del cuerpo de tu solicitud. El sistema aplica automáticamente el punto de interrupción de caché al último bloque almacenable en caché.

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-4-6",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are a helpful assistant that remembers our conversation.",
    "messages": [
      {"role": "user", "content": "My name is Alex. I work on machine learning."},
      {"role": "assistant", "content": "Nice to meet you, Alex! How can I help with your ML work today?"},
      {"role": "user", "content": "What did I say I work on?"}
    ]
  }'

Cómo funciona el almacenamiento en caché automático en conversaciones de múltiples turnos

Con el almacenamiento en caché automático, el punto de caché avanza automáticamente a medida que crecen las conversaciones. Cada nueva solicitud almacena en caché todo hasta el último bloque almacenable en caché, y el contenido anterior se lee desde el caché.

El punto de interrupción de caché se mueve automáticamente al último bloque almacenable en caché en cada solicitud, por lo que no necesitas actualizar ningún marcador cache_control a medida que crece la conversación.

Soporte de TTL

Por defecto, el almacenamiento en caché automático utiliza un TTL de 5 minutos. Puedes especificar un TTL de 1 hora al doble del precio base del token de entrada:

"cache_control": {"type": "ephemeral", "ttl": "1h"}

Combinación con almacenamiento en caché a nivel de bloque

El almacenamiento en caché automático es compatible con los puntos de interrupción de caché explícitos. Cuando se usan juntos, el punto de interrupción de caché automático utiliza uno de los 4 espacios de puntos de interrupción disponibles.

Esto te permite combinar ambos enfoques. Por ejemplo, usa puntos de interrupción explícitos para almacenar en caché tu prompt del sistema y las herramientas de forma independiente, mientras que el almacenamiento en caché automático maneja la conversación:

{
  "model": "claude-opus-4-6",
  "max_tokens": 1024,
  "cache_control": {"type": "ephemeral"},
  "system": [
    {
      "type": "text",
      "text": "You are a helpful assistant.",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [...]
}

Lo que permanece igual

El almacenamiento en caché automático utiliza la misma infraestructura de almacenamiento en caché subyacente. Los precios, los umbrales mínimos de tokens, los requisitos de ordenación de contexto y la ventana de retrospección de 20 bloques se aplican de la misma manera que con los puntos de interrupción explícitos.

Casos extremos

• Si el último bloque ya tiene un cache_control explícito con el mismo TTL, el almacenamiento en caché automático no tiene efecto.
• Si el último bloque tiene un cache_control explícito con un TTL diferente, la API devuelve un error 400.
• Si ya existen 4 puntos de interrupción explícitos a nivel de bloque, la API devuelve un error 400 (no quedan espacios para el almacenamiento en caché automático).
• Si el último bloque no es elegible como objetivo de punto de interrupción de caché automático, el sistema retrocede silenciosamente para encontrar el bloque elegible más cercano. Si no se encuentra ninguno, se omite el almacenamiento en caché.

Puntos de interrupción de caché explícitos

Para un mayor control sobre el almacenamiento en caché, puedes colocar cache_control directamente en bloques de contenido individuales. Esto es útil cuando necesitas almacenar en caché diferentes secciones que cambian con diferentes frecuencias, o necesitas un control detallado sobre exactamente qué se almacena en caché.

Estructuración de tu prompt

Coloca el contenido estático (definiciones de herramientas, instrucciones del sistema, contexto, ejemplos) al comienzo de tu prompt. Marca el final del contenido reutilizable para el almacenamiento en caché usando el parámetro cache_control.

Los prefijos de caché se crean en el siguiente orden: tools, system, luego messages. Este orden forma una jerarquía donde cada nivel se construye sobre los anteriores.

Cómo funciona la verificación automática de prefijos

Puedes usar solo un punto de interrupción de caché al final de tu contenido estático, y el sistema encontrará automáticamente la secuencia coincidente más larga de bloques en caché. Comprender cómo funciona esto te ayuda a optimizar tu estrategia de almacenamiento en caché.

Tres principios fundamentales:

1. Las claves de caché son acumulativas: Cuando almacenas explícitamente en caché un bloque con cache_control, la clave hash de caché se genera hasheando todos los bloques anteriores en la conversación secuencialmente. Esto significa que el caché para cada bloque depende de todo el contenido que vino antes.

2. Verificación secuencial hacia atrás: El sistema verifica los aciertos de caché trabajando hacia atrás desde tu punto de interrupción explícito, verificando cada bloque anterior en orden inverso. Esto asegura que obtengas el acierto de caché más largo posible.

3. Ventana de retrospección de 20 bloques: El sistema solo verifica hasta 20 bloques antes de cada punto de interrupción cache_control explícito. Después de verificar 20 bloques sin coincidencia, deja de verificar y pasa al siguiente punto de interrupción explícito (si existe).

Ejemplo: Comprensión de la ventana de retrospección

Considera una conversación con 30 bloques de contenido donde estableces cache_control solo en el bloque 30:

• Si envías el bloque 31 sin cambios en los bloques anteriores: El sistema verifica el bloque 30 (¡coincidencia!). Obtienes un acierto de caché en el bloque 30, y solo el bloque 31 necesita procesamiento.

• Si modificas el bloque 25 y envías el bloque 31: El sistema verifica hacia atrás desde el bloque 30 → 29 → 28... → 25 (sin coincidencia) → 24 (¡coincidencia!). Como el bloque 24 no ha cambiado, obtienes un acierto de caché en el bloque 24, y solo los bloques 25-30 necesitan reprocesamiento.

• Si modificas el bloque 5 y envías el bloque 31: El sistema verifica hacia atrás desde el bloque 30 → 29 → 28... → 11 (verificación #20). Después de 20 verificaciones sin encontrar coincidencia, deja de buscar. Como el bloque 5 está más allá de la ventana de 20 bloques, no se produce ningún acierto de caché y todos los bloques necesitan reprocesamiento. Sin embargo, si hubieras establecido un punto de interrupción cache_control explícito en el bloque 5, el sistema continuaría verificando desde ese punto de interrupción: bloque 5 (sin coincidencia) → bloque 4 (¡coincidencia!). Esto permite un acierto de caché en el bloque 4, demostrando por qué debes colocar puntos de interrupción antes del contenido editable.

Conclusión clave: Siempre establece un punto de interrupción de caché explícito al final de tu conversación para maximizar tus posibilidades de aciertos de caché. Además, establece puntos de interrupción justo antes de los bloques de contenido que podrían ser editables para asegurarte de que esas secciones puedan almacenarse en caché de forma independiente.

Cuándo usar múltiples puntos de interrupción

Puedes definir hasta 4 puntos de interrupción de caché si deseas:

• Almacenar en caché diferentes secciones que cambian con diferentes frecuencias (por ejemplo, las herramientas rara vez cambian, pero el contexto se actualiza diariamente)
• Tener más control sobre exactamente qué se almacena en caché
• Garantizar el almacenamiento en caché para contenido que está a más de 20 bloques antes de tu punto de interrupción final
• Colocar puntos de interrupción antes del contenido editable para garantizar aciertos de caché incluso cuando se producen cambios más allá de la ventana de 20 bloques

Comprensión de los costos de los puntos de interrupción de caché

Los puntos de interrupción de caché en sí mismos no agregan ningún costo. Solo se te cobra por:

• Escrituras en caché: Cuando se escribe nuevo contenido en el caché (25% más que los tokens de entrada base para TTL de 5 minutos)
• Lecturas de caché: Cuando se utiliza el contenido en caché (10% del precio base del token de entrada)
• Tokens de entrada regulares: Para cualquier contenido no almacenado en caché

Agregar más puntos de interrupción cache_control no aumenta tus costos: sigues pagando la misma cantidad según el contenido que realmente se almacena en caché y se lee. Los puntos de interrupción simplemente te dan control sobre qué secciones pueden almacenarse en caché de forma independiente.

Estrategias y consideraciones de almacenamiento en caché

Limitaciones del caché

La longitud mínima del prompt almacenable en caché es:

• 4096 tokens para Claude Opus 4.6, Claude Opus 4.5
• 2048 tokens para Claude Sonnet 4.6
• 1024 tokens para Claude Sonnet 4.5, Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4 y Claude Sonnet 3.7 (obsoleto)
• 4096 tokens para Claude Haiku 4.5
• 2048 tokens para Claude Haiku 3.5 (obsoleto) y Claude Haiku 3

Los prompts más cortos no pueden almacenarse en caché, incluso si están marcados con cache_control. Cualquier solicitud para almacenar en caché menos de este número de tokens se procesará sin almacenamiento en caché. Para ver si un prompt fue almacenado en caché, consulta los campos de uso de la respuesta.

Para solicitudes concurrentes, ten en cuenta que una entrada de caché solo está disponible después de que comienza la primera respuesta. Si necesitas aciertos de caché para solicitudes paralelas, espera la primera respuesta antes de enviar solicitudes posteriores.

Actualmente, "ephemeral" es el único tipo de caché compatible, que por defecto tiene una vida útil de 5 minutos.

Qué puede almacenarse en caché

La mayoría de los bloques en la solicitud pueden almacenarse en caché. Esto incluye:

• Herramientas: Definiciones de herramientas en el array tools
• Mensajes del sistema: Bloques de contenido en el array system
• Mensajes de texto: Bloques de contenido en el array messages.content, tanto para turnos de usuario como de asistente
• Imágenes y documentos: Bloques de contenido en el array messages.content, en turnos de usuario
• Uso de herramientas y resultados de herramientas: Bloques de contenido en el array messages.content, tanto en turnos de usuario como de asistente

Cada uno de estos elementos puede almacenarse en caché, ya sea automáticamente o marcándolos con cache_control.

Qué no puede almacenarse en caché

Si bien la mayoría de los bloques de solicitud pueden almacenarse en caché, hay algunas excepciones:

• Los bloques de pensamiento no pueden almacenarse en caché directamente con cache_control. Sin embargo, los bloques de pensamiento SÍ pueden almacenarse en caché junto con otro contenido cuando aparecen en turnos anteriores del asistente. Cuando se almacenan en caché de esta manera, SÍ cuentan como tokens de entrada cuando se leen desde el caché.

• Los sub-bloques de contenido (como las citas) no pueden almacenarse en caché directamente. En su lugar, almacena en caché el bloque de nivel superior.

  En el caso de las citas, los bloques de contenido de documentos de nivel superior que sirven como material fuente para las citas pueden almacenarse en caché. Esto te permite usar el almacenamiento en caché de prompts con citas de manera efectiva almacenando en caché los documentos a los que harán referencia las citas.

• Los bloques de texto vacíos no pueden almacenarse en caché.

Qué invalida el caché

Las modificaciones al contenido en caché pueden invalidar parte o todo el caché.

Como se describe en Estructuración de tu prompt, el caché sigue la jerarquía: tools → system → messages. Los cambios en cada nivel invalidan ese nivel y todos los niveles posteriores.

La siguiente tabla muestra qué partes del caché son invalidadas por diferentes tipos de cambios. ✘ indica que el caché es invalidado, mientras que ✓ indica que el caché permanece válido.

Seguimiento del rendimiento del caché

Monitorea el rendimiento del caché usando estos campos de respuesta de la API, dentro de usage en la respuesta (o el evento message_start si se usa streaming):

• cache_creation_input_tokens: Número de tokens escritos en el caché al crear una nueva entrada.
• cache_read_input_tokens: Número de tokens recuperados del caché para esta solicitud.
• input_tokens: Número de tokens de entrada que no fueron leídos ni utilizados para crear un caché (es decir, tokens después del último punto de interrupción de caché).

total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

Almacenamiento en caché con bloques de pensamiento

Cuando se usa el pensamiento extendido con el almacenamiento en caché de prompts, los bloques de pensamiento tienen un comportamiento especial:

Almacenamiento en caché automático junto con otro contenido: Si bien los bloques de pensamiento no pueden marcarse explícitamente con cache_control, se almacenan en caché como parte del contenido de la solicitud cuando realizas llamadas API posteriores con resultados de herramientas. Esto ocurre comúnmente durante el uso de herramientas cuando pasas bloques de pensamiento de vuelta para continuar la conversación.

Conteo de tokens de entrada: Cuando los bloques de pensamiento se leen desde el caché, cuentan como tokens de entrada en tus métricas de uso. Esto es importante para el cálculo de costos y el presupuesto de tokens.

Patrones de invalidación de caché:

• El caché permanece válido cuando solo se proporcionan resultados de herramientas como mensajes de usuario
• El caché se invalida cuando se agrega contenido de usuario que no es resultado de herramienta, lo que hace que todos los bloques de pensamiento anteriores sean eliminados
• Este comportamiento de almacenamiento en caché ocurre incluso sin marcadores cache_control explícitos

Para más detalles sobre la invalidación del caché, consulta Qué invalida el caché.

Ejemplo con uso de herramientas:

Request 1: User: "What's the weather in Paris?"
Response: [thinking_block_1] + [tool_use block 1]

Request 2:
User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True]
Response: [thinking_block_2] + [text block 2]
# Request 2 caches its request content (not the response)
# The cache includes: user message, thinking_block_1, tool_use block 1, and tool_result_1

Request 3:
User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [thinking_block_2] + [text block 2],
User: [Text response, cache=True]
# Non-tool-result user block causes all thinking blocks to be ignored
# This request is processed as if thinking blocks were never present

Cuando se incluye un bloque de usuario que no es resultado de herramienta, designa un nuevo bucle de asistente y todos los bloques de pensamiento anteriores se eliminan del contexto.

Para información más detallada, consulta la documentación de pensamiento extendido.

Almacenamiento y compartición del caché

• Aislamiento de organización: Los cachés están aislados entre organizaciones. Las diferentes organizaciones nunca comparten cachés, incluso si usan prompts idénticos.

• Coincidencia exacta: Los aciertos de caché requieren segmentos de prompt 100% idénticos, incluyendo todo el texto e imágenes hasta e incluyendo el bloque marcado con control de caché.

• Generación de tokens de salida: El almacenamiento en caché de prompts no tiene efecto en la generación de tokens de salida. La respuesta que recibes será idéntica a lo que obtendrías si no se usara el almacenamiento en caché de prompts.

Mejores prácticas para un almacenamiento en caché efectivo

Para optimizar el rendimiento del almacenamiento en caché de prompts:

• Comienza con el almacenamiento en caché automático para conversaciones de múltiples turnos. Maneja la gestión de puntos de interrupción automáticamente.
• Usa puntos de interrupción explícitos a nivel de bloque cuando necesites almacenar en caché diferentes secciones con diferentes frecuencias de cambio.
• Almacena en caché contenido estable y reutilizable como instrucciones del sistema, información de fondo, contextos grandes o definiciones de herramientas frecuentes.
• Coloca el contenido en caché al comienzo del prompt para obtener el mejor rendimiento.
• Usa puntos de interrupción de caché estratégicamente para separar diferentes secciones de prefijo almacenables en caché.
• Establece puntos de interrupción de caché al final de las conversaciones y justo antes del contenido editable para maximizar las tasas de aciertos de caché, especialmente cuando trabajas con prompts que tienen más de 20 bloques de contenido.
• Analiza regularmente las tasas de aciertos de caché y ajusta tu estrategia según sea necesario.

Optimización para diferentes casos de uso

Adapta tu estrategia de almacenamiento en caché de prompts a tu escenario:

• Agentes conversacionales: Reduce el costo y la latencia para conversaciones extendidas, especialmente aquellas con instrucciones largas o documentos cargados.
• Asistentes de codificación: Mejora el autocompletado y las preguntas y respuestas sobre la base de código manteniendo secciones relevantes o una versión resumida de la base de código en el prompt.
• Procesamiento de documentos grandes: Incorpora material completo de formato largo incluyendo imágenes en tu prompt sin aumentar la latencia de respuesta.
• Conjuntos de instrucciones detalladas: Comparte listas extensas de instrucciones, procedimientos y ejemplos para ajustar las respuestas de Claude. Los desarrolladores a menudo incluyen uno o dos ejemplos en el prompt, pero con el almacenamiento en caché de prompts puedes obtener un rendimiento aún mejor incluyendo más de 20 ejemplos diversos de respuestas de alta calidad.
• Uso de herramientas agéntico: Mejora el rendimiento para escenarios que involucran múltiples llamadas a herramientas y cambios de código iterativos, donde cada paso típicamente requiere una nueva llamada a la API.
• Habla con libros, artículos, documentación, transcripciones de podcasts y otro contenido de formato largo: Da vida a cualquier base de conocimiento incrustando el documento completo en el prompt y dejando que los usuarios hagan preguntas.

Solución de problemas comunes

Si experimentas comportamiento inesperado:

• Asegúrate de que las secciones en caché sean idénticas entre llamadas. Para puntos de interrupción explícitos, verifica que los marcadores cache_control estén en las mismas ubicaciones
• Verifica que las llamadas se realicen dentro de la vida útil del caché (5 minutos por defecto)
• Verifica que el uso de tool_choice e imágenes permanezca consistente entre llamadas
• Valida que estés almacenando en caché al menos el número mínimo de tokens
• El sistema verifica automáticamente los aciertos de caché en los límites de bloques de contenido anteriores (hasta ~20 bloques antes de tu punto de interrupción). Para prompts con más de 20 bloques de contenido, es posible que necesites parámetros cache_control adicionales anteriores en el prompt para asegurarte de que todo el contenido pueda almacenarse en caché
• Verifica que las claves en tus bloques de contenido tool_use tengan un orden estable, ya que algunos lenguajes (por ejemplo, Swift, Go) aleatorian el orden de las claves durante la conversión JSON, rompiendo los cachés

Duración de caché de 1 hora

Si encuentras que 5 minutos es demasiado corto, Anthropic también ofrece una duración de caché de 1 hora a un costo adicional.

Para usar el caché extendido, incluye ttl en la definición de cache_control de esta manera:

"cache_control": {
  "type": "ephemeral",
  "ttl": "1h"
}

La respuesta incluirá información detallada del caché como la siguiente:

{
  "usage": {
    "input_tokens": 2048,
    "cache_read_input_tokens": 1800,
    "cache_creation_input_tokens": 248,
    "output_tokens": 503,

    "cache_creation": {
      "ephemeral_5m_input_tokens": 456,
      "ephemeral_1h_input_tokens": 100
    }
  }
}

Ten en cuenta que el campo actual cache_creation_input_tokens es igual a la suma de los valores en el objeto cache_creation.

Cuándo usar el caché de 1 hora

Si tienes prompts que se usan con una cadencia regular (es decir, prompts del sistema que se usan con más frecuencia que cada 5 minutos), continúa usando el caché de 5 minutos, ya que este seguirá actualizándose sin cargo adicional.

El caché de 1 hora se usa mejor en los siguientes escenarios:

• Cuando tienes prompts que probablemente se usan con menos frecuencia que 5 minutos, pero con más frecuencia que cada hora. Por ejemplo, cuando un sub-agente agéntico tardará más de 5 minutos, o cuando se almacena una larga conversación de chat con un usuario y generalmente esperas que ese usuario no responda en los próximos 5 minutos.
• Cuando la latencia es importante y tus prompts de seguimiento pueden enviarse más allá de los 5 minutos.
• Cuando deseas mejorar la utilización de tu límite de velocidad, ya que los aciertos de caché no se deducen de tu límite de velocidad.

Mezcla de diferentes TTLs

Puedes usar controles de caché de 1 hora y 5 minutos en la misma solicitud, pero con una restricción importante: Las entradas de caché con TTL más largo deben aparecer antes que los TTL más cortos (es decir, una entrada de caché de 1 hora debe aparecer antes que cualquier entrada de caché de 5 minutos).

Al mezclar TTLs, determinamos tres ubicaciones de facturación en tu prompt:

1. Posición A: El recuento de tokens en el acierto de caché más alto (o 0 si no hay aciertos).
2. Posición B: El recuento de tokens en el bloque cache_control de 1 hora más alto después de A (o igual a A si no existe ninguno).
3. Posición C: El recuento de tokens en el último bloque cache_control.

Se te cobrará por:

1. Tokens de lectura de caché para A.
2. Tokens de escritura en caché de 1 hora para (B - A).
3. Tokens de escritura en caché de 5 minutos para (C - B).

Aquí hay 3 ejemplos. Esto muestra los tokens de entrada de 3 solicitudes, cada una de las cuales tiene diferentes aciertos y fallos de caché. Cada una tiene un precio calculado diferente, mostrado en los cuadros de colores, como resultado.

Ejemplos de caché de prompts

Para ayudarte a comenzar con el caché de prompts, hemos preparado un libro de recetas de caché de prompts con ejemplos detallados y mejores prácticas.

A continuación, hemos incluido varios fragmentos de código que muestran varios patrones de caché de prompts. Estos ejemplos demuestran cómo implementar el caché en diferentes escenarios, ayudándote a comprender las aplicaciones prácticas de esta función:

Retención de datos

El almacenamiento en caché de prompts guarda representaciones KV (clave-valor) y hashes criptográficos del contenido almacenado en caché, pero no almacena el texto sin formato de los prompts ni las respuestas. Las entradas en caché tienen una vida útil mínima de 5 minutos (estándar) o 60 minutos (extendida). Las entradas de caché están aisladas entre organizaciones. Dado que Anthropic no almacena el texto sin formato de prompts ni respuestas, esta función puede ser adecuada para clientes que requieren compromisos de retención de datos de tipo ZDR.

Para conocer la elegibilidad ZDR en todas las funciones, consulte API y Retención de Datos.

Preguntas frecuentes