![Imagen de portada de [Contexto de IA #7] Reduce el coste de la API con la caché de prompts](/assets/images/posts/80775323-baa4-47ad-bc90-fa3cce66546c/1.jpg)
La última entrega de la serie trata sobre dinero. Si has ejecutado un agente mediante una API, probablemente hayas visto algo extraño en la factura: los tokens de entrada cuestan muchísimo más que los de salida. Al recordar la estructura de la primera entrega, resulta lógico. Cada turno reenvía todo, desde el prompt del sistema hasta el historial completo, así que una sesión de 50 turnos cobra 50 veces el mismo prompt del sistema.
La caché de prompts (prompt caching) reduce este coste repetitivo. Bien utilizada, puede reducir el coste de entrada a una décima parte y acelerar las respuestas, pero exige una condición: acumular el contexto de la forma que favorece la caché. En esta entrega veremos el principio y los errores que la destruyen sin darnos cuenta.
El mismo prefijo no se calcula de nuevo
Ya vimos la mitad del principio en la primera entrega. Al procesar la entrada, el modelo produce resultados intermedios de atención para cada token y los acumula en la memoria de la GPU como caché KV. La caché de prompts conserva esa caché KV después de terminar una solicitud y reutiliza todo el cálculo cuando la siguiente comienza con el mismo contenido.
Mira lo bien que encaja con las conversaciones de agentes. La entrada del turno 10 es «prompt del sistema + turnos 19 + mensaje nuevo»; la del turno 11 es «prompt del sistema + turnos 110 + mensaje nuevo». La parte inicial es idéntica. Con caché, el servidor recupera el resultado calculado hasta el turno 10 y solo calcula la cola recién añadida.
La facturación sigue la misma estructura. En la API de Anthropic, los tokens de entrada leídos desde la caché cuestan solo el 10% del precio normal. Escribir tokens nuevos en la caché aplica un recargo del 25%, pero se compensa pronto en el patrón de agentes que escribe una vez y lee muchas. En sesiones de cientos de turnos, la caché puede multiplicar la diferencia de coste; además, al saltarse ese tramo, reduce claramente la latencia hasta el primer token.
Una condición: el prefijo no puede cambiar ni un carácter
No existe el almuerzo gratis. La reutilización de la caché exige que coincida el prefijo. Solo se aplica al tramo idéntico y consecutivo desde el inicio de la entrada; desde el primer punto distinto, todo lo posterior se calcula de nuevo.
La primera entrega también explica el motivo. En la atención, el valor KV de cada token depende de todos los tokens anteriores. Si cambia siquiera uno de los tokens iniciales, cambian los resultados de todos los posteriores, por lo que la caché deja de servir. Por eso modificar el principio del contexto resulta tan caro.
El principio de un contexto favorable a la caché cabe en una frase: lo estable delante, lo variable detrás y el historial sin modificar, solo con anexiones (append-only).
Errores inadvertidos que destruyen la caché
El principio es sencillo, pero hay muchas formas sutiles de incumplirlo.
La primera son los valores variables dentro del prompt del sistema. Si insertas la hora actual con precisión de segundos, el inicio del contexto cambia en cada solicitud y la tasa de aciertos cae al 0%. Si debes incluirla, redúcela al nivel de fecha o colócala al final del contexto. Los ID de sesión y los valores aleatorios son trampas iguales.
La segunda es cambiar las definiciones de herramientas. El esquema suele estar al principio del contexto, así que añadir o quitar una herramienta durante la sesión invalida toda la caché posterior. En la cuarta entrega recomendé ordenar los servidores MCP; desde el punto de vista de la caché hay que añadir: hazlo antes de iniciar la sesión y no lo toques después.
La tercera es editar el historial en medio. Modificar un turno anterior o borrar turnos antiguos para ahorrar contexto rompe el prefijo y elimina la caché desde ese punto. Por ahorrar unos miles de tokens, es fácil acabar pagando el recálculo de toda la sesión. Si necesitas borrar algo del historial, suele ser mejor cerrar un bloque y vaciarlo entero.
Por último, /compact de la tercera entrega también cambia de perspectiva con la caché. Como sustituye todo el historial por un resumen nuevo, reinicia completamente la caché. A largo plazo puede compensar porque los turnos posteriores construyen una nueva caché sobre un historial más corto, pero conviene entender que «compact no es una limpieza gratuita, sino un evento con coste de reconstrucción de caché». Por eso /clear en cada bloque suele ser más barato que compactar con frecuencia.
Resumen de la serie: siete intuiciones para manejar el contexto
Repasemos, una línea cada vez, el principio común a las 7 entregas.
- La ventana de contexto es finita y su límite proviene de la física de la atención y la caché KV.
- Que quepa no significa que se use bien. La longitud por sí sola reduce la calidad.
- /clear debe ser el valor predeterminado en cada frontera de trabajo; usa /compact con instrucciones solo cuando necesites conservar el contexto.
- El prompt del sistema, CLAUDE.md y las definiciones de herramientas son costes fijos. Mantén breve solo lo que siempre sea cierto.
- Aísla en el contexto de un subagente las tareas cuyo proceso es pesado pero cuya conclusión es sencilla.
- Externaliza en archivos el conocimiento que debe sobrevivir a la sesión: archivos de plan, memoria y RAG si crece demasiado.
- El contexto debe acumularse con append-only para que la caché funcione: lo estable delante y lo variable detrás.
En una frase: el contexto no es una capacidad del modelo, sino un presupuesto que diseña el usuario. Incluso en la era de un millón de tokens, esta intuición seguirá siendo válida. Cuanto mayor sea la ventana, más diferencia de rendimiento marcará saber qué poner dentro.