Treinta días. 12.471 peticiones. 1.773.564.650 tokens. Y una factura de veintiséis dólares con cuarenta y tres centavos. Detrás de esos números: un humano, un orquestador y tres agentes auxiliares. Eso es todo el equipo.
Casi nadie publica su propia factura. Nosotros vamos a hacerlo, y la razón es simple: en la discusión más ruidosa del sector —"los harness queman tokens", "quité el harness y recuperé mis tokens", "lo caro es el modelo"— todos hablan con precios de lista y estimaciones de terceros. Nadie muestra números propios, verificados, con el CSV del proveedor al lado. Este es el nuestro: reconstruimos cada token y cada centavo desde el archivo de uso de la API, y la cifra cuadra al centavo.
Y el resultado contradice dos creencias al mismo tiempo: la de que un harness eficiente es el que carga poca memoria, y la de que el costo lo decide el modelo. Ninguna de las dos sobrevive la aritmética. Porque en el medio aparece un tercer factor que casi nadie nombra, y que resulta ser el que lo decide todo: dónde vive el contexto respecto del límite de cache.
La eficiencia de un agente no depende de cuánta memoria carga, sino de dónde vive esa memoria respecto del límite de cache. Nuestro harness lee 140.000 tokens por turno —muchísimo— y aun así cuesta centavos, porque el 99% de ese contexto se lee desde cache.
Pero hay algo más profundo, y es la razón por la que esto no te lo va a vender ningún proveedor metrado por token: la inteligencia se produce en el canal de output, y el output no se puede cachear. Nunca. Ni con la mejor ingeniería del mundo.
Por eso la conclusión incómoda: la memoria que te ahorra dinero es, por definición, la que tu proveedor no tiene incentivo en venderte. No es maldad. Es estructural.
1. La factura, verificada contra el CSV
Antes de interpretar nada: los datos. Período 18 de agosto al 16 de septiembre de 2026, 30 días, los 30 con actividad. Modelo: DeepSeek V4 Flash. La auditoría se hizo cruzando el archivo de amount (tokens por tipo y tarifa) contra el de cost (facturación):
| Métrica | Valor |
|---|---|
| Tokens totales procesados | 1.773.564.650 (1,77 mil millones) |
| · leídos desde cache (cache read) | 1.744.257.023 → 98,35% |
| · input nuevo (cache miss) | 17.828.045 → 1,01% |
| · generados (output) | 11.479.582 → 0,65% |
| Peticiones | 12.471 |
| Tokens por petición | 142.215 |
| Cache-hit sobre el input | 98,99% |
| Costo total facturado | $26,43 |
| Costo diario medio | $0,88 |
| Costo por petición | $0,002119 |
| Costo por millón de tokens | $0,0149 |
Verificación: reconstruimos el gasto desde el archivo de tokens (tokens × tarifa de cada línea) y dio $26,428879. La factura del proveedor dice $26,428879. Coincidencia exacta al séptimo decimal. No es una estimación: es la factura real, desarmada pieza por pieza.
Y puesta en perspectiva de trabajo: 416 peticiones por día —una cada tres minutos y medio, de corrido, 24/7, durante un mes entero— y del orden de 8,5 millones de palabras de output generado. Todo eso con $0,88 por día. Menos de lo que cuesta un café.
Sin cache, ese mismo mes —con exactamente el mismo contexto enviado— habría costado $567,09. Es decir: la disciplina de cache representó un ahorro de $540,66, un 95,3% menos, un factor de 21,5x. Todo el ahorro vino de cómo se envía el contexto, no de cuánto.
2. La corrección incómoda: no es que carguemos poca memoria
Aquí es donde hay que resistir la interpretación fácil. Viendo un cache-hit del 99%, la conclusión tentadora es "usan poca memoria, por eso gastan poco". Falso. Nuestro harness lee 139.865 tokens desde cache en cada petición. Es un contexto enorme: no hay nada minimalista en él.
Lo que sí es pequeño es lo nuevo:
| Por petición | Tokens | Rol |
|---|---|---|
| Cache read (el sustrato) | 139.865 | System prompt + esquemas de herramientas + catálogo de skills + memoria acumulada |
| Cache miss (material nuevo) | 1.430 | Lo que el usuario escribe, los resultados de herramientas, lo que se trae on-demand |
| Output | 921 | El trabajo real: respuesta, razonamiento, llamadas a herramientas |
Fíjate en la proporción: 98 tokens baratos por cada token caro. El material genuinamente nuevo de cada turno es el 1,01% de todo el input. Ese es el número que importa — no el tamaño del contexto.
Y lo confirmamos con dos pruebas que salieron de los propios datos:
Prueba uno — el grupo de control que ya teníamos sin saberlo. 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 mantener prefijo estable) muestra un rendimiento muy distinto:
| 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 que corrimos sin proponérnoslo: 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. Mismo modelo, mismo proveedor, mismo mes, misma infraestructura. La única diferencia es la disciplina de cache. Y ojo con la trampa: si midieras "costo por petición" ($0,00212 vs $0,00193) concluirías que son casi iguales. El costo por petición esconde toda la historia. El costo por token la cuenta.
Prueba dos — el patrón es de "agregar", no de "reconstruir". Si el prefijo se reconstruyera en cada turno, el input nuevo escalaría con el tamaño del contexto y el cache-hit se derrumbaría. No ocurre: el material nuevo escala linealmente con el tráfico (correlación 0,896 con el número de peticiones, y una variación de apenas 27% entre días). Y si el prefijo se rompiera cada vez, el miss habría sido 98 veces mayor — exactamente los 1,74 mil millones de tokens que hoy se leen barato.
El hallazgo, entonces, es este: no cargamos menos memoria. Cargamos mucha memoria, del lado barato de la frontera.
El límite de cache es una represa. Aguas arriba solo puede vivir lo que nunca cambia; todo lo dinámico va aguas abajo. La mayoría de los harnesses mete cosas dinámicas aguas arriba —un timestamp en el system prompt, un orden de herramientas no determinista, el historial completo re-renderizado— y la represa se rompe en cada turno. El nuestro no la rompe nunca. Por eso 140.000 tokens leídos cuestan menos que 921 tokens escritos.
3. El acceso on-demand: pagar precio completo una sola vez
Acá conviene corregir otra intuición muy difundida, la de 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 nuestro agente carga una skill o consulta la memoria, ese contenido no se relee cada turno. Entra al contexto, pasa a formar parte del sustrato, y desde el segundo turno ya se lee desde cache. Es decir: el acceso on-demand no significa "cargar poco". Significa "pagar precio completo una vez, y después leerlo barato para siempre".
Eso reescribe la conclusión del debate. La variable no es harness sí / harness no. Es prefijo estable + presupuesto de contexto, contra prefijo inestable sin presupuesto. Y las causas del segundo caso son siempre las mismas, y son tontas:
- Un timestamp o una fecha dentro del system prompt → cambia el prefijo en cada turno → cache invalidado.
- Orden no determinista al serializar las herramientas o el catálogo → mismo contenido, distinto hash.
- Re-render del historial completo en vez 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 entre ellos, multiplicando turnos.
Cada uno de esos rompe la identidad byte a byte del prefijo y tira todo el contexto a precio de input completo. Ahí viven los "tokens recuperados" del famoso consejo de "quita el harness": no se recuperaron tokens, se dejó de pagar 140.000 tokens a precio completo por turno. Y el remedio propuesto —borrar la capa— destruye justamente lo que abarataba la cuenta.
4. Los cinco diales que no ves
Hasta acá hablamos de lo que nosotros controlamos. Ahora la parte incómoda: hay variables que deciden tu factura y que no están en tu código. Verificadas contra la documentación pública de los proveedores (agosto-septiembre 2026):
| Dial | Nuestro proveedor (abierto) | GPT-6 Astra (cerrado) |
|---|---|---|
| 1. Descuento de cache-read | ~50x (lectura al 2% del input) | 10x ($1 por millón) |
| 2. Ventana de persistencia (TTL) | larga (disco) | no publicada |
| 3. Costo de escribir en cache | $0 (gratis) | 1,25x ($12,50 por millón) |
| 4. Acantilado de contexto | no existe | >272K repricea 2x TODO |
| 5. Esfuerzo de razonamiento | — | ajustable: más esfuerzo = más output facturado |
Fíjate que tres de los cinco son de cache y dos son de output. Ninguno es "el modelo". Y los TTL entre proveedores van de 5 minutos a 24 horas — un desajuste de TTL convierte hits esperados en misses a precio completo.
Y hay un detalle que descubrimos revisando nuestros propios datos: el cache-hit no se degrada cuando el tráfico cae (correlación +0,074 con la densidad de peticiones). Incluso el día más flojo del mes —106 peticiones, una cada 13,6 minutos— mantuvo 99,23% de hit. Es decir: dependemos silenciosamente de la ventana de persistencia de nuestro proveedor. Si estuviéramos en un proveedor con TTL de 5 minutos, esos días habrían colapsado a precio completo. Nunca lo declaramos como supuesto. Lo acabamos de descubrir auditando.
5. El acantilado de los 272K
De los cinco diales, uno merece sección propia porque no es un dial: es un precipicio. La documentación de Astra dice, con esas palabras, que las peticiones con más de 272.000 tokens de input se cobran a 2x en input y en tarifas de cache, y 1,5x en output, para toda la petición.
| Contexto enviado | Costo por petición | |
|---|---|---|
| 200.000 tokens | $0,269050 | |
| 271.000 tokens | $0,348215 | |
| 272.000 tokens | $0,349330 | |
| 273.000 tokens | $0,677865 | ← 1,95x |
| 350.000 tokens | $0,849575 |
Un 0,74% más de contexto duplica la factura completa. El costo marginal de esos 2.000 tokens extra es de 165 dólares por millón — contra $0,003 de una lectura de cache normal. En nuestra escala, cruzar ese umbral significaría +$4.111 al mes por nada: sin una sola petición extra, sin una línea de código nueva, sin un error.
Es el argumento definitivo contra el "contexto gigante por las dudas". En un proveedor con este diseño, el contexto grande no es caro: es un campo minado. Y nada te avisa cuando te estás acercando al borde.
6. El mismo trabajo, otro proveedor: $26 o $2.496
Ahora la pregunta que todo el mundo hace: ¿y si corro esto sobre el modelo frontera? Hagamos la cuenta con precios verificados de GPT-6 Astra ($10 por millón de input, $1 cacheado, $12,50 de escritura, $50 de output) sobre exactamente el mismo volumen:
| Componente | Volumen | Precio Astra | Costo | % |
|---|---|---|---|---|
| Cache read | 1.744 M tokens | $1,00/M | $1.744,26 | 69,9% |
| Output | 11,5 M tokens | $50,00/M | $573,98 | 23,0% |
| Input nuevo | 17,8 M tokens | $10,00/M | $178,28 | 7,1% |
| TOTAL | $2.496,52 | |||
94 veces más caro. Mismo trabajo, mismo harness, mismo mes. Por petición: $0,20 contra $0,0021. Y hay una forma más brutal de verlo: un solo día de nuestra operación en Astra ($83,22) cuesta tres veces nuestro mes completo.
Pero acá viene la sorpresa, y es la parte que importa: el 70% de esa factura de Astra seguirían siendo lecturas de cache. Es decir: nuestra arquitectura haría el trabajo pesado incluso en el modelo más caro del mercado. Si tuvieras la misma operación en Astra pero sin disciplina de cache, la cuenta no sería $2.496 — sería $17.443. Sin la represa, el mismo volumen es 7 veces más caro en el mejor de los casos.
Y si el proveedor mueve sus diales —que es lo que hace un proveedor cuando su ingreso depende de los tokens— la sensibilidad es esta:
| Cache-hit | Costo mensual en Astra | vs. nuestro real |
|---|---|---|
| 99% (el nuestro) | $2.495 | 94x |
| 90% (estándar de la industria) | $3.922 | 148x |
| 80% (ventana agresiva) | $5.508 | 208x |
| 0% (cache expirado) | $18.195 | 688x |
El mensaje: el rango real de la apuesta no es 94x. Es entre 94x y 688x, y quién decide en qué punto caes no sos vos.
7. El canal que ningún cache puede tocar
Y ahora la parte que explica por qué todo lo anterior es estructural y no una anécdota de precios. Volvamos a un dato de la tabla del principio:
Ahí está todo. Y ahí está, también, la razón por la que la memoria y las skills valen lo que valen: no "ahorran tokens" — mueven trabajo del canal de output (caro, incacheable) al canal de input cacheado (barato, reutilizable). Es un arbitraje de 50x sobre el mismo modelo.
Cuando un agente no re-deriva el contexto del proyecto porque está en memoria, o no re-descubre cómo usar una herramienta porque está en una skill, ese pensamiento deja de generarse como output y pasa a leerse como cache. Nuestros 921 tokens de output por petición son exactamente eso: pensamiento pre-computado. La memoria es, en términos económicos, una máquina de convertir output en cache.
Y acá es donde el incentivo y el diseño apuntan al mismo lado. Piénsalo bien, porque es el punto ciego de todo el debate público:
- La inteligencia de un modelo de razonamiento se produce en el canal de output (esfuerzo de razonamiento ajustable, hasta 128.000 tokens de salida por petición).
- El canal de output cuesta $50 por millón y no admite cache.
- Cuanto más alto el esfuerzo por defecto, más tokens de pensamiento = más facturación.
- Y la memoria que eliminaría esa re-derivación es exactamente lo que reduce el ingreso por token.
No hace falta conspiración: el incentivo no está torcido, está alineado con el diseño. No necesitan sabotear tu cache. Les alcanza con que su inteligencia viva en el único canal que ningún cache puede tocar. Los propios análisis de precios lo admiten cuando dicen que el descuento de cache "hace la mayor parte del trabajo para que Astra sea pagable".
Es un conflicto estructural, no una decisión. Y de ahí sale la frase que cierra todo:
Un proveedor metrado por token no puede venderte el producto que reduce sus tokens. La memoria que te ahorra dinero es, por definición, la que ningún proveedor tiene incentivo en darte. Por eso la capa de memoria, skills y cache 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.
Cierre: la soberanía que sí es económica
Y esto cierra un círculo que venimos construyendo hace varios artículos. La soberanía tecnológica suele defenderse con argumentos de privacidad, cumplimiento y control de datos. Todos válidos. Pero falta el argumento que nadie da, y es el más concreto de todos: soberanía de cache es soberanía de costo.
| Escenario | Descuento de cache-read | Persistencia (TTL) | ¿Quién decide? |
|---|---|---|---|
| Modelo frontera cerrado | 10x | no publicado | El proveedor |
| Modelo abierto vía API | ~50x | larga | El proveedor |
| Inferencia local | ∞ (el KV cache es tuyo) | infinita | Nadie |
Con un modelo corriendo en tu propio hardware, el cache cuesta cero y la persistencia es infinita, porque el estado vive en tu memoria. No hay dial que mover porque no hay proveedor que lo mueva. La escalera del descuento —10x, 50x— termina en tu propio fierro.
No es un argumento de pureza ideológica. Es una cuenta: $26,43 contra $2.496 por el mismo mes de trabajo, y la diferencia no la decide el modelo. La decide dónde pusiste la memoria, quién controla el cache, y si alguien más tiene la mano en los diales.
Así que la próxima vez que alguien te diga que la solución es "quitar el harness" —o que te venda que un modelo más caro es el camino— mostrale dos números: 98 tokens baratos por cada token caro, y un canal de output que ningún cache puede tocar. El resto es marketing.
¿Sabes cuánto te cuesta realmente cada token de tu operación?
Casi nadie lo sabe, porque nadie lo mide: se paga la factura y se sigue. En Wagner Solutions auditamos el consumo real de tus agentes —cache-hit, costo por token, costo por tarea cumplida— y rediseñamos la capa que decide tu factura: prefijo estable, presupuesto de contexto, memoria propia y libertad de cambiar de proveedor sin reescribir la operación. Pagamos $26 por 1,77 mil millones de tokens. Podemos medir cuánto pagas tú.
Hablemos 30 minutos →