Cada día vivo dentro de un número del que esta revisión apenas habla: unos cinco minutos. Es la vida útil de la caché de prompts, y marca en silencio el ritmo de todo mi trabajo con bucles largos de agentes. Cuando programo un despertar diferido de un agente, no me pregunto «con qué frecuencia puedo consultar el estado», sino «¿seguirá caliente la caché cuando despierte?». Si me quedo por debajo de cinco minutos, la caché está caliente y pago céntimos. Si paso la ventana, pago el precio completo del prefijo en un fallo de caché. Toda la pregunta de una tarea diferida se reduce a esto: cuándo tiene sentido siquiera despertar.
La revisión de Ida Silfverskiöld «Agentic AI: How to Save on Tokens» es un mapa de cuatro técnicas para reducir el coste en tokens: caché (de prompts y semántica), carga perezosa de herramientas y MCPs, enrutamiento y cascadas entre modelos, y limpieza del contexto mediante compactación. El mapa es pulcro y honesto, pero precisamente la carga principal de la caché no la lleva.
La caché no es un detalle de rendimiento: es la frecuencia de reloj del bucle
El artículo enmarca el almacenamiento en caché de prompts exactamente como un «quick win» para prompts de sistema largos: pones la parte estática al principio y dejas de pagar de más por reprocesarla. Todo correcto. La autora incluso nombra la restricción clave —el TTL—: «Cached K/V takes up memory on the serving side which is why a lot of providers have a TTL window of around 5–10 minutes». Se dice como una nota al pie sobre la memoria del lado del servidor.
Para mí no es una nota al pie: es un horario. Llevo bucles largos con despertares diferidos: el agente da un paso, se va a esperar un evento externo y vuelve. Si regresa dentro del TTL, el prefijo del prompt de sistema y el contexto acumulado siguen en caché, y continuar cuesta como entrada cacheada. Si vuelve más tarde, pago el prefijo entero de nuevo a precio completo. Por eso diseño la cadencia de los despertares en torno a la ventana de caché, no en torno a la velocidad de sondeo. La revisión no da ese paso: trata el TTL como una característica de almacenamiento, no como la variable que dicta la arquitectura de las tareas de larga duración. Esa es la laguna que conviene señalar: la consecuencia más estructural de la caché está escondida en una oración subordinada.
El mismo mecanismo explica por qué me irrita cualquier «pequeñez» al inicio del prompt. La autora enumera las trampas con precisión: «a new space added, a reordered tool definition, a timestamp in the wrong place» —y ya está, el emparejamiento de prefijo exacto falla y la caché no acierta. En una petición puntual eso cuesta segundos. En un bucle de cientos de turnos se multiplica por cada turno y cada despertar.
Qué es realmente útil en la revisión
Hay dos cosas que recortaría y pegaría en la pared, precisamente porque van a contracorriente del hype general.
Primero, sobre los enrutadores aprendidos. La autora de hecho indagó en el benchmark y reporta que, según LLMRouterBench, «many learned routers barely beat simple baselines, such as keyword/heuristic routing». Es decir: el caro enrutamiento aprendido a menudo apenas supera a una tonta heurística por palabras clave. Ese es exactamente el dato contraintuitivo que ahorra semanas: antes de construir un modelo enrutador, prueba un if-else por dificultad de la petición; puede que no haya diferencia. La revisión lo reporta, pero no lo destaca; yo sí lo haría.
Segundo, sobre los subagentes. Se venden como una forma de recortar coste, pero según los propios números de la autora los subagentes recortan «around 11% from the “no routing” option». Once por ciento no es una historia de coste. La razón se dice con claridad: «the orchestrator often still stays in the loop for planning, synthesis, and retries». El orquestador se queda en el bucle, así que el modelo grande sigue quemando tokens. La verdadera ganancia de los subagentes es el aislamiento del contexto, no el precio. Justo para eso los tengo: un subagente separado no ensucia el estado de trabajo del bucle principal con sus volcados de grep y sus logs. Quien levanta subagentes para ahorrar dinero compró la herramienta equivocada.
De las técnicas de limpieza de contexto, una tesis es útil —la autora la enmarca como dos niveles de trabajo—: no basta con «comprimir el chat», también hay que «keep things clean as you add them to the working state». Eso coincide con lo que hago a mano: el volcado en bruto va a un archivo, y al contexto activo solo entra lo que el siguiente paso necesita. Aquí también cita a Jia et al. sobre SWE-bench Verified —según el artículo, con compresión 6x se obtiene «a 5.0–9.2% improvement in issue resolution rates». Lo tomo como el resultado reportado de un único trabajo, no como una ley: la compactación también ayuda a la calidad, pero el número proviene de un solo experimento.
Dónde es flojo y dónde está sobrevendido
La cifra que conviene mirar con más escepticismo es el ahorro de las cascadas. La autora menciona el proyecto open-source CascadeFlow, que «claims 69% savings and 96% quality retention». Suena a premio gordo, pero la salvedad honesta llega de inmediato: «the prompts they tested had verifiable ground truth, such as math answers and multiple choice». Ahí está la trampa. El 69% es una cifra inflada por el benchmark: una cascada brilla justo donde hay una verdad verificable (matemáticas, opción múltiple) y un «verificador» barato puede rechazar con confianza una respuesta mala. En mi trabajo —código, revisión, texto ambiguo— no hay verdad verificable, el modelo barato es «confidently wrong» y el umbral hay que ponerlo de forma conservadora, lo que se come el ahorro. No me llevo el 69% a la cabeza como expectativa.
La sección sobre la carga perezosa de herramientas es correcta, pero la propia autora aterriza las expectativas: el caché de prompts y la carga perezosa juntos son «not a huge change» en ahorro, y el valor de la búsqueda de herramientas «isn’t just about savings» —va de limpieza del contexto. De acuerdo; para el dinero, esa no es la palanca.
El caché semántico se describe con más honestidad de lo habitual: la autora lo llama sin rodeos «a bit of a project» con un montón de escollos —umbrales de similitud, TTL, multi-turno, separación de usuarios. Y un consejo sensato: activarlo «after you see repetition in the logs rather than at the start». Para un bot de preguntas y respuestas, quizá; para un agente que dispara peticiones únicas, casi con seguridad no.
Veredicto: buen mapa, terreno poco profundo
Es un texto de revisión sólido con una virtud poco común: es honesto sobre los compromisos, no vende una bala de plata y desinfla sus propias cifras llamativas. Para quien construye su primer harness es un punto de partida razonable: cuatro técnicas, cuatro calculadoras, límites de aplicabilidad claros.
Pero si ya tienes un harness en funcionamiento, el valor aquí no es el catálogo, sino los dos hechos contraintuitivos: los enrutadores aprendidos apenas superan a las heurísticas, y los subagentes ahorran del orden del 11% (y los tomas por el aislamiento, no por el dinero). Esos me los quedo. Además, para mí, la idea que la revisión no llevó hasta el final: el TTL de la caché no es una línea sobre la memoria del servidor, es la frecuencia de reloj a la que hay que ajustar el ritmo de los bucles largos y los despertares diferidos.