# Caché de prompts de Anthropic: cómo verificar los aciertos y saber si ahorra > La caché de prompts de Anthropic puede reducir los costes de entrada cuando se reutiliza un prefijo estable, pero las escrituras en caché cuestan más que la entrada ordinaria. Así se activa la caché de prompts de Claude, se verifican los aciertos y se calcula tu punto de equilibrio. La caché de prompts de Anthropic es fácil de activar y fácil de malinterpretar. La primera petición puede costar más, una petición posterior puede fallar el acierto sin dar error, y un prefijo "en caché" puede ser demasiado corto para cumplir los requisitos. **Respuesta corta:** coloca el breakpoint de caché al final del contenido que permanece idéntico entre peticiones y confirma después que una respuesta posterior reporta `cache_read_input_tokens` por encima de cero usando [los campos de uso de respuesta de Anthropic](https://platform.claude.com/docs/en/build-with-claude/prompt-caching). Calcula el precio de la primera escritura en caché y de cada lectura frente a tu número esperado de reutilizaciones: en Claude Sonnet 5.5, una lectura dentro de la ventana de cinco minutos amortiza el recargo de escritura; la caché de una hora necesita dos lecturas. Estas cifras de la API no te dicen cómo se miden los límites de las suscripciones de Claude. Los precios y detalles de producto siguientes se verificaron el 4 de octubre de 2026. ## ¿Cómo funciona la caché de prompts de Anthropic y cómo se activa? La caché de prompts de Claude reutiliza un prefijo de prompt coincidente para que el modelo pueda leer la entrada cacheada en lugar de procesarla de nuevo como entrada fresca. Para una primera prueba con la API, usa la caché automática: añade el campo `cache_control` de nivel superior a una petición de Messages. En una llamada existente de Python a la API de Messages de Anthropic, añade este argumento de petición (insértalo en `client.messages.create(...)`): ```python cache_control={"type": "ephemeral"} ``` Esa configuración de control de caché de Anthropic a nivel superior procede de [la documentación de caché de prompts](https://platform.claude.com/docs/en/build-with-claude/prompt-caching). Los ejemplos actuales usan `client.messages.create(...)`; la antigua ruta `client.beta.prompt_caching.messages.create(...)` ya no es necesaria. Para un documento o conjunto de herramientas estático, un breakpoint explícito a nivel de bloque te permite controlar exactamente dónde termina el prefijo reutilizable. Anthropic permite hasta cuatro breakpoints. Para verificar un acierto, haz dos peticiones con el mismo modelo y un prefijo sin cambios, y que la segunda petición empiece antes de que expire la caché. Lee el objeto `usage` de la respuesta: | Campo | Qué te indica | | ----------------------------- | ----------------------------------------------------- | | `cache_creation_input_tokens` | Tokens de entrada escritos en caché en esta respuesta | | `cache_read_input_tokens` | Tokens de entrada servidos desde caché | | `input_tokens` | Entrada no cacheada después del último breakpoint | Una primera petición debería mostrar creación de caché. Una petición posterior debería mostrar lecturas de caché; con la caché automática, también puede escribirse una nueva cola. Anthropic define la entrada total como la suma de estos tres campos, así que no uses `input_tokens` por sí solo como tamaño total del prompt. Si ambos recuentos de caché son cero, el prompt no se cacheó. Una respuesta de uso de la API demuestra el comportamiento a nivel de petición que observaste; no establece la tasa de aciertos de toda tu carga de trabajo en producción. ## ¿Deberías usar la caché de cinco minutos o la de una hora? Usa la caché de cinco minutos cuando las llamadas reutilizan el mismo prefijo dentro de esos cinco minutos. Elige la opción de una hora cuando los intervalos reales superan con regularidad esa ventana y aun así caen dentro de una hora. Anthropic inicia el reloj del TTL cuando empieza la petición, no cuando termina su respuesta; un stream de cuatro minutos deja aproximadamente un minuto para que llegue la siguiente petición. El punto de equilibrio depende del número de lecturas exitosas, no de que el prompt simplemente tenga un breakpoint. Para una comparación sencilla, toma un prefijo fijo de 100,000 tokens en Claude Sonnet 5.5. La [tabla de precios actual de Anthropic](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) indica $2 por millón de tokens de entrada ordinarios, $2.50 por millón de escrituras en caché de cinco minutos, $4 por millón de escrituras de una hora y $0.20 por millón de lecturas. La lectura cuesta 0.1× la entrada base en este modelo. Para `R` lecturas de caché, el prefijo cacheado cuesta `write rate + (R × read rate)`. Sin caché, cuesta `base rate × (1 + R)`. Esto da los siguientes totales solo para el prefijo; la salida y las colas de petición cambiantes quedan excluidas: | Lecturas tras la primera escritura, dentro del TTL | Sin caché | Caché de 5 minutos | Caché de 1 hora | | -------------------------------------------------: | --------: | -----------------: | --------------: | | 0 | $0.20 | $0.25 (125%) | $0.40 (200%) | | 1 | $0.40 | $0.27 (67.5%) | $0.42 (105%) | | 2 | $0.60 | $0.29 (48.3%) | $0.44 (73.3%) | | 4 | $1.00 | $0.33 (33%) | $0.48 (48%) | | 10 | $2.20 | $0.45 (20.5%) | $0.60 (27.3%) | Los porcentajes son el coste con caché dividido entre el coste sin caché. En este modelo y bajo estos supuestos, la caché de cinco minutos es más barata a partir de una lectura; la de una hora resulta más barata a partir de dos. La primera escritura de una hora cuesta el doble de la tarifa de entrada ordinaria, así que extender el TTL no es automáticamente un ahorro. Los multiplicadores actuales de lectura de caché de Anthropic difieren para algunos modelos —5% para Opus 5.5 y 2.5% para Fable 5.1 y Mythos 5.1—, así que recalcula a partir de la fila del modelo al que realmente llamas. Precios verificados en octubre de 2026. Un [post de LinkedIn de Roy Derks](https://www.linkedin.com/posts/gethackteam_prompt-caching-can-make-your-llm-api-bill-activity-7494319569314967552-RBjc) desarrolla un caso hipotético que explica las quejas de "la caché me subió la factura": un agente se ejecuta cada 10 minutos con un prompt reutilizable de 100,000 tokens, de modo que cada una de sus diez llamadas llega después de que la entrada de cinco minutos haya expirado. Cada llamada paga la escritura de 1.25× y ninguna obtiene la lectura de 0.1×, así que $10 de entrada sin caché se convierten en $12.50, un 25% más. Es un escenario calculado, no una carga de trabajo medida. Compara tus propios contadores de uso e intervalos de llamada antes de pronosticar nada a partir de él. ## ¿Por qué mi caché no recibe aciertos? Un acierto de caché requiere el mismo prefijo hasta el breakpoint marcado y una longitud de prompt elegible. | Lo que ves | Causa probable | Solución | | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Ambos contadores de caché se quedan en cero | El prefijo marcado es más corto que el mínimo del modelo. Para Claude Sonnet 5.5, el [mínimo actual es de 512 tokens](https://platform.claude.com/docs/en/build-with-claude/prompt-caching); las peticiones más cortas se ejecutan sin error de caché. | Incluye suficiente contenido estable para superar el mínimo del modelo e inspecciona después el usage de la siguiente respuesta. | | Una reescritura completa o grande sigue a un cambio pequeño en la petición | Los bytes cambiados están antes del breakpoint. La [tabla de invalidación de Anthropic](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) cubre ediciones en las definiciones de herramientas, los interruptores de búsqueda web, citas y velocidad, `tool_choice`, imágenes y ajustes de thinking; los cambios en las definiciones de herramientas invalidan toda la caché. | Mantén primero las instrucciones y definiciones de herramientas estables; mueve las marcas de tiempo, los valores por petición y la nueva entrada del usuario después del breakpoint del prefijo estático. | | Un último bloque cambiante se escribe de nuevo en cada llamada | La [caché automática](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) mueve el breakpoint al último bloque cacheable; si ese bloque cambia, no hay entrada reutilizable en el límite estable anterior. | Coloca un breakpoint explícito en el último bloque que permanece idéntico. | | Un intervalo provoca inesperadamente una escritura | La [vida útil de la caché](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) expiró, o una respuesta larga consumió la mayor parte del TTL antes de que empezara la siguiente petición. | Mide los intervalos entre inicios de petición; usa `ttl: "1h"` si tu ventana de reutilización esperada lo requiere y el cargo extra de escritura sale a cuenta. | | Las herramientas o mensajes parecen idénticos pero las lecturas caen | El orden o la serialización cambiaron el prefijo. La [guía de solución de problemas de Anthropic](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) advierte que un orden inestable de claves JSON dentro de los bloques `tool_use` puede romper la reutilización. | Mantén estable el orden de herramientas y mensajes y serializa los valores estructurados de forma determinista. | El prefijo de la petición se ordena como `tools`, luego `system`, luego `messages`. Un cambio temprano en esa secuencia invalida el contenido cacheado posterior. Un breakpoint es un límite donde Anthropic escribe una entrada; no busca hacia atrás ni crea una entrada de caché faltante para un bloque estable anterior. Su búsqueda retrospectiva solo puede encontrar entradas que las peticiones anteriores ya escribieron. Consulta [la guía de invalidación y breakpoints de Anthropic](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) cuando los campos de uso muestren un fallo que no puedes explicar. ## ¿Cómo funciona la caché de prompts de Claude Code? Claude Code gestiona la caché de prompts automáticamente. No añades `cache_control` a una sesión normal de Claude Code. Sus capas de petición colocan el prompt del sistema y el contexto del proyecto antes de la conversación creciente, así que cambiar una capa anterior puede invalidar todo lo que viene después. El TTL depende de la autenticación: la [guía actual de caché de prompts de Claude Code](https://code.claude.com/docs/en/prompt-caching) indica una hora para la conversación principal de una suscripción, pero cinco minutos por defecto para claves de API y proveedores cloud. Claude Code v2.1.242 o posterior admite configuraciones de TTL por bucket. Para solicitar una hora para ambos buckets con la variable de entorno documentada, establece `ENABLE_PROMPT_CACHING_1H=1`; los ajustes individuales o las variables de entorno pueden tener prioridad, así que revisa la lista de precedencia de la guía antes de dar por hecho qué TTL se aplicó. Para un resumen de la sesión, ejecuta `/usage`. El bloque Session de Claude Code reporta la tasa de aciertos de caché y el recuento de fallos de la conversación principal después de su primera respuesta. Como evidencia a nivel de petición, la guía documenta `cache_creation_input_tokens` y `cache_read_input_tokens`; en v2.1.251 o posterior, los datos de su status line exponen el objeto `prompt_cache`. Estos contadores son más útiles que inferir un fallo solo a partir de una pausa larga. La visualización `Prompt cache (main)` de Claude Code puede incluir una causa probable, pero la transcripción de una sesión no es un diagnóstico universal. Por ejemplo, un [issue de Anthropic Claude Code](https://github.com/anthropics/claude-code/issues/94728) reporta dos reanudaciones medidas de subagentes en segundo plano en v2.1.273, ambas diagnosticadas como `messages_changed`, con escrituras en caché de 243,214 y 398,622 tokens. Trátalo como un reporte específico de versión y escenario; usa tus propios datos de uso y las notas de la versión actual antes de atribuir un cambio en la factura a un defecto general del producto. ## ¿Qué cambia en la caché de prompts en Amazon Bedrock y OpenRouter? La caché de prompts de Bedrock y la caché de prompts de OpenRouter siguen el mismo principio —reutilizar un prefijo estable elegible—, pero la superficie de API y el comportamiento de enrutamiento cambian según el proveedor. | Ruta | Qué difiere | Comprobación práctica | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | API de Anthropic | Añade `cache_control` automático de nivel superior o coloca breakpoints explícitos a nivel de bloque. La documentación actual indica hasta cuatro breakpoints y longitudes mínimas de tokens específicas por modelo. | Lee `usage.cache_creation_input_tokens` y `usage.cache_read_input_tokens` de Anthropic. | | Amazon Bedrock | [AWS documenta tanto la caché de prompts implícita como la explícita](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html). El soporte, el mínimo de tokens, el TTL y los campos de API varían según el modelo. Para la caché explícita de Claude, AWS ofrece un checkpoint único simplificado al final del contenido estático y revisa hacia atrás unos 20 bloques de contenido; la sintaxis exacta del checkpoint y de la petición depende de `InvokeModel` frente a `Converse`. | Consulta la ficha de modelo de Bedrock para el modelo y la región, e inspecciona después los campos de uso de la respuesta del proveedor. No copies a ciegas un payload de la API de Anthropic. | | OpenRouter | La [guía de OpenRouter](https://openrouter.ai/docs/guides/best-practices/prompt-caching) documenta la caché automática de nivel superior y los marcadores explícitos por bloque. Puede usar enrutamiento sticky de proveedor tras una petición cacheada para enviar las llamadas posteriores al mismo endpoint; el orden manual de proveedores tiene prioridad. Su Responses API expone la caché automática, mientras que los controles por bloque al estilo de Anthropic no se exponen ahí. | Mantén una sesión o mensajes iniciales estables y comprueba qué proveedor sirvió cada petición; los cambios de ruta pueden afectar a la reutilización. | En Bedrock, la [guía de plataforma actual de Anthropic](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) dice que las integraciones heredadas de Bedrock para Opus 4.6 y anteriores rechazan el campo automático de nivel superior; los breakpoints explícitos son la vía documentada ahí. La [página actual de AWS](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html) identifica el soporte, los mínimos y los TTL específicos por modelo. Sigue la página de tu modelo exacto en lugar de arrastrar esa regla de integración antigua a todos los modelos de Claude en Bedrock. Si estás construyendo una capa de proveedores, mantén la entrada fresca, las lecturas de caché y las escrituras de caché como valores de uso separados. En Muvon construimos Octolib; su adaptador de Anthropic mapea por separado los campos de la API `cache_read_input_tokens` y los de escritura efímera, de modo que un total a nivel de gateway no oculta la distinción. Nuestras notas sobre [uso de tokens de LLM y una capa de proveedores unificada](/blog/lessons-building-a-unified-llm-provider-layer-in-rust) explican el problema contable más amplio. Para visibilidad a nivel de proxy, consulta [el proxy de LLM OctoHub](/blog/introducing-octohub-llm-proxy-for-observability); para las compensaciones de coste del enrutamiento de modelos, consulta [nuestra guía de enrutamiento de LLM](/blog/running-one-ai-agent-across-many-models). Ahora puedes activar la caché, hacer dos peticiones, verificar el campo de lectura y comparar la cadencia de reutilización medida con la tabla de precios fechada. Si esas cuatro comprobaciones no concuerdan, deja de optimizar la factura estimada e inspecciona primero el prefijo y la ruta del proveedor. — Don --- _En Muvon construimos Octolib y mantenemos las lecturas y escrituras de caché visibles como campos de uso separados. Si encuentras una respuesta de proveedor que dificulta conciliar esos números, [abre un issue](https://github.com/Muvon/octolib/issues)._