El prompt caching (caché de prompts) es un mecanismo de precios que ofrecen algunos proveedores de IA: el contenido que envías repetidamente (prompts de sistema, definiciones de herramientas, descripciones de fondo del proyecto) se almacena temporalmente, así que la próxima vez que aparece exactamente el mismo contenido, se te cobra la tarifa más barata de "lectura de caché" en lugar de la tarifa completa de "entrada". Pero escribir en la caché también cuesta dinero — si el prefijo de tu contenido no es suficientemente estable o tu tasa de aciertos es demasiado baja, el costo de escritura puede superar lo que ahorras en lecturas, y tu factura total sube en vez de bajar. Ese es exactamente el hallazgo contraintuitivo de una prueba sistemática de 5 estrategias de gestión de contexto realizada por el canal de YouTube Atef Ataya.
Este artículo desglosa: qué ahorra realmente el caching, en qué condiciones se vuelve una carga en vez de un ahorro, y — más allá del caching — un orden de gasto más fundamental que vale la pena considerar primero.
¿Qué es exactamente lo que cachea el prompt caching?
La mayoría de las API de LLM dividen una sola llamada en "tokens de entrada" y "tokens de salida" con precios separados, y el caching divide aún más el lado de entrada en dos estados: escritura de caché (cache creation) y lectura de caché (cache read). La primera vez que se envía un contenido fijo, el sistema tiene que almacenarlo, y ese costo suele ser igual o mayor al precio normal de entrada. Después, cada vez que ese mismo contenido reaparece intacto al frente de una solicitud, el sistema acierta en la caché y cobra la tarifa de "lectura" mucho más baja.
En otras palabras, el caching no te ahorra dinero en el contenido en sí — te ahorra dinero en la repetición. Si un contenido es diferente en cada llamada, la caché nunca puede acertar, y habrás pagado una tarifa de escritura por un descuento que nunca vas a cobrar.
¿Dónde debe ir la caché? Prefijo estable vs. datos de la tarea
La prueba enfatiza especialmente una regla de orden: coloca el contenido que nunca cambia al frente de la solicitud — reglas de sistema, definiciones de herramientas, descripciones fijas del proyecto o del código — y coloca los datos que cambian en cada llamada después. La lógica es directa: el caching funciona comparando si el prefijo coincide carácter por carácter. En el momento en que un solo carácter al frente es distinto, todo lo que viene después no se puede aprovechar aunque sea idéntico. Mezclar contenido volátil delante de contenido estable equivale a sabotear tu propia cadena de caché.
Por el contrario, si un proyecto tiene pocas definiciones de herramientas y su descripción de fondo se reescribe con cada tarea, el "prefijo estable" que la caché puede aprovechar es, por naturaleza, corto — y el beneficio de activar el caching es limitado desde el inicio.
¿Por qué bajó el volumen de lecturas de caché pero la factura subió?
Esta es la parte más contraintuitiva de toda la prueba. En el experimento donde se añadió caching manualmente, el volumen de "entrada cacheada" sí bajó alrededor de un 15% — lo que suena a que debería ahorrar dinero — pero el costo total subió de todos modos en cerca de un 7%. La razón: el ahorro de menos lecturas fue devorado por la sobrecarga que las propias lecturas de caché generan. Cuando la tasa de aciertos no es estable y el prefijo se rompe constantemente, el sistema tiene que reescribir la caché sin parar y disparar más solicitudes de lectura, y esas lecturas dispersas adicionales suman más de lo que originalmente se ahorró.
Eso también explica por qué el caching no es una función que "simplemente ahorra dinero al activarla" — es un problema de precios altamente ligado a tu patrón de uso: una tasa de aciertos alta y estable hace que valga la pena pagar el costo de escritura por el descuento de lectura; una tasa de aciertos baja convierte ese mismo costo de escritura en pura sobrecarga.
¿Cómo elegir el tiempo de retención de la caché (TTL)?
La mayoría de las API que ofrecen prompt caching te dejan elegir cuánto tiempo mantener viva una caché — y cuanto más tiempo la mantienes, normalmente pagas un múltiplo más alto sobre el costo de escritura, a cambio de una ventana más larga en la que puedes seguir acertando el descuento. Esto es fundamentalmente un intercambio de riesgo: si tienes la certeza de que vas a llamar el mismo prefijo repetidamente en una ventana corta, un TTL más largo vale la pena; pero si tu frecuencia de llamadas es baja, o el prefijo puede cambiar a mitad de camino, el costo extra de escritura que pagaste puede nunca recuperar suficientes aciertos para compensar.
⚠️ Vale la pena señalar específicamente: el video indica que la API de Claude actualmente expone el uso de caché mediante dos campos separados — "tokens de escritura de caché" y "tokens de lectura de caché" — y ofrece dos niveles de TTL para elegir (el nivel más corto a precio estándar de caché, el nivel más largo con un múltiplo). Esto describe cómo el video original caracteriza el mecanismo; la duración real de los niveles y los múltiplos de tarifa deben verificarse contra la página oficial de precios vigente de Anthropic, en lugar de depender de un solo video.
El paso que va antes del caching: no es cargar de forma más inteligente, es no cargar en absoluto
La prueba comparó 5 formas de reducir el costo de contexto, y la que quedó en primer lugar — mayor efecto, más consistente — no fue ninguna forma de caching ni de recuperación inteligente. Fue la jugada más simple posible: antes de tocar la tarea, decide explícitamente qué archivos o datos realmente necesitas, y no leas nada más. Esto redujo lo suficiente el volumen de datos enviados al modelo como para que el costo total quedara aproximadamente un 30% por debajo de la línea base de no hacer nada, y fue la única estrategia que ahorró dinero de forma consistente en cada ronda repetida de la prueba.
La lógica detrás es simple: el caching y la indexación estructurada hacen que "cargar" sea más eficiente, pero el modelo de todos modos cobra por cada token que carga; en cambio, filtrar y excluir datos irrelevantes primero significa que una parte de los tokens nunca se envía en absoluto — ese dinero de verdad nunca se gasta. El token más barato es el que nunca llegó a entrar en la solicitud.
"Cargar solo cuando se necesita" suena de lo más razonable — ¿por qué la prueba mostró que era la estrategia más cara?
Otra intuición común es empezar con el contexto mínimo posible, ir a buscar lo que se necesite sobre la marcha, y descartarlo una vez usado — suena como el enfoque más frugal en recursos, pero en esta prueba resultó ser, por sí sola, la estrategia más cara, costando casi un 45% más que la línea base.
El problema está en la mecánica de facturación: la mayoría de las API de LLM cobran por solicitud completa, y cada solicitud tiene que reenviar todo el historial de conversación acumulado hasta ese momento. "Descartar una vez usado" solo hace que el modelo "olvide" el contenido de un archivo — no hace que ese archivo desaparezca de la factura. Si una tarea necesita revisar decenas de archivos uno tras otro, eso equivale a decenas de solicitudes de ida y vuelta, y cada ida y vuelta tiene que volver a adjuntar todo el contenido de la conversación anterior. Una estrategia diseñada para "reducir" el contexto termina siendo la que retransmite más contexto, repetidamente. Esta es también la advertencia específica señalada en la prueba: la optimización de la gestión de contexto debe mirar el total de tokens enviados en toda la tarea, no qué tan limpia se ve una sola solicitud.
¿Por qué apilar todos los trucos de ahorro juntos sale peor que no hacer nada?
Combinar todas las estrategias de gestión de contexto anteriores a la vez es lo que muchas guías recomiendan por defecto, pero la prueba encontró que la combinación completamente apilada costó alrededor de un 23% más que la línea base de no hacer nada — peor que usar cualquier estrategia por sí sola.
La razón: distintas estrategias chocan entre sí en lugar de sumarse. Por ejemplo, hacer dos tipos distintos de análisis estructural al mismo tiempo genera sobrecarga de análisis duplicada; y el caching y el "cargar solo cuando se necesita" se basan en supuestos de uso directamente contradictorios (uno asume un prefijo estable y repetido; el otro asume contenido fragmentado y cambiante). Activar ambos a la vez solo apila costo extra de configuración sin el ahorro correspondiente. Hacer más no es lo mismo que ahorrar más — cada estrategia tiene su propio costo de activación, y apilar más de ellas eleva la barra que hay que superar antes de que algo compense.
¿Cuándo vale realmente la pena activar el caching? Un orden de decisión
Reuniendo todo lo anterior, aquí hay un orden de prioridad aproximado para evaluar frente a tu propio patrón de uso:
1. Filtra primero, cachea después — antes de tocar la tarea, define claramente qué necesita realmente esta tarea específica, y excluye todo lo irrelevante de la solicitud desde el principio. Este es, por sí solo, el paso con mayor efecto y más consistente. 2. En segundo lugar, dale al modelo un mapa estructural ligero — un directorio compacto o un esquema de dependencias permite que el modelo localice lo que necesita sin depender de lecturas de prueba y error. 3. El caching va después de tus decisiones de arquitectura, tratado puramente como un problema de precios — primero confirma si tu patrón de uso realmente tiene un prefijo estable y llamado repetidamente; si es así, vale la pena activar el caching; si el contenido cambia con frecuencia y la frecuencia de llamadas es baja, el caching puede ser solo una tarifa de escritura adicional. 4. La recuperación por demanda va al final — solo vale la pena considerarla cuando el conjunto de datos candidato es genuinamente enorme y lo que realmente necesitas es una fracción mínima de él; de lo contrario, la facturación por solicitud y el hecho de reenviar el historial de conversación repetidamente hacen que sea muy fácil que se convierta en la opción más cara.
La lógica común detrás de este orden: resuelve primero "si este dato debería enviarse siquiera", antes de resolver "si enviarlo se puede abaratar". El caching resuelve lo segundo — y si lo primero no se atendió antes, el espacio que le queda al caching para ayudar es limitado de por sí.
Preguntas frecuentes
P1: ¿Qué es el prompt caching y en qué se diferencia del precio normal de una llamada a la API?
El precio normal divide una llamada solo en tokens de "entrada" y "salida". Al activar el caching, el lado de entrada se divide además en estados de "escritura de caché" y "lectura de caché": la primera vez que aparece un contenido fijo se paga una tarifa de escritura; cuando ese mismo contenido reaparece sin cambios después, se cobra a la tarifa de lectura, más baja.
P2: Si activo el prompt caching, ¿mi factura seguro que se abarata?
No necesariamente. Si el prefijo de tu contenido no es suficientemente estable, o el número de aciertos repetidos no es suficientemente alto, el costo de escritura de caché que pagas puede superar lo que ahorra el descuento de lectura — la propia prueba encontró un caso donde el volumen de lecturas de caché bajó pero el costo total subió de todos modos.
P3: El contenido de mis tareas cambia mucho — ¿me conviene el caching?
Si los datos de tu tarea son distintos cada vez, sin un prefijo fijo que no cambie, el caching prácticamente no tiene nada estable a lo que aferrarse, y su beneficio en ese escenario suele ser limitado. La prioridad debería estar en filtrar qué datos realmente necesitas primero, en lugar de apresurarte a activar el caching.
P4: ¿Debo elegir un TTL corto o largo?
Depende de qué tan frecuente sea que vuelvas a llamar el mismo prefijo en el futuro cercano. Un TTL más largo suele significar un múltiplo más alto sobre el costo de escritura, así que solo vale la pena si esperas aciertos densos y repetidos en una ventana corta; verifica los niveles reales y los múltiplos de tarifa contra la página oficial de precios vigente de tu proveedor.
P5: Además del caching, ¿qué otras formas hay de reducir el costo en tokens de un agente de IA?
La prueba encontró que filtrar explícitamente "qué necesita realmente esta tarea" antes de empezar es la ganancia más grande y consistente; en segundo lugar está dar al modelo un mapa estructural ligero para que gaste menos esfuerzo en lecturas de prueba y error. Ambas van antes del caching, porque reducen si los datos se envían siquiera — el caching solo puede optimizar qué tan barato es enviarlos.
P6: ¿Los datos de la prueba de este artículo se corrieron en Claude?
La prueba original usó las tarifas publicadas por otro proveedor de modelos (DeepSeek) en cinco corridas repetidas, específicamente para mantener la comparación centrada en las proporciones de costo relativo entre distintas estrategias de contexto, en lugar de en las cifras absolutas de ningún proveedor en particular. El video explica por separado cómo funciona en general el mecanismo de caché de la API de Claude (tokens de escritura/lectura de caché y niveles de TTL). La conclusión metodológica — que el valor del caching depende de la tasa de aciertos y la estabilidad del prefijo, y que filtrar primero supera a cachear primero — no es específica de ningún proveedor en particular, pero para las cifras concretas del precio oficial de Claude, verifica directamente el anuncio vigente de Anthropic.
Nota sobre la fuente
Este artículo se basa en el video *"I Tested Claude's Prompt Cache. It Cost Me More."* del canal Atef Ataya, enlace original: https://www.youtube.com/watch?v=DyzDuiwISa8. Las cifras de cambio de costo para cada estrategia de gestión de contexto discutida aquí (caching, mapas estructurales, grafos de dependencias, filtrado de datos, recuperación por demanda, etc.) provienen de la metodología de prueba y las conclusiones descritas en ese video. La prueba en sí usó las tarifas públicas de otro proveedor de modelos como línea base de comparación unificada, y el video es explícito en que el punto de la comparación son las proporciones de costo entre estrategias, no una cifra absoluta de ningún proveedor. Donde esto toca específicamente la mecánica de caché de la API de Claude (niveles de TTL, múltiplos de tarifa), los lectores deben verificar de forma independiente contra la documentación oficial de precios vigente de Anthropic para obtener cifras precisas y actualizadas.
Para seguir leyendo
La factura de IA que lo asustó resultó ser un espejo
¿Quieres tener un control más claro del costo de tus tokens de IA?
Ya sea que estés decidiendo si vale la pena activar el prompt caching, o simplemente quieras saber cuántos tokens está quemando tu flujo de trabajo con agentes cada mes, AI Token King junta los datos de uso y costo dispersos entre distintos proveedores de modelos en un solo panel que realmente puedes leer y seguir.
