El almacenamiento en caché de prompts es una característica poderosa que optimiza el uso de tu API permitiendo reanudar desde prefijos específicos en tus prompts. Este enfoque reduce significativamente el tiempo de procesamiento y los costos para tareas repetitivas o prompts con elementos consistentes. Aquí hay un ejemplo de cómo implementar el almacenamiento en caché de prompts con la API de Messages usando un bloque cache_control:
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-sonnet-4-5",
    "max_tokens": 1024,
    "system": [
      {
        "type": "text",
        "text": "You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.\n"
      },
      {
        "type": "text",
        "text": "<the entire contents of Pride and Prejudice>",
        "cache_control": {"type": "ephemeral"}
      }
    ],
    "messages": [
      {
        "role": "user",
        "content": "Analyze the major themes in Pride and Prejudice."
      }
    ]
  }'

# Call the model again with the same inputs up to the cache checkpoint
curl https://api.anthropic.com/v1/messages # rest of input
JSON
{"cache_creation_input_tokens":188086,"cache_read_input_tokens":0,"input_tokens":21,"output_tokens":393}
{"cache_creation_input_tokens":0,"cache_read_input_tokens":188086,"input_tokens":21,"output_tokens":393}
En este ejemplo, el texto completo de “Pride and Prejudice” se almacena en caché usando el parámetro cache_control. Esto permite reutilizar este texto grande en múltiples llamadas a la API sin reprocesarlo cada vez. Cambiar solo el mensaje del usuario te permite hacer varias preguntas sobre el libro mientras utilizas el contenido almacenado en caché, lo que resulta en respuestas más rápidas y una eficiencia mejorada.

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 ruptura de caché especificado, ya está almacenado en caché de una consulta reciente.
  2. Si se encuentra, utiliza la versión almacenada 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 antecedentes
  • 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 almacenado en caché.
Si encuentras que 5 minutos es demasiado corto, Anthropic también ofrece una duración de caché de 1 hora con costo adicional. El caché de 1 hora está actualmente en beta.Para más información, consulta duración de caché de 1 hora.
El almacenamiento en caché de prompts almacena en caché el prefijo completoEl almacenamiento en caché de prompts hace referencia al prompt completo - tools, system y messages (en ese orden) hasta e incluyendo el bloque designado con cache_control.

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:
ModelBase Input Tokens5m Cache Writes1h Cache WritesCache Hits & RefreshesOutput Tokens
Claude Opus 4.1$15 / MTok$18.75 / MTok$30 / MTok$1.50 / MTok$75 / MTok
Claude Opus 4$15 / MTok$18.75 / MTok$30 / MTok$1.50 / MTok$75 / MTok
Claude Sonnet 4.5$3 / MTok$3.75 / MTok$6 / MTok$0.30 / MTok$15 / MTok
Claude Sonnet 4$3 / MTok$3.75 / MTok$6 / MTok$0.30 / MTok$15 / MTok
Claude Sonnet 3.7 (deprecated)$3 / MTok$3.75 / MTok$6 / MTok$0.30 / MTok$15 / MTok
Claude Haiku 4.5$1 / MTok$1.25 / MTok$2 / MTok$0.10 / MTok$5 / MTok
Claude Haiku 3.5$0.80 / MTok$1 / MTok$1.6 / MTok$0.08 / MTok$4 / MTok
Claude Opus 3 (deprecated)$15 / MTok$18.75 / MTok$30 / MTok$1.50 / MTok$75 / MTok
Claude Haiku 3$0.25 / MTok$0.30 / MTok$0.50 / MTok$0.03 / MTok$1.25 / MTok
La tabla anterior refleja los siguientes multiplicadores de precios para el almacenamiento en caché de prompts:
  • Los tokens de escritura de caché de 5 minutos son 1,25 veces el precio de tokens de entrada base
  • Los tokens de escritura de caché de 1 hora son 2 veces el precio de tokens de entrada base
  • Los tokens de lectura de caché son 0,1 veces el precio de tokens de entrada base

Cómo implementar el almacenamiento en caché de prompts

Modelos compatibles

El almacenamiento en caché de prompts está actualmente soportado en:
  • Claude Opus 4.1
  • Claude Opus 4
  • Claude Sonnet 4.5
  • Claude Sonnet 4
  • Claude Sonnet 3.7
  • Claude Haiku 4.5
  • Claude Haiku 3.5
  • Claude Haiku 3
  • Claude Opus 3 (deprecado)

Estructurando tu prompt

Coloca contenido estático (definiciones de herramientas, instrucciones del sistema, contexto, ejemplos) al principio de tu prompt. Marca el final del contenido reutilizable para 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 ruptura de caché al final de tu contenido estático, y el sistema encontrará automáticamente el prefijo coincidente más largo. Así es cómo funciona:
  • Cuando añades un punto de ruptura cache_control, el sistema verifica automáticamente si hay coincidencias de caché en todos los límites de bloques de contenido anteriores (hasta aproximadamente 20 bloques antes de tu punto de ruptura explícito)
  • Si alguna de estas posiciones anteriores coincide con contenido almacenado en caché de solicitudes anteriores, el sistema utiliza el prefijo coincidente más largo
  • Esto significa que no necesitas múltiples puntos de ruptura solo para habilitar el almacenamiento en caché - uno al final es suficiente

Cuándo usar múltiples puntos de ruptura

Puedes definir hasta 4 puntos de ruptura de caché si deseas:
  • Almacenar en caché diferentes secciones que cambian a 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é
  • Asegurar el almacenamiento en caché para contenido más de 20 bloques antes de tu punto de ruptura final
Limitación importante: La verificación automática de prefijos solo mira hacia atrás aproximadamente 20 bloques de contenido desde cada punto de ruptura explícito. Si tu prompt tiene más de 20 bloques de contenido antes de tu punto de ruptura de caché, el contenido anterior a eso no se verificará para coincidencias de caché a menos que añadas puntos de ruptura adicionales.

Limitaciones de caché

La longitud mínima de prompt almacenable en caché es:
  • 1024 tokens para Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4.5, Claude Sonnet 4, Claude Sonnet 3.7 (deprecado) y Claude Opus 3 (deprecado)
  • 4096 tokens para Claude Haiku 4.5
  • 2048 tokens para Claude Haiku 3.5 y Claude Haiku 3
Los prompts más cortos no se pueden almacenar en caché, incluso si se marcan 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 respuesta. Para solicitudes concurrentes, ten en cuenta que una entrada de caché solo se vuelve disponible después de que comienza la primera respuesta. Si necesitas coincidencias de caché para solicitudes paralelas, espera la primera respuesta antes de enviar solicitudes posteriores. Actualmente, “ephemeral” es el único tipo de caché soportado, que por defecto tiene una vida útil de 5 minutos.

Entendiendo los costos de los puntos de ruptura de caché

Los puntos de ruptura de caché en sí no añaden ningún costo. Solo se te cobra por:
  • Escrituras de caché: Cuando se escribe contenido nuevo en el caché (25% más que tokens de entrada base para TTL de 5 minutos)
  • Lecturas de caché: Cuando se utiliza contenido almacenado en caché (10% del precio de token de entrada base)
  • Tokens de entrada regulares: Para cualquier contenido no almacenado en caché
Añadir más puntos de ruptura cache_control no aumenta tus costos - aún pagas la misma cantidad basada en qué contenido se almacena en caché y se lee realmente. Los puntos de ruptura simplemente te dan control sobre qué secciones se pueden almacenar en caché independientemente.

Qué se puede almacenar en caché

La mayoría de bloques en la solicitud se pueden designar para almacenamiento en caché con cache_control. 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 se puede marcar con cache_control para habilitar el almacenamiento en caché para esa porción de la solicitud.

Qué no se puede almacenar en caché

Aunque la mayoría de bloques de solicitud se pueden almacenar en caché, hay algunas excepciones:
  • Los bloques de pensamiento no se pueden almacenar en caché directamente con cache_control. Sin embargo, los bloques de pensamiento PUEDEN almacenarse en caché junto con otro contenido cuando aparecen en turnos de asistente anteriores. Cuando se almacenan en caché de esta manera, SÍ cuentan como tokens de entrada cuando se leen del caché.
  • Los bloques de subcontenido (como citas) en sí no se pueden almacenar en caché directamente. En su lugar, almacena en caché el bloque de nivel superior. En el caso de citas, los bloques de contenido de documento de nivel superior que sirven como material fuente para citas se pueden almacenar en caché. Esto te permite usar el almacenamiento en caché de prompts con citas de manera efectiva almacenando en caché los documentos que las citas referenciarán.
  • Los bloques de texto vacíos no se pueden almacenar en caché.

Qué invalida el caché

Las modificaciones al contenido almacenado en caché pueden invalidar parte o todo el caché. Como se describe en Estructurando tu prompt, el caché sigue la jerarquía: toolssystemmessages. Los cambios en cada nivel invalidan ese nivel y todos los niveles posteriores. La siguiente tabla muestra qué partes del caché se invalidan por diferentes tipos de cambios. ✘ indica que el caché se invalida, mientras que ✓ indica que el caché permanece válido.
Qué cambiaCaché de herramientasCaché del sistemaCaché de mensajesImpacto
Definiciones de herramientasModificar definiciones de herramientas (nombres, descripciones, parámetros) invalida todo el caché
Alternar búsqueda webHabilitar/deshabilitar búsqueda web modifica el prompt del sistema
Alternar citasHabilitar/deshabilitar citas modifica el prompt del sistema
Opción de herramientaLos cambios al parámetro tool_choice solo afectan bloques de mensajes
ImágenesAñadir/eliminar imágenes en cualquier lugar del prompt afecta bloques de mensajes
Parámetros de pensamientoLos cambios en la configuración de pensamiento extendido (habilitar/deshabilitar, presupuesto) afectan bloques de mensajes
Resultados no relacionados con herramientas pasados a solicitudes de pensamiento extendidoCuando se pasan resultados no relacionados con herramientas en solicitudes mientras el pensamiento extendido está habilitado, todos los bloques de pensamiento previamente almacenados en caché se eliminan del contexto, y cualquier mensaje en contexto que siga a esos bloques de pensamiento se elimina del caché. Para más detalles, consulta Almacenamiento en caché con bloques de pensamiento.

Rastreando el rendimiento del caché

Monitorea el rendimiento del caché usando estos campos de respuesta de la API, dentro de usage en la respuesta (o evento message_start si transmitiendo):
  • 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 del caché ni utilizados para crear un caché.

Mejores prácticas para almacenamiento en caché efectivo

Para optimizar el rendimiento del almacenamiento en caché de prompts:
  • Almacena en caché contenido estable y reutilizable como instrucciones del sistema, información de antecedentes, contextos grandes o definiciones de herramientas frecuentes.
  • Coloca contenido almacenado en caché al principio del prompt para mejor rendimiento.
  • Usa puntos de ruptura de caché estratégicamente para separar diferentes secciones de prefijo almacenable en caché.
  • Analiza regularmente las tasas de acierto de caché y ajusta tu estrategia según sea necesario.

Optimizando para diferentes casos de uso

Adapta tu estrategia de almacenamiento en caché de prompts a tu escenario:
  • Agentes conversacionales: Reduce costo y latencia para conversaciones extendidas, especialmente aquellas con instrucciones largas o documentos cargados.
  • Asistentes de codificación: Mejora el autocompletado y preguntas y respuestas de 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 forma larga 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 almacenamiento en caché de prompts puedes obtener un rendimiento aún mejor incluyendo 20+ ejemplos diversos de respuestas de alta calidad.
  • Uso de herramientas agéntico: Mejora el rendimiento para escenarios que involucran múltiples llamadas de 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 forma larga: Trae cualquier base de conocimiento a la vida incrustando el documento(s) completo en el prompt, y dejando que los usuarios le hagan preguntas.

Solución de problemas comunes

Si experimentas comportamiento inesperado:
  • Asegúrate de que las secciones almacenadas en caché sean idénticas y estén marcadas con cache_control en las mismas ubicaciones en todas las llamadas
  • Verifica que las llamadas se realicen dentro de la vida útil del caché (5 minutos por defecto)
  • Verifica que tool_choice y el uso de imágenes permanezcan consistentes entre llamadas
  • Valida que estés almacenando en caché al menos el número mínimo de tokens
  • El sistema verifica automáticamente si hay coincidencias de caché en límites de bloques de contenido anteriores (hasta ~20 bloques antes de tu punto de ruptura). Para prompts con más de 20 bloques de contenido, es posible que necesites parámetros cache_control adicionales anteriormente en el prompt para asegurar que todo el contenido se pueda almacenar en caché
  • Verifica que las claves en tus bloques de contenido tool_use tengan ordenamiento estable ya que algunos lenguajes (por ejemplo, Swift, Go) aleatorizan el orden de claves durante la conversión JSON, rompiendo cachés
Los cambios a tool_choice o la presencia/ausencia de imágenes en cualquier lugar del prompt invalidarán el caché, requiriendo que se cree una nueva entrada de caché. Para más detalles sobre invalidación de caché, consulta Qué invalida el caché.

Almacenamiento en caché con bloques de pensamiento

Cuando se usa pensamiento extendido con almacenamiento en caché de prompts, los bloques de pensamiento tienen comportamiento especial: Almacenamiento automático en caché junto con otro contenido: Aunque los bloques de pensamiento no se pueden marcar explícitamente con cache_control, se almacenan en caché como parte del contenido de la solicitud cuando realizas llamadas a la 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 del caché, cuentan como tokens de entrada en tus métricas de uso. Esto es importante para el cálculo de costos y 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 añade contenido de usuario no relacionado con resultados de herramientas, causando que todos los bloques de pensamiento anteriores se eliminen
  • Este comportamiento de almacenamiento en caché ocurre incluso sin marcadores cache_control explícitos
Para más detalles sobre invalidación de caché, consulta Qué invalida el caché. Ejemplo con uso de herramientas:
Solicitud 1: Usuario: "¿Cuál es el clima en París?"
Respuesta: [thinking_block_1] + [tool_use block 1]

Solicitud 2:
Usuario: ["¿Cuál es el clima en París?"],
Asistente: [thinking_block_1] + [tool_use block 1],
Usuario: [tool_result_1, cache=True]
Respuesta: [thinking_block_2] + [text block 2]
# La solicitud 2 almacena en caché su contenido de solicitud (no la respuesta)
# El caché incluye: mensaje de usuario, thinking_block_1, tool_use block 1, y tool_result_1

Solicitud 3:
Usuario: ["¿Cuál es el clima en París?"],
Asistente: [thinking_block_1] + [tool_use block 1],
Usuario: [tool_result_1, cache=True],
Asistente: [thinking_block_2] + [text block 2],
Usuario: [Text response, cache=True]
# El bloque de usuario no relacionado con resultados de herramientas causa que todos los bloques de pensamiento se ignoren
# Esta solicitud se procesa como si los bloques de pensamiento nunca estuvieran presentes
Cuando se incluye un bloque de usuario no relacionado con resultados de herramientas, 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 de caché

  • Aislamiento de organización: Los cachés se aíslan entre organizaciones. Diferentes organizaciones nunca comparten cachés, incluso si utilizan 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 recibas será idéntica a la que obtendrías si el almacenamiento en caché de prompts no se utilizara.

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 con costo adicional. Para usar el caché extendido, incluye ttl en la definición de cache_control así:
"cache_control": {
    "type": "ephemeral",
    "ttl": "5m" | "1h"
}
La respuesta incluirá información detallada del caché como la siguiente:
{
    "usage": {
        "input_tokens": ...,
        "cache_read_input_tokens": ...,
        "cache_creation_input_tokens": ...,
        "output_tokens": ...,

        "cache_creation": {
            "ephemeral_5m_input_tokens": 456,
            "ephemeral_1h_input_tokens": 100,
        }
    }
}
Ten en cuenta que el campo cache_creation_input_tokens actual 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 a una cadencia regular (es decir, prompts del sistema que se usan más frecuentemente que cada 5 minutos), continúa usando el caché de 5 minutos, ya que esto continuará siendo actualizado sin costo adicional. El caché de 1 hora se usa mejor en los siguientes escenarios:
  • Cuando tienes prompts que probablemente se usan menos frecuentemente que cada 5 minutos, pero más frecuentemente que cada hora. Por ejemplo, cuando un agente secundario agéntico tardará más de 5 minutos, o cuando almacenas una conversación de chat larga 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 5 minutos.
  • Cuando deseas mejorar tu utilización de límite de velocidad, ya que los aciertos de caché no se deducen de tu límite de velocidad.
El caché de 5 minutos y 1 hora se comportan igual con respecto a la latencia. Generalmente verás tiempo mejorado al primer token para documentos largos.

Mezclando 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 TTLs más cortos (es decir, una entrada de caché de 1 hora debe aparecer antes que cualquier entrada de caché de 5 minutos). Cuando se mezclan TTLs, determinamos tres ubicaciones de facturación en tu prompt:
  1. Posición A: El conteo de tokens en el acierto de caché más alto (o 0 si no hay aciertos).
  2. Posición B: El conteo de tokens en el bloque cache_control de 1 hora más alto después de A (o es igual a A si ninguno existe).
  3. Posición C: El conteo de tokens en el último bloque cache_control.
Si B y/o C son mayores que A, necesariamente serán fallos de caché, porque A es el acierto de caché más alto.
Se te cobrará por:
  1. Tokens de lectura de caché para A.
  2. Tokens de escritura de caché de 1 hora para (B - A).
  3. Tokens de escritura de 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 de caché y fallos de caché. Cada una tiene una facturación diferente calculada, mostrada en los cuadros de color, como resultado. Diagrama de mezcla de TTLs

Ejemplos de almacenamiento en caché de prompts

Para ayudarte a comenzar con el almacenamiento en caché de prompts, hemos preparado un libro de recetas de almacenamiento en 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 almacenamiento en caché de prompts. Estos ejemplos demuestran cómo implementar el almacenamiento en caché en diferentes escenarios, ayudándote a entender las aplicaciones prácticas de esta característica:
curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "system": [
        {
            "type": "text",
            "text": "You are an AI assistant tasked with analyzing legal documents."
        },
        {
            "type": "text",
            "text": "Here is the full text of a complex legal agreement: [Insert full text of a 50-page legal agreement here]",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": "What are the key terms and conditions in this agreement?"
        }
    ]
}'
Este ejemplo demuestra el uso básico del almacenamiento en caché de prompts, almacenando en caché el texto completo del acuerdo legal como prefijo mientras se mantiene la instrucción del usuario sin almacenar en caché.Para la primera solicitud:
  • input_tokens: Número de tokens en el mensaje del usuario solamente
  • cache_creation_input_tokens: Número de tokens en el mensaje del sistema completo, incluyendo el documento legal
  • cache_read_input_tokens: 0 (sin acierto de caché en la primera solicitud)
Para solicitudes posteriores dentro de la vida útil del caché:
  • input_tokens: Número de tokens en el mensaje del usuario solamente
  • cache_creation_input_tokens: 0 (sin creación de caché nueva)
  • cache_read_input_tokens: Número de tokens en el mensaje del sistema completo almacenado en caché
curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "tools": [
        {
            "name": "get_weather",
            "description": "Get the current weather in a given location",
            "input_schema": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "The city and state, e.g. San Francisco, CA"
                    },
                    "unit": {
                        "type": "string",
                        "enum": ["celsius", "fahrenheit"],
                        "description": "The unit of temperature, either celsius or fahrenheit"
                    }
                },
                "required": ["location"]
            }
        },
        # many more tools
        {
            "name": "get_time",
            "description": "Get the current time in a given time zone",
            "input_schema": {
                "type": "object",
                "properties": {
                    "timezone": {
                        "type": "string",
                        "description": "The IANA time zone name, e.g. America/Los_Angeles"
                    }
                },
                "required": ["timezone"]
            },
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": "What is the weather and time in New York?"
        }
    ]
}'
En este ejemplo, demostramos el almacenamiento en caché de definiciones de herramientas.El parámetro cache_control se coloca en la herramienta final (get_time) para designar todas las herramientas como parte del prefijo estático.Esto significa que todas las definiciones de herramientas, incluyendo get_weather y cualquier otra herramienta definida antes de get_time, se almacenarán en caché como un único prefijo.Este enfoque es útil cuando tienes un conjunto consistente de herramientas que deseas reutilizar en múltiples solicitudes sin reprocesarlas cada vez.Para la primera solicitud:
  • input_tokens: Número de tokens en el mensaje del usuario
  • cache_creation_input_tokens: Número de tokens en todas las definiciones de herramientas y prompt del sistema
  • cache_read_input_tokens: 0 (sin acierto de caché en la primera solicitud)
Para solicitudes posteriores dentro de la vida útil del caché:
  • input_tokens: Número de tokens en el mensaje del usuario
  • cache_creation_input_tokens: 0 (sin creación de caché nueva)
  • cache_read_input_tokens: Número de tokens en todas las definiciones de herramientas almacenadas en caché y prompt del sistema
curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "system": [
        {
            "type": "text",
            "text": "...long system prompt",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Hello, can you tell me more about the solar system?",
                }
            ]
        },
        {
            "role": "assistant",
            "content": "Certainly! The solar system is the collection of celestial bodies that orbit our Sun. It consists of eight planets, numerous moons, asteroids, comets, and other objects. The planets, in order from closest to farthest from the Sun, are: Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, and Neptune. Each planet has its own unique characteristics and features. Is there a specific aspect of the solar system you would like to know more about?"
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Good to know."
                },
                {
                    "type": "text",
                    "text": "Tell me more about Mars.",
                    "cache_control": {"type": "ephemeral"}
                }
            ]
        }
    ]
}'
En este ejemplo, demostramos cómo usar el almacenamiento en caché de prompts en una conversación de múltiples turnos.Durante cada turno, marcamos el bloque final del mensaje final con cache_control para que la conversación se pueda almacenar en caché incrementalmente. El sistema buscará automáticamente y utilizará el prefijo previamente almacenado en caché más largo para mensajes de seguimiento. Es decir, los bloques que fueron marcados previamente con un bloque cache_control no se marcan más tarde con esto, pero aún se considerarán un acierto de caché (¡y también una actualización de caché!) si se alcanzan dentro de 5 minutos.Además, ten en cuenta que el parámetro cache_control se coloca en el mensaje del sistema. Esto es para asegurar que si esto se expulsa del caché (después de no usarse durante más de 5 minutos), se agregará de vuelta al caché en la siguiente solicitud.Este enfoque es útil para mantener contexto en conversaciones en curso sin reprocesar repetidamente la misma información.Cuando esto se configura correctamente, deberías ver lo siguiente en la respuesta de uso de cada solicitud:
  • input_tokens: Número de tokens en el nuevo mensaje del usuario (será mínimo)
  • cache_creation_input_tokens: Número de tokens en los nuevos turnos de asistente y usuario
  • cache_read_input_tokens: Número de tokens en la conversación hasta el turno anterior
curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "tools": [
        {
            "name": "search_documents",
            "description": "Search through the knowledge base",
            "input_schema": {
                "type": "object",
                "properties": {
                    "query": {
                        "type": "string",
                        "description": "Search query"
                    }
                },
                "required": ["query"]
            }
        },
        {
            "name": "get_document",
            "description": "Retrieve a specific document by ID",
            "input_schema": {
                "type": "object",
                "properties": {
                    "doc_id": {
                        "type": "string",
                        "description": "Document ID"
                    }
                },
                "required": ["doc_id"]
            },
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "system": [
        {
            "type": "text",
            "text": "You are a helpful research assistant with access to a document knowledge base.\n\n# Instructions\n- Always search for relevant documents before answering\n- Provide citations for your sources\n- Be objective and accurate in your responses\n- If multiple documents contain relevant information, synthesize them\n- Acknowledge when information is not available in the knowledge base",
            "cache_control": {"type": "ephemeral"}
        },
        {
            "type": "text",
            "text": "# Knowledge Base Context\n\nHere are the relevant documents for this conversation:\n\n## Document 1: Solar System Overview\nThe solar system consists of the Sun and all objects that orbit it...\n\n## Document 2: Planetary Characteristics\nEach planet has unique features. Mercury is the smallest planet...\n\n## Document 3: Mars Exploration\nMars has been a target of exploration for decades...\n\n[Additional documents...]",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": "Can you search for information about Mars rovers?"
        },
        {
            "role": "assistant",
            "content": [
                {
                    "type": "tool_use",
                    "id": "tool_1",
                    "name": "search_documents",
                    "input": {"query": "Mars rovers"}
                }
            ]
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "tool_result",
                    "tool_use_id": "tool_1",
                    "content": "Found 3 relevant documents: Document 3 (Mars Exploration), Document 7 (Rover Technology), Document 9 (Mission History)"
                }
            ]
        },
        {
            "role": "assistant",
            "content": [
                {
                    "type": "text",
                    "text": "I found 3 relevant documents about Mars rovers. Let me get more details from the Mars Exploration document."
                }
            ]
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Yes, please tell me about the Perseverance rover specifically.",
                    "cache_control": {"type": "ephemeral"}
                }
            ]
        }
    ]
}'
Este ejemplo completo demuestra cómo usar los 4 puntos de ruptura de caché disponibles para optimizar diferentes partes de tu prompt:
  1. Caché de herramientas (punto de ruptura de caché 1): El parámetro cache_control en la última definición de herramienta almacena en caché todas las definiciones de herramientas.
  2. Caché de instrucciones reutilizables (punto de ruptura de caché 2): Las instrucciones estáticas en el prompt del sistema se almacenan en caché por separado. Estas instrucciones rara vez cambian entre solicitudes.
  3. Caché de contexto RAG (punto de ruptura de caché 3): Los documentos de la base de conocimiento se almacenan en caché independientemente, permitiéndote actualizar los documentos RAG sin invalidar el caché de herramientas o instrucciones.
  4. Caché del historial de conversación (punto de ruptura de caché 4): La respuesta del asistente se marca con cache_control para habilitar el almacenamiento en caché incremental de la conversación a medida que progresa.
Este enfoque proporciona máxima flexibilidad:
  • Si solo actualizas el mensaje del usuario final, se reutilizan los cuatro segmentos de caché
  • Si actualizas los documentos RAG pero mantienes las mismas herramientas e instrucciones, se reutilizan los primeros dos segmentos de caché
  • Si cambias la conversación pero mantienes las mismas herramientas, instrucciones y documentos, se reutilizan los primeros tres segmentos
  • Cada punto de ruptura de caché se puede invalidar independientemente basado en qué cambia en tu aplicación
Para la primera solicitud:
  • input_tokens: Tokens en el mensaje del usuario final
  • cache_creation_input_tokens: Tokens en todos los segmentos almacenados en caché (herramientas + instrucciones + documentos RAG + historial de conversación)
  • cache_read_input_tokens: 0 (sin aciertos de caché)
Para solicitudes posteriores con solo un nuevo mensaje del usuario:
  • input_tokens: Tokens en el nuevo mensaje del usuario solamente
  • cache_creation_input_tokens: Cualquier token nuevo añadido al historial de conversación
  • cache_read_input_tokens: Todos los tokens previamente almacenados en caché (herramientas + instrucciones + documentos RAG + conversación anterior)
Este patrón es especialmente poderoso para:
  • Aplicaciones RAG con contextos de documentos grandes
  • Sistemas de agentes que usan múltiples herramientas
  • Conversaciones de larga duración que necesitan mantener contexto
  • Aplicaciones que necesitan optimizar diferentes partes del prompt independientemente

Preguntas frecuentes

En la mayoría de los casos, un único punto de ruptura de caché al final de tu contenido estático es suficiente. El sistema verifica automáticamente si hay aciertos de caché en todos los límites de bloques de contenido anteriores (hasta 20 bloques antes de tu punto de ruptura) y utiliza el prefijo coincidente más largo.Solo necesitas múltiples puntos de ruptura si:
  • Tienes más de 20 bloques de contenido antes de tu punto de caché deseado
  • Deseas almacenar en caché secciones que se actualizan a diferentes frecuencias independientemente
  • Necesitas control explícito sobre qué se almacena en caché para optimización de costos
Ejemplo: Si tienes instrucciones del sistema (rara vez cambian) y contexto RAG (cambia diariamente), podrías usar dos puntos de ruptura para almacenarlos en caché por separado.
No, los puntos de ruptura de caché en sí son gratuitos. Solo pagas por:
  • Escribir contenido en el caché (25% más que tokens de entrada base para TTL de 5 minutos)
  • Leer del caché (10% del precio de token de entrada base)
  • Tokens de entrada regulares para contenido no almacenado en caché
El número de puntos de ruptura no afecta los precios - solo importa la cantidad de contenido almacenado en caché y leído.
La vida útil mínima por defecto del caché (TTL) es de 5 minutos. Esta vida útil se actualiza cada vez que se utiliza el contenido almacenado en caché.Si encuentras que 5 minutos es demasiado corto, Anthropic también ofrece un TTL de caché de 1 hora.
Puedes definir hasta 4 puntos de ruptura de caché (usando parámetros cache_control) en tu prompt.
No, el almacenamiento en caché de prompts está actualmente disponible solo para Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4.5, Claude Sonnet 4, Claude Sonnet 3.7, Claude Haiku 4.5, Claude Haiku 3.5, Claude Haiku 3 y Claude Opus 3 (deprecado).
Los prompts del sistema almacenados en caché y las herramientas se reutilizarán cuando cambien los parámetros de pensamiento. Sin embargo, los cambios de pensamiento (habilitar/deshabilitar o cambios de presupuesto) invalidarán los prefijos de prompt previamente almacenados en caché con contenido de mensajes.Para más detalles sobre invalidación de caché, consulta Qué invalida el caché.Para más sobre pensamiento extendido, incluyendo su interacción con el uso de herramientas y almacenamiento en caché de prompts, consulta la documentación de pensamiento extendido.
Para habilitar el almacenamiento en caché de prompts, incluye al menos un punto de ruptura cache_control en tu solicitud de API.
Sí, el almacenamiento en caché de prompts se puede usar junto con otras características de la API como uso de herramientas y capacidades de visión. Sin embargo, cambiar si hay imágenes en un prompt o modificar la configuración de uso de herramientas romperá el caché.Para más detalles sobre invalidación de caché, consulta Qué invalida el caché.
El almacenamiento en caché de prompts introduce una nueva estructura de precios donde las escrituras de caché cuestan 25% más que tokens de entrada base, mientras que los aciertos de caché cuestan solo 10% del precio de token de entrada base.
Actualmente, no hay forma de limpiar manualmente el caché. Los prefijos almacenados en caché expiran automáticamente después de un mínimo de 5 minutos de inactividad.
Puedes monitorear el rendimiento del caché usando los campos cache_creation_input_tokens y cache_read_input_tokens en la respuesta de la API.
Consulta Qué invalida el caché para más detalles sobre invalidación de caché, incluyendo una lista de cambios que requieren crear una nueva entrada de caché.
El almacenamiento en caché de prompts está diseñado con medidas fuertes de privacidad y separación de datos:
  1. Las claves de caché se generan usando un hash criptográfico de los prompts hasta el punto de control de caché. Esto significa que solo las solicitudes con prompts idénticos pueden acceder a un caché específico.
  2. Los cachés son específicos de la organización. Los usuarios dentro de la misma organización pueden acceder al mismo caché si usan prompts idénticos, pero los cachés no se comparten entre diferentes organizaciones, incluso para prompts idénticos.
  3. El mecanismo de almacenamiento en caché está diseñado para mantener la integridad y privacidad de cada conversación o contexto único.
  4. Es seguro usar cache_control en cualquier lugar de tus prompts. Para eficiencia de costos, es mejor excluir partes altamente variables (por ejemplo, entrada arbitraria del usuario) del almacenamiento en caché.
Estas medidas aseguran que el almacenamiento en caché de prompts mantenga la privacidad y seguridad de datos mientras ofrece beneficios de rendimiento.
Sí, es posible usar el almacenamiento en caché de prompts con tus solicitudes de API de Batches. Sin embargo, porque las solicitudes de lotes asincrónicas se pueden procesar concurrentemente y en cualquier orden, los aciertos de caché se proporcionan en base de mejor esfuerzo.El caché de 1 hora puede ayudar a mejorar tus aciertos de caché. La forma más rentable de usarlo es la siguiente:
  • Reúne un conjunto de solicitudes de mensajes que tienen un prefijo compartido.
  • Envía una solicitud de lote con solo una solicitud que tenga este prefijo compartido y un bloque de caché de 1 hora. Esto se escribirá en el caché de 1 hora.
  • Tan pronto como esto se complete, envía el resto de las solicitudes. Tendrás que monitorear el trabajo para saber cuándo se completa.
Esto es típicamente mejor que usar el caché de 5 minutos simplemente porque es común que las solicitudes de lote tarden entre 5 minutos y 1 hora en completarse. Estamos considerando formas de mejorar estas tasas de acierto de caché y hacer este proceso más directo.
Este error típicamente aparece cuando has actualizado tu SDK o estás usando ejemplos de código desactualizados. El almacenamiento en caché de prompts ahora está generalmente disponible, así que ya no necesitas el prefijo beta. En lugar de:
python client.beta.prompt_caching.messages.create(...)
Simplemente usa:
python client.messages.create(...)
Este error típicamente aparece cuando has actualizado tu SDK o estás usando ejemplos de código desactualizados. El almacenamiento en caché de prompts ahora está generalmente disponible, así que ya no necesitas el prefijo beta. En lugar de:
TypeScript
client.beta.promptCaching.messages.create(...)
Simplemente usa:
client.messages.create(...)