La mayoría de los tokens de tu agente de IA muere donde nunca miras

Vigilas el medidor de dólares de tu suscripción. Nunca miras dónde mueren de verdad los tokens. Mueren en tres lugares, y puedes tapar los tres sin tocar el modelo.

Todos se obsesionan con el precio por millón de tokens. Es el número equivocado para quedarse mirando. El modelo te cobra por cada token que lee, y la mayoría de lo que lee es basura que nunca habrías pegado tú mismo: doscientos tests pasando en pantalla para esconder los tres que fallaron, el mismo archivo leído cinco veces en una sesión, el stack explicado otra vez al principio de cada conversación nueva.

Ese desperdicio no es culpa del modelo. Es el harness dándole al modelo un chorro de datos y llamándolo contexto. Este artículo acompaña al de harness engineering, con el zoom puesto en un solo eje: la cuenta de tokens. Aquí está a dónde van los tokens y el stack que uso para parar la hemorragia.

Los tokens se fugan en tres lugares

Mira una sesión real y el desperdicio se ordena solo en tres capas. Cada una se fuga de una forma distinta, así que cada una necesita un arreglo distinto. Ponle un modelo más grande y pagas más por las mismas fugas. Arregla las capas y cada sesión se abarata de una vez.

Tres fugas, tres capas

1. L1

   Output de herramientas, la fuga ruidosa

   Cada comando que corre el agente vuelca su output completo en la ventana. Un git status en un repositorio con mucho movimiento son dos mil tokens. Una corrida completa de tests son veinticinco mil. El modelo necesitaba las tres fallas, no los doscientos tests en verde.

   git status  → 2.000 tokens
   corrida de tests → 25.000 tokens

   +
2. L2

   Historial repetido, la fuga silenciosa

   A lo largo de los turnos, la transcripción se repite. El mismo archivo leído cinco veces. El mismo error impreso tres veces. El plan repetido en cada paso. El modelo relee todo eso en cada turno, y pagas por cada relectura.

   mismo archivo × 5 lecturas
   mismo error × 3 impresiones

   +
3. L3

   Reexplicación, la fuga invisible

   Cada sesión nueva empieza de cero. Vuelves a explicar el stack, las convenciones, las decisiones que ya tomaste la semana pasada. Es la fuga más barata de ignorar y la más cara a lo largo de un mes, porque también la pagas con tu tiempo.

   inicio de sesión → reexplicar todo
   siguiente sesión → otra vez

Arregla primero la fuga ruidosa: comprime el output de las herramientas

El cambio de mayor retorno en cualquier harness es un filtro en el output de las herramientas, porque ahí es donde los tokens se desangran y nadie mira. El output pasa por la terminal, parece normal y en silencio se come un tercio de tu ventana.

La herramienta que uso para esto es RTK, un proxy de CLI open source. Se ubica entre el shell y el modelo. El agente corre un comando, RTK reescribe el output a un equivalente comprimido antes de que llegue al context window, y el modelo ve señal en vez de ruido. Filtrado inteligente, agrupación, deduplicación, truncado. En los comandos de dev del día a día ahorra entre 60 y 90 por ciento, y un hook de shell lo vuelve invisible: el agente escribe git status, el hook lo reescribe a rtk git status y nadie más arriba tiene que cambiar nada.

Lo que devuelve el filtro

60-90%

menos tokensen los comandos de dev del día a día

2k → ~0

git statusde chorro a un puñado

25k

tokens de una corrida de testsreducidos a las fallas que importan

0

cambios en el workflowel hook de shell es invisible

Arregla la fuga silenciosa: comprime la conversación

El output de una herramienta es una llamada. La conversación es todo el historial, reenviado en cada turno. Cuando el agente lee el mismo archivo cinco veces, las cinco copias viajan en el contexto del turno seis. Cuando un error se imprimió tres veces, el modelo relee los tres. La ventana se llena de sus propios ecos.

El arreglo es una pasada de compresión entre turnos: deduplicar las lecturas, reducir los pasos exitosos a una sola línea, dejar intactos los turnos recientes y resumir los viejos. El modelo ve el delta, no la transcripción otra vez. Esta es la capa que todavía estoy construyendo, así que no te voy a dar un benchmark inventado. El mecanismo es el mismo que en la capa de herramientas, un nivel más arriba: pon el filtro donde está la repetición y deja de pagar por releer lo que no cambió. La compresión es una táctica dentro de la disciplina más amplia de context engineering: decidir qué ve el modelo en cada turno.

La misma sesión, dos harnesses

Cuatro fugas, cuatro filtros. Ninguno es un modelo más inteligente. Todos son plomería.

A dónde van los tokens	Harness ingenuo	Harness con filtro
Output de herramientas	volcado crudo, 2k a 25k por llamada	comprimido en el origen, 60 a 90% menos
Lecturas repetidas	el mismo archivo reenviado cada turno	deduplicado, una sola copia
Turnos viejos	transcripción completa, cada turno	resumidos, turnos recientes intactos
Inicio de sesión	reexplicar el proyecto a mano	contexto cargado automáticamente desde la memoria

Arregla la fuga invisible: dale memoria al harness

La tercera fuga te cobra dos veces, en tokens y en tu tiempo. En cada sesión nueva vuelves a escribir el stack, las convenciones, las decisiones. El modelo empieza en blanco porque el harness lo permitió.

El arreglo es contexto persistente cargado al inicio de la sesión: las decisiones y convenciones viven en archivos, y el harness inyecta las relevantes antes del primer mensaje. El agente empieza sabiendo en vez de preguntando. En la práctica es un AGENTS.md que el harness lee automáticamente, más un almacén de memoria para lo que es demasiado grande para un solo archivo. Escribí la versión con archivos en la guía de AGENTS.md. El punto aquí es más acotado: la reexplicación es una fuga de tokens como cualquier otra, y el arreglo es dejar de hacer a mano lo que un archivo puede hacer una sola vez.

El stack y su estado real

Tres fugas, tres capas. Esto es lo que de verdad uso, y lo que todavía está en el taller. No te voy a vender las partes que no he puesto en producción.

El stack de tokens en tres capas

• ✓Obligatorio:
  RTK en la capa de herramientas, en producción y claveProxy de CLI open source, comprime el output de los comandos entre 60 y 90 por ciento. Lo uso todos los días. Es el que vale la pena copiar hoy.
• •Opcional:
  Compresión en la capa de la conversación, en construcciónDeduplicar lecturas y resumir turnos viejos entre prompts. El mecanismo ya está probado en la capa de herramientas; la versión para la conversación es lo que estoy conectando ahora.
• •Opcional:
  Memoria en la capa de conocimiento, en construcciónCargar automáticamente las decisiones y convenciones del proyecto al inicio de la sesión. AGENTS.md ya cubre el caso con archivos; el almacén indexado es lo siguiente.
• •Opcional:
  Un proxy local delante de cualquier agenteLa dirección: juntar las tres capas en un único proxy local-first que se ubica entre cualquier agente y el modelo, para que el stack viaje entre pi, Claude Code o cualquier cosa que hable con un endpoint compatible con OpenAI.

El plan no es ingenioso, y de eso se trata. Un proxy que habla el mismo protocolo compatible con OpenAI que ya habla cada agente, haciendo tres trabajos aburridos antes de que la request llegue al modelo.

Lo que hace el proxy con una request

Entrada

Un agente a punto de enviar un turno al modelo

↓

1. MEMORYInyectar lo que importa

   Traer del almacén las decisiones y convenciones relevantes del proyecto y ponerlas en el system prompt, para que el modelo empiece la sesión conociendo ya el código.

   ↓
2. COMPRESSRecortar la repetición

   Deduplicar lecturas repetidas y resumir turnos viejos, para que el modelo pague por el delta en vez de releer toda la transcripción.

   ↓
3. FORWARDEnviar el payload liviano

   Rutear la request recortada al proveedor. RTK ya recortó el output de las herramientas antes, en el shell, así que lo que llega es señal.

↓

Salida

La misma respuesta, con una fracción de los tokens, en cada agente que usas

El número que de verdad hay que mirar

Deja de mirar el precio por millón de tokens. No lo controlas, y de todos modos baja solo cada pocos meses. Mira los tokens por tarea terminada. Ese número es puro harness, y es el que puedes recortar a la mitad esta semana. Si la pregunta real es si un plan fijo le gana a pagar por token, hice esa cuenta en si vale la pena Claude Max.

Aquí hay una palanca más: rutear un modelo barato para explorar y uno fuerte solo para construir. Lo automatizo por fase en pi con un pequeño paquete de cambio de modelo que cambia el modelo y el esfuerzo de razonamiento cuando se carga una skill, explicado en la guía de pi. Los turnos de exploración dejan de cobrarte tarifa premium por trabajo que nunca la necesitó.

Pon un filtro en el output de las herramientas y habrás hecho lo de mayor retorno que tienes a mano. Todo lo que sigue es el mismo movimiento en otra capa: encuentra dónde se repiten los tokens y deja de pagar por leerlos dos veces.

Costo en tokens, respuestas rápidas

¿Cuál es la forma más rápida de recortar el costo en tokens de mi agente de IA de código?+

Comprimir el output de las herramientas en el shell antes de que llegue al modelo. Un git status pueden ser dos mil tokens y una corrida de tests veinticinco mil, y el modelo no necesitaba casi nada de eso.

Un proxy de CLI como RTK hace esto y ahorra entre 60 y 90 por ciento en los comandos del día a día, sin ningún cambio en tu workflow. Es el cambio de mayor retorno que le puedes hacer a un harness.

¿Un context window más grande resuelve el desperdicio de tokens?+

No. Una ventana más grande hace que el desperdicio sea pagable, no que desaparezca. La fuga sigue ahí, solo llegas al límite más tarde y pagas más por turno hasta entonces.

Arregla la fuga en el origen: filtra el output de las herramientas, deduplica el historial repetido y carga la memoria del proyecto para dejar de reexplicar. Con eso, una ventana normal alcanza de sobra.

¿Qué es RTK?+

RTK es un proxy de CLI open source que intercepta comandos comunes de shell y reescribe su output a un equivalente comprimido antes de que llegue al context window del modelo, recortando entre 60 y 90 por ciento de los tokens en los comandos de dev del día a día. Un hook de shell lo vuelve invisible para el agente.

¿A dónde van realmente los tokens en una sesión de agente?+

A tres lugares. Output de herramientas que vuelca el chorro entero cuando el modelo necesitaba una línea. Historial repetido que reenvía las mismas lecturas y errores en cada turno. Y reexplicación, cuando cada sesión nueva empieza en blanco y vuelves a escribir el contexto del proyecto.

Cada fuga tiene su arreglo: comprimir el output, comprimir la conversación y darle memoria al harness.