142.000 tokens por turno, 98,99% en cache: cómo diseñamos el agente más barato del mercado

Cada vez que nuestro agente piensa, lee unos 142.000 tokens. Es el tamaño de una novela corta por turno. A precio de lista de cualquier modelo frontera —10 dólares por millón de tokens de entrada— ese único turno debería costar más de un dólar. Y sin embargo, treinta días de operación continua, con 12.471 peticiones encima, caben en $26,43. Menos de tres centavos por hora de trabajo real.

No hay magia ni descuentos especiales. Hay un número: 98,99%. Esa es la fracción del contexto que se lee desde cache en cada turno. Y ese número, que parece un detalle de ingeniería, es en realidad un récord. El sistema de agentes más avanzado del mercado público —Claude Code, de Anthropic— sostiene alrededor de un 92% de cache-hit. El grueso de la industria vive entre el 7% y el 46%. Nosotros estamos por encima del líder documentado.

Pero el récord no es la historia. El récord es el síntoma. Lo que lo produce es una decisión de arquitectura que casi nadie trata como tal: nuestra memoria. Porque un 98,99% de cache-hit no se programa ni se tunea. Se diseña — y solo es posible si el sistema tiene memoria.

1. El tablero completo: dónde queda el 98,99%

Empecemos por ubicar el número. Cuando un agente conversa con un modelo, la mayoría de los tokens que envía ya los envió antes: son contexto que no cambió. Si el proveedor los guarda en cache y tú los reutilizas, los cobra a una fracción del precio. Si no, los cobra completos. El cache-hit es la proporción de tu input que cae en el primer caso. Es, en la práctica, la métrica que decide tu factura, y casi nadie la mide.

Estos son los números documentados del mercado (abril-septiembre 2026), contra el nuestro, medido sobre la factura real de un mes:

Sistema	Cache-hit	Fuente
Nuestro harness (Shiva)	98,99%	✅ Factura auditada (30 días)
Claude Code (Anthropic)	~92%	Reporte de industria, abr-2026
OpenCode	89%	Mismo reporte
Gateway Anthropic-direct	77%	Mismo reporte
Bedrock (Claude)	57%	Mismo reporte
Kilo Code	46%	Mismo reporte
Vertex (Claude / Gemini)	24% / 10%	Mismo reporte
Promedio agentes reales en producción	7% – 80%	Estudio sobre 500+ sesiones, ene-2026

Hay tres frases que conviene tener a mano, porque provienen de equipos que viven de esto: "una aplicación de agentes sana aterriza entre 60% y 90%"; hay un agente de seguridad en producción corriendo al 7% mientras su panel decía "caching: on"; y los equipos que optimizan cache celebran pasar del 7% al 74%. O sea: la mayor parte del mercado ni se acerca al techo — y nosotros estamos arriba del techo.

Y el detalle que da contexto a todo: Anthropic construyó Claude Code alrededor de la preservación de cache. Es una decisión de producto explícita —tanto que su equipo declara incidentes de severidad alta cuando el cache-hit se degrada—. Que la ley que rige al agente insignia del mejor laboratorio de agentes sea "el prefijo estable es sagrado" no es casualidad: es la misma ley que descubrimos, con nuestras manos, corriendo un agente en un servidor propio. Y nuestro número, medido, es más alto.

La honestidad, antes de que la diga otro: esto no es manzanas con manzanas, y conviene decirlo primero. Claude Code hace un trabajo más difícil de cachear: explora repositorios, escribe y edita archivos, su contexto es volátil por naturaleza. Nuestro agente es memory-heavy: arrastra un prefijo grande y estable. Un cache-hit alto es, en parte, consecuencia de nuestra arquitectura —que es justamente el mérito— pero no equivale automáticamente a "mejor sistema" en cualquier tarea. Y hay una segunda trampa: el cache-hit, aislado, es parcialmente "gameable" —basta con cargar un prefijo estático enorme y el número sube solo—. Por eso el dato que importa no es el porcentaje por sí mismo. Es la combinación: 98,99% de hit + 142.000 tokens de memoria real por turno + trabajo de verdad entregado (12.471 peticiones, cuatro roles). En esa combinación, en el registro público, no encontramos a nadie.

2. La memoria no es una feature: es una estructura de costo

Llegamos al corazón del asunto, y es una idea que conviene decir sin rodeos: en un agente, la memoria no es una función que agrega capacidad. Es una decisión que fija el costo.

La intuición popular dice lo contrario. Dice que la memoria "enriquece" al agente, que le da continuidad, que lo hace más útil. Todo eso es cierto y es secundario. Lo decisivo es otra cosa: la memoria es lo que permite que el contexto grande viva del lado barato de la frontera del cache. Sin memoria, cada turno arranca de cero, y un agente que arranca de cero repaga todo su contexto a precio completo. Con memoria, el contexto se estabiliza, entra a cache, y se relee a una fracción del costo.

Desarmémoslo en la cadena causal, porque cada eslabón es verificable sobre los datos:

1. Hay memoria persistente (sesiones acumuladas, grafo de conocimiento, skills). Eso hace que el agente sepa cosas que, sin ella, tendría que re-descubrir en el turno.
2. Esa memoria se ordena en un prefijo estable. Lo que cambia poco va primero; lo que cambia siempre (el mensaje del usuario, los resultados de herramientas) va al final.
3. El prefijo estable entra a cache y se mantiene byte-idéntico turno a turno. El proveedor lo reconoce y lo cobra barato.
4. El cache-hit se dispara —98,99%— y, con él, colapsa el costo por token.

Ninguno de esos cuatro pasos requiere un modelo más barato, más chico ni más nuevo. Todos dependen de cómo está armado el sistema. De ahí la conclusión que separa a un harness de un simple wrapper:

Y aquí está el giro que le da sentido a todo el artículo: si la memoria decide el costo, entonces la pregunta "¿cuánto cuesta tu agente?" no se responde mirando el precio del modelo. Se responde mirando dónde vive el contexto. Dos equipos con el mismo modelo, el mismo proveedor y el mismo tipo de tarea pueden tener facturas que difieren en un orden de magnitud — y la diferencia no será el modelo. Será si uno tiene memoria con prefijo estable y el otro no.

3. Cómo lo diseñamos: la represa del prefijo estable

Si la memoria es la que decide, entonces el trabajo de ingeniería real no está en elegir el modelo: está en ordenar el contexto para que nada frágil viva aguas arriba. La imagen que mejor lo describe es una represa.

Qué vive aguas arriba (el sustrato)

Nuestro prefijo estable se compone de cuatro bloques, siempre en el mismo orden y con la misma forma byte a byte:

• El system prompt — fijo, sin fechas ni timestamps que lo hagan variar.
• Los esquemas de las herramientas — serializados de forma determinista (mismo contenido, mismo hash, siempre).
• El catálogo de skills — nombres y descripciones, no el contenido completo. Es divulgación progresiva: el agente sabe qué skills existen sin cargar su interior.
• La memoria de sesión acumulada — el historial crece hacia abajo, nunca se reconstruye.

Qué vive aguas abajo (lo que paga precio completo)

Y aquí está la corrección más importante, porque desarma un mito. Mucha gente cree que la eficiencia viene de "cargar poca memoria". Falso: nosotros leemos 139.865 tokens de cache por petición. Es un contexto gigantesco. No hay nada minimalista en él. Lo que es pequeño es lo nuevo:

Por petición	Tokens	Qué es
Cache read (el sustrato)	139.865	System prompt + herramientas + catálogo de skills + memoria acumulada
Cache miss (material nuevo)	1.430	Lo que escribe el usuario, los resultados de herramientas, lo que se carga on-demand
Output (el trabajo real)	921	Respuesta, razonamiento, llamadas a herramientas

La proporción es de 98 tokens baratos por cada token caro. El material genuinamente nuevo de cada turno es el 1,01% de todo el input. Ese —no el tamaño del contexto— es el número que decide la factura.

El acceso on-demand: pagar precio completo una sola vez

Otra creencia muy difundida dice que "acceder a la memoria on-demand es lo que abarata". Es verdad a medias, y la mitad que falta es la más elegante. Cuando el agente carga una skill o consulta la memoria, ese contenido no se relee en cada turno: entra al contexto, pasa a formar parte del sustrato, y desde el segundo turno ya se lee desde cache. El acceso on-demand no significa "cargar poco". Significa "pagar precio completo una vez, y después leerlo barato para siempre".

Y las causas por las que la represa de otros harnesses se rompe son siempre las mismas, y son tontas:

• Un timestamp o una fecha dentro del system prompt → el prefijo cambia en cada turno → cache invalidado.
• Orden no determinista al serializar herramientas o catálogo → mismo contenido, distinto hash.
• Re-render del historial completo en lugar de agregar al final.
• RAG que inyecta los fragmentos antes del bloque estático, en vez de después.
• Multi-agente que arma un system prompt nuevo por sub-agente — y encima los hace conversar, multiplicando turnos.

Cada uno de esos rompe la identidad byte a byte del prefijo y tira todo el contexto a precio de input completo. La prueba de que nosotros no caemos en ninguno es un experimento de control que corrimos sin proponérnoslo: en el mismo periodo, con el mismo modelo y la misma infraestructura, otra de nuestras claves de API —un agente auxiliar que hace llamadas sueltas, sin prefijo estable— muestra lo que pasa cuando el diseño falla:

Clave	Peticiones	Cache-hit	Tokens/petición	Costo por millón
Shiva (prefijo estable)	12.205	99,07%	145.184	$0,0143
Overseer (sin prefijo estable)	257	0,00%	5.929	$0,3253

Léelo despacio, porque es un experimento controlado: Shiva mueve 24,5 veces el contexto por petición, a 1,10 veces el costo por petición. Es decir, 22,7 veces más barato por token, con el mismo modelo, el mismo proveedor y el mismo mes. Y ojo con la trampa: si midieras "costo por petición" concluirías que son casi iguales. El costo por petición esconde toda la historia; el costo por token la cuenta.

La conclusión, entonces, es esta: no cargamos menos memoria. Cargamos mucha memoria, del lado barato de la frontera.

4. El impacto real en producción

Todo lo anterior suena bien en teoría. El problema es que nadie opera en teoría. Así que veamos qué significa el 98,99% cuando el sistema lleva un mes corriendo sin apagarse:

Lo que hizo el agente (18-ago → 16-sep)	Valor
Peticiones al modelo	12.471 (≈ 416/día · una cada 3,5 min, 24/7)
Tokens leídos por turno	~142.000 de memoria real
Cache-hit sostenido	98,99%
Costo total del mes	$26,43
Costo diario	$0,88
Costo por millón de tokens	$0,0149 (≈ 67 millones de tokens por dólar)
Contrafactual sin cache (mismo contexto)	$567,09 → 21,5x más caro

Hay una consecuencia que cambia por completo lo que un agente puede permitirse recordar. Un equipo sin disciplina de cache tiene que elegir entre contexto grande (caro) o contexto chico (barato pero pobre). Nosotros rompimos esa disyuntiva: arrastramos 142.000 tokens de memoria en cada turno y pagamos como si fuera un agente minimalista. Eso no es eficiencia decorativa — es la diferencia entre un agente que recuerda de verdad y uno que finge recordar para no quemar la factura.

Y la operación no es un solo modelo: es una orquestación de roles, cada uno con su propio costo, facturado por separado. En el mismo mes:

Rol	Peticiones	Costo
Shiva (agente principal)	12.205	$25,92
Overseer (supervisión)	257	$0,50
Morfeo (tareas específicas)	8	$0,013
Trinity	1	$0,0001
TOTAL		$26,43

Cuatro roles trabajando en paralelo, con contextos y responsabilidades distintas, caben en menos de un dólar al día. Proyectado a doce meses, la operación corre del orden de $177 al año. Si el prefijo se rompiera en cada turno, esa misma operación costaría $3.254. Esa diferencia —$3.000 al año— no la produce un cambio de modelo. La produce no romper la represa.

El bono estratégico: ser agnóstico al modelo

Y hay una ventaja que no aparece en ninguna factura. Como el costo lo decide el harness y no el modelo, cambiar de modelo cuesta casi nada. El modelo es un componente intercambiable; la capa que decide el costo —la memoria, el prefijo, el presupuesto de contexto— es nuestra y no se toca. En un mercado donde los modelos se commoditizan cada trimestre, eso significa que podemos saltar al que esté mejor o más barato sin reescribir la operación. El activo no es el modelo. Es el sistema que lo rodea.

5. El riesgo del que dependemos (y el guardrail que lo cubre)

Sería deshonesto terminar sin la otra cara. Todo este edificio descansa sobre un supuesto silencioso: que el prefijo sea byte-idéntico entre turnos. Eso nos apalanca. Y todo apalancamiento es, por definición, un riesgo.

La magnitud del riesgo es esta: estamos apalancados aproximadamente 21x al byte-identidad del prefijo. Un solo datetime.now() escondido en el system prompt —o un catálogo de herramientas que se serializa en orden variable— cambiaría el prefijo en cada turno y multiplicaría la factura por dieciocho… sin tirar un solo error. El sistema funcionaría igual. Los logs se verían iguales. El dashboard diría "caching: on". Y la cuenta aparecería, inflada, recién al mes siguiente. Es el tipo de falla silenciosa que se descubre mirando la factura, no el código.

Y la segunda cara honesta: nadie controla los diales del proveedor. El descuento del cache-read, la ventana de persistencia, el costo de escritura: todo eso lo fija el proveedor, y lo cambia cuando quiere. Nuestros propios datos muestran que el cache-read se abarató un 79% durante el mes auditado —sin que tocáramos nada—. Es una buena noticia que llega sin pedirla, y es también el recordatorio de que la soberanía de cache es soberanía de costo: mientras la represa esté en tu código, tienes la sartén; pero los precios pueden moverse sin avisarte.

Cierre: el número que ningún proveedor te va a vender

Resumamos lo que descubrimos, porque es más profundo que un porcentaje:

El 98,99% de cache-hit no es una optimización de ingeniería. Es la prueba financiera de una decisión de arquitectura: tener memoria, y ordenarla para que viva del lado barato de la frontera. La cadena se sostiene sola: memoria → prefijo estable → cache-hit alto → colapso de costo. Cada eslabón es medible, y el último es la factura.

Y por eso la conclusión incómoda cierra el círculo con todo lo que venimos escribiendo: un proveedor metrado por token no tiene incentivo en venderte el sistema que reduce sus tokens. La inteligencia se produce en el canal de output —caro y no cacheable—; la memoria que la reemplaza por lecturas de cache baratas es, punto por punto, lo que baja su factura. No es maldad: es estructura. Y la respuesta a una estructura no es buena voluntad: es construir la capa tú mismo.

Esa capa —memoria, prefijo, presupuesto de contexto, libertad de cambiar de modelo— tiene que ser tuya. No por privacidad, que es el argumento que todos dan, sino porque es lo único que no te van a vender. Y cuando la construyes bien, el resultado es medible: 142.000 tokens por turno, 98,99% en cache, $26 al mes. Un agente que recuerda de verdad, corriendo por el precio de un café diario.