Un caso de estudio sobre cómo Claude logra un 92 % de tasa de acierto en caché
Cada vez que un agente de IA da un paso, paga un impuesto.
Vuelve a leer todo desde cero.
Las instrucciones del sistema. Las definiciones de herramientas. El contexto del proyecto que ya cargó hace tres turnos. Todo. En cada turno.
Ese es el impuesto de contexto. Y para flujos de trabajo agentivos de larga duración, suele ser la partida más costosa de toda tu infraestructura de IA.
Aquí están los números: un prompt de sistema con 20 000 tokens ejecutándose durante 50 turnos significa 1 millón de tokens de cómputo redundante facturados a precio completo, produciendo cero valor nuevo.
La solución es el caché de prompts. Pero para usarlo bien, necesitas entender qué sucede realmente bajo el capó.
Empieza con lo que cambia y lo que no cambia
Antes de optimizar algo, debes pensar claramente en la estructura del prompt (contexto) de un agente.
Cada solicitud que envía tu agente tiene dos partes fundamentalmente diferentes:
El prefijo estático: incluye instrucciones del sistema, definiciones de herramientas, contexto del proyecto, pautas de comportamiento. Este contenido es idéntico en cada turno de una sesión.
La cola dinámica: mensajes del usuario, salidas de herramientas, observaciones del terminal. Esto es único para cada solicitud y crece a medida que avanza la conversación.
Esta distinción lo es todo. El prefijo estático es la parte costosa que vuelves a calcular sin razón. La cola dinámica es la única parte que realmente necesita cómputo nuevo.
El caché de prompts funciona almacenando el estado matemático del prefijo estático para que las solicitudes futuras puedan omitir por completo su recálculo. Pagas por procesar ese prefijo una vez. Cada turno posterior lo lee desde la memoria.
Por qué funciona esto: lo que realmente hace un Transformer
Para entender realmente por qué el caché es tan efectivo, necesitas entender qué sucede dentro del modelo cuando lee tu prompt.
Cada solicitud de inferencia de LLM tiene dos fases:
Fase 1: Prefill (prellenado)
Aquí el modelo procesa tu prompt de entrada completo. Está limitado por cómputo, lo que significa que ejecuta multiplicaciones densas de matrices en cada token de tu contexto. El modelo lee todo y construye una representación. Esta es la fase lenta y costosa.
Fase 2: Decode (decodificación)
Aquí el modelo genera tokens de salida, uno a la vez. Está limitado por memoria, no por cómputo, porque el modelo pasa la mayor parte del tiempo leyendo estado previamente calculado en lugar de ejecutar cálculos pesados.
Durante la fase de prefill, el transformer construye tres vectores para cada token: una Consulta (Query), una Clave (Key) y un Valor (Value). El mecanismo de atención usa estos para determinar cómo se relaciona cada token con todos los demás en la secuencia.
Aquí está la idea crítica: los vectores Clave y Valor dependen solo de los tokens que vinieron antes. Una vez calculados para un prefijo dado, nunca necesitan cambiar.
La ilustración a continuación explica visualmente lo que acabamos de discutir:
Sin caché, esos tensores Clave-Valor se descartan en cuanto se completa una solicitud. La siguiente solicitud empieza desde cero y los recalcula para los 20 000 tokens nuevamente.
El caché KV resuelve esto almacenando esos tensores. La infraestructura los mantiene en los servidores de inferencia, indexados por un hash criptográfico del texto de entrada. Cuando llega una nueva solicitud con el mismo prefijo, el hash coincide, los tensores se recuperan de inmediato y el modelo se salta todo ese cómputo.
Esto reduce la complejidad computacional de O(n²) por token generado a O(n). Para un prefijo de 20 000 tokens repetido en 50 turnos, es una reducción enorme.
La economía
Entender la estructura de precios es lo que hace que esta decisión arquitectónica sea tan impactante.
Así es como Anthropic tarifica el caché en sus familias de modelos:
Tres números para internalizar:
- Las lecturas de caché cuestan el 10 % del precio base de entrada, un 90 % de descuento en cada token leído desde caché
- Las escrituras de caché cuestan un 25 % más que el precio base de entrada, una pequeña prima por almacenar los tensores KV
- El caché extendido de 1 hora cuesta 2 veces el precio base
Las matemáticas solo funcionan si tu tasa de aciertos de caché se mantiene alta. Lo que nos lleva al mejor ejemplo real de cómo se ve eso en la práctica.
Claude Code: Un recorrido por una sesión de 30 minutos
Claude Code está construido enteramente en torno a un objetivo: mantener el caché caliente.
Para entender qué significa eso concretamente, veamos cómo se ve una sesión típica de codificación de 30 minutos y rastreemos exactamente qué se factura y qué no.
Minuto 0: Inicio de sesión
Claude Code carga su prompt de sistema y definiciones de herramientas. También lee el archivo CLAUDE.md en la raíz de tu proyecto, que describe el código y las convenciones. Esta carga útil supera regularmente los 20 000 tokens.
Este es el momento más costoso de toda la sesión. Cada token es nuevo. Pero solo pagas este costo una vez.
Minutos 1 a 5: Primeros comandos
Escribes tu primera instrucción, algo como "mira el módulo de autenticación y sugiere mejoras".
Claude Code envía un Subagente de Exploración. Navega por el código, abre archivos, ejecuta comandos grep y construye una imagen del código relevante. Todo esto se agrega a la cola dinámica.
¿La base estática de 20 000 tokens? Ya está en caché. Se lee a $0.30/MTok en lugar de $3.00/MTok. Solo pagas por las nuevas salidas de herramientas y tu mensaje.
Minutos 6 a 15: Trabajo profundo
El Subagente de Planificación recibe los hallazgos del Subagente de Exploración. En lugar de pasar los resultados sin procesar textualmente (lo que inflaría innecesariamente la cola dinámica), Claude Code pasa un resumen conciso. Esto mantiene el sufijo manejable y el caché eficiente.
El planificador produce un plan de implementación estructurado. Lo revisas, lo apruebas y Claude Code comienza a hacer cambios. Cada turno en este bucle lee el prefijo de 20 000 tokens desde caché. Cada acierto de caché reinicia el TTL, manteniendo el caché caliente para turnos futuros.
Minutos 16 a 25: Iteración
Pides ajustes. Claude Code revisa su enfoque. Más llamadas a herramientas, más salidas de terminal. La cola dinámica está creciendo, pero representa solo el contenido nuevo y único de esta sesión.
En este punto, la sesión ha procesado cientos de miles de tokens en total. Pero la base de 20 000 tokens se ha leído desde caché en cada turno.
Minuto 28: Ejecutar /cost
Sin caché, una sesión como esta fácilmente supera los 2 millones de tokens. A las tarifas de Sonnet 4.5, eso es alrededor de $6.00.
Con el caché funcionando a alta eficiencia:
- La gran mayoría de los tokens se leen desde caché a $0.30/MTok
- Solo los tokens nuevos de la cola dinámica se computan desde cero
En la práctica, esperarías una reducción de costos del 80 % o más en una sola tarea. Ahora multiplica eso por cada usuario, cada día.
Para resumir, así es como se ve el diseño del prompt del sistema a medida que avanza la sesión:
La regla que lo rompe todo
Esto es lo más contraintuitivo del caché de prompts.
1 + 2 = 3. Pero 2 + 1 es un fallo de caché.
La infraestructura hashea el prompt. El hash es un identificador criptográfico. El hash cambia si algo en ese orden cambia, incluso si dos elementos están en un orden diferente. El caché está vacío. Todo el prefijo se recalcula a precio completo.
Tres reglas que se derivan de esto:
- No agregues ni quites herramientas durante una sesión. El prefijo en caché incluye herramientas. Cambiar las herramientas hace que todo lo que viene después sea inútil.
- Nunca cambies de modelo a mitad de sesión. Los cachés son específicos del modelo. Cambiar a un modelo más barato a mitad de conversación requiere reconstruir todo el caché.
- Nunca cambies el prefijo para cambiar el estado. En su lugar, Claude Code agrega una etiqueta al siguiente mensaje del usuario que recuerda al sistema. El prefijo nunca cambia.
Lo que significa para ti
Todo lo anterior explica cómo Claude Code maneja el caché. Las mismas reglas aplican si estás creando tu propio agente.
Así es como debes estructurar tus prompts:
- Arriba, las instrucciones y reglas del sistema. No cambies a mitad.
- Carga todas las herramientas que necesitarás de antemano. No las agregues ni quites.
- Contexto y documentos recuperados después. Estáticos durante la duración.
- Al final, el historial de la conversación y las salidas de las herramientas.
Con el auto-caché activado, el punto de corte avanza automáticamente a medida que avanza la conversación.
Claude Code está a cargo de su propio caché. Anthropic acaba de agregar auto-caché a su API, para que puedas hacer lo mismo con tu propio agente.
Sin auto-caché, tenías que recordar dónde estaban los límites de tokens. Un límite incorrecto significaba no llegar al caché.
Usa bifurcación segura para caché (cache-safe forking) para compactar dentro del límite de contexto. Usa el mismo prompt de sistema, herramientas y conversación, luego agrega la compactación como un nuevo mensaje.
La llamada de compactación se ve casi exactamente igual que la anterior. El prefijo en caché se usa nuevamente. Lo único que se factura como nuevo es la instrucción de compactación.
Para verificar si una API está funcionando, mantén un ojo en estos tres campos en cada respuesta:
- cache_creation_input_tokens: tokens puestos en memoria
- cache_read_input_tokens: tokens leídos desde memoria
- input_tokens: tokens procesados normalmente
Tu puntuación de eficiencia de caché es la cantidad de tokens leídos en comparación con la cantidad de tokens creados. Vigílala de la misma manera que vigilas el tiempo de actividad.
Conclusiones clave
El caché de prompts no es una función que activas. Es una disciplina arquitectónica que construyes a su alrededor.
Claude Code es el mejor ejemplo de cómo se ve ese campo cuando se hace a gran escala.
Una tasa de aciertos de caché del 92 %. Una reducción de costos del 81 %.
Este es el plano si estás creando agentes. No puedes ignorar el impuesto; existe. Lo único que importa es si estás pagando por él o deshaciéndote de él.
