Hace unos meses, mientras optimizaba un agente de inteligencia artificial para análisis de negocio, me tropecé con una de esas optimizaciones que parecen demasiado buenas para ser verdad. Bastaba con añadir cuatro líneas de código para reducir el coste de las llamadas a la API de Claude en un 57%. No cambié el modelo, no toqué el prompt de sistema, no reescribí la lógica del agente. Solo añadí un marcador de cache. Lo que sigue es mi experiencia real, los números que obtuve y las lecciones que aprendí sobre cuándo esta técnica funciona y cuándo no.
El contexto es un asistente BI conversacional que permite a analistas preguntar en lenguaje natural sobre un almacén de datos minorista. El prompt de sistema contiene toda la descripción del esquema: tablas, relaciones, tipos, ejemplos. Ocupa unos 1.800 tokens. En cada turno de conversación, el agente necesita ese contexto para generar SQL correcto. El problema es que, en un flujo típico de preguntas y respuestas, ese mismo texto se envía una y otra vez. Cada llamada a la API paga por procesar esos tokens de entrada como si fueran nuevos. A escala, eso dispara los costes sin aportar valor adicional.
La solución técnica que encontré es el prompt caching que ofrece Anthropic. La idea es simple: marcas un bloque de texto como cacheable y la API lo almacena durante unos minutos. En la primera petición pagas un pequeño sobrecoste por escribirlo en cache. En las siguientes, solo pagas una décima parte del coste de entrada normal. En mi agente, el prefijo cacheable incluía la descripción del esquema, las definiciones de herramientas y el preámbulo de instrucciones fijas. Todo lo que cambiaba entre preguntas (la consulta del usuario) iba después del marcador, en el mensaje del usuario.
Los resultados hablan por sí solos. Ejecuté las mismas 15 preguntas dos veces, con y sin cache. Sin cache: 32 llamadas a la API, 0,1906 $ de coste total, 82,8 segundos de latencia acumulada. Con cache: exactamente las mismas 32 llamadas (la misma longitud de conversación), 0,0824 $ de coste y 70,9 segundos de latencia. Una reducción del 57% en coste y del 14% en latencia. Todo por cuatro líneas de código. El contador de tokens lo explicaba: 1804 tokens de prefijo se escribieron una vez y se leyeron en las 31 llamadas restantes. Ningún fallo parcial, porque el prefijo nunca cambió.
La mecánica del cache se basa en una coincidencia exacta de prefijo. La API hashea los bytes de la petición hasta el marcador. Cualquier diferencia, por pequeña que sea, invalida todo el bloque. Esto significa que no puedes interpolar fechas, IDs de usuario o cualquier contenido volátil antes del marcador. Si necesitas contexto por petición, debe ir después, en el mensaje del usuario. Además, el orden de renderizado de Anthropic (herramientas antes que sistema antes que mensajes) hace que un solo marcador al final del prompt de sistema también cachee las definiciones de herramientas. No hace falta un segundo marcador.
Una sorpresa fue el tamaño mínimo necesario. Anthropic documenta umbrales por modelo, generalmente entre 1024 y 4096 tokens. Mi prefijo de 1804 tokens funcionó, pero si tu prompt de sistema es más corto, el marcador no hace nada. La única forma de saberlo es revisar los campos cache_creation_input_tokens y cache_read_input_tokens en la respuesta de la API. No asumas que por tener marcador ya estás ahorrando.
La implementación real es sencilla. Donde antes pasabas el prompt de sistema como un string, ahora lo envuelves en un array con un bloque de texto y el marcador cache_control. Por ejemplo: system: [{ type: 'text', text: systemPromptText, cache_control: { type: 'ephemeral' } }]. Eso es todo. Pero hay trampas sutiles. La primera: el cálculo de costes. La API devuelve input_tokens sin incluir los tokens cacheados. Si tu función de coste solo multiplica input_tokens por el precio base, estás ignorando tanto el ahorro como el sobrecoste de escritura. Hay que añadir manualmente los multiplicadores: 1,25x para escritura y 0,1x para lectura. Si no lo haces, los números no cuadran.
La segunda trampa: la ventana de tiempo de vida del cache es de cinco minutos por defecto. Si tu agente recibe una pregunta cada veinte minutos, el cache se enfría entre peticiones y pagarás el sobrecoste de escritura casi siempre sin llegar a leerlo. Anthropic ofrece un TTL de una hora con doble coste de escritura, pero solo compensa si el volumen de lecturas es alto. Para mi prueba secuencial de 15 preguntas, el TTL de cinco minutos fue suficiente, pero en producción hay que monitorizar la frecuencia de tráfico.
¿Dónde no sirve este enfoque? Si el prompt de sistema es corto (por ejemplo, menos de mil tokens), si el tráfico es demasiado espaciado, o si el contenido del sistema cambia en cada turno (porque entonces el prefijo ya no es estable). Tampoco funciona si las herramientas se modifican dinámicamente. En esos casos, el cache se invalida constantemente y solo pagas sobrecoste sin beneficio.
La moraleja es que una optimización aparentemente trivial puede tener un impacto enorme, pero solo si se dan las condiciones adecuadas. En Q2BSTUDIO trabajamos a diario con soluciones de Business Intelligence y agentes de IA para empresas. Sabemos que cada céntimo y cada milisegundo cuentan cuando escalas un asistente conversacional a cientos de usuarios. Por eso aplicamos técnicas como el prompt caching, siempre validando con datos reales de producción, nunca confiando solo en la teoría.
Si estás desarrollando un agente con un prompt de sistema grande y estático, te recomiendo que hagas la prueba: activa el cache, ejecuta unas cuantas preguntas y revisa los tokens de cache en la respuesta. Si ves que cache_read_input_tokens empieza a crecer mientras cache_creation_input_tokens se mantiene plano, enhorabuena: has encontrado un ahorro del 50-60% con apenas cuatro líneas. Si no, no pasa nada: revertir el cambio es igual de rápido. El experimento te llevará menos tiempo que leer este artículo.
En Q2BSTUDIO desarrollamos aplicaciones a medida, integramos inteligencia artificial, aseguramos la ciberseguridad de tus sistemas y desplegamos en cloud AWS o Azure. Si tu equipo necesita optimizar un agente de IA o construir una solución de BI desde cero, podemos ayudarte a medir el impacto real de cada optimización, desde el prompt caching hasta la elección del modelo más rentable. Porque, al final, el verdadero ahorro no está en copiar recetas de blogs, sino en probar con tu propio código y tus propios datos.
