Resumen de la publicación
Un análisis empírico de julio de 2026 midió algo que casi nadie mira: cuántos tokens consume un agente de IA antes de leer tu primer prompt. Claude Code arranca cada request con unos 33.000 tokens de system prompt, definiciones de herramientas y scaffolding; OpenCode, con unos 7.000. Y en un benchmark con idéntico resultado final, uno gastó 3,7 veces más tokens que el otro.
Si trabajás con agentes de IA (o pagás la factura de un equipo que lo hace), este artículo te sirve para entender de dónde sale ese costo invisible, qué es el prompt caching y por qué cambia la ecuación, cuándo conviene un agente liviano y cómo empezar a medir lo que tus agentes gastan de verdad.
Hace un tiempo conté en este blog cómo orquesto agentes de IA en paralelo con Claude Code para trabajo real: varios agentes corriendo a la vez, cada uno con su tarea.
Lo que no conté en ese momento es la otra mitad de la historia: cada uno de esos agentes arranca su vida gastando decenas de miles de tokens que yo nunca escribí ni voy a leer. Y cuando multiplicás eso por agentes en paralelo, por requests por turno y por días de trabajo, el costo por token deja de ser un detalle de facturación y pasa a ser una variable de arquitectura.
Los 33.000 tokens que nunca escribiste
La gente de Systima publicó en julio un análisis empírico que me pareció oro: pusieron un proxy entre dos harnesses de agentes (Claude Code y OpenCode, ambos apuntando al mismo modelo) y capturaron los payloads exactos de cada request.
El primer dato es contundente. Para una tarea trivial (responder «OK», 22 caracteres), Claude Code consumió unos 33.000 tokens antes de que el modelo llegara a leer el prompt del usuario; OpenCode, unos 7.000.
¿De dónde salen? De tres lugares que casi nadie audita:
- El system prompt: las instrucciones base del harness. En la medición, unas 3,3 veces más grande en Claude Code que en OpenCode.
- Las definiciones de herramientas: cada tool que el agente puede usar viaja como un schema JSON en cada request. Claude Code cargaba 27 herramientas (casi 100 KB de schemas); OpenCode, 10 herramientas (21 KB).
- El scaffolding inyectado: recordatorios de sistema, estado del entorno, contexto del repositorio.
Y ojo, que la configuración multiplica: cada servidor MCP conectado suma entre 1.000 y 1.400 tokens por request, y un archivo de instrucciones de 72 KB le agregó unos 20.000 tokens a cada llamada en ambos harnesses.
El dato que más me hizo ruido es el benchmark de calidad: en una tarea de implementar utilidades de fechas, con cinco corridas por harness, ambos aprobaron 5 de 5. Pero uno lo hizo con ~72.000 tokens de input por corrida exitosa y el otro con ~268.000. Mismo resultado, 3,7 veces el costo.
Y si delegás en subagentes, peor: la misma tarea que directa costaba 121.000 tokens, repartida entre dos subagentes costó 513.000. Cada subagente es un agente completo que vuelve a cargar su propio system prompt y sus herramientas en cada turno.
Más contexto no es más inteligencia
Acá viene la parte que me parece más incomprendida: esto no es solo un problema de plata. Es un problema de calidad.
Hay un argumento que vengo viendo crecer y que comparto: los LLMs en conversaciones largas no fallan porque «se olvidan», fallan porque acumulan de más. El rendimiento de razonamiento se degrada con el largo del input, y cada token redundante (el resultado viejo de una herramienta, el pasaje duplicado que trajo el RAG) no es neutro: degrada calidad, sube latencia y sube costo, todo a la vez.
La autora de ese análisis construyó una capa de «poda» determinística que elimina contexto vencido y duplicado, con una pasada final que restaura cualquier mensaje del que dependan turnos posteriores. Los números: en agentes con herramientas logró reducir el prompt un 33% preservando el 100% de los hechos requeridos, con menos de 44 milisegundos de overhead.
La idea de fondo me encanta: el contexto de una conversación hay que administrarlo como un sistema operativo administra memoria. Algo tiene que decidir activamente qué se queda y qué se va, en vez de acumular pasivamente hasta reventar.
Prompt caching: por qué cambia la ecuación
Ahora, seamos justos con los harnesses «cargados»: existe un mecanismo que amortigua buena parte de este overhead, y entenderlo es clave para no sacar conclusiones apuradas.
El prompt caching funciona así: como el system prompt y las definiciones de herramientas son idénticos en cada request, el proveedor puede cachear ese prefijo. La primera vez pagás la escritura al caché con un recargo (en el caso de Anthropic, 1,25 veces el precio de input para el caché de 5 minutos), pero cada lectura posterior cuesta alrededor del 10% del precio normal.
Es decir: esos 33.000 tokens de arranque, bien cacheados, en el segundo request cuestan como 3.300. La ecuación cambia por completo.
Pero (y este «pero» es enorme) el caché es un prefix match: un solo byte que cambie al principio invalida todo lo que viene después. Un timestamp interpolado en el system prompt, una herramienta que se agrega a mitad de sesión, un JSON serializado en orden distinto, y estás pagando precio completo en cada request sin enterarte.
El mismo análisis de Systima encontró exactamente eso: uno de los harnesses mantenía un prefijo byte-idéntico entre requests (caché estable), mientras el otro reescribía decenas de miles de tokens de caché a mitad de sesión. La diferencia medida en escrituras de caché para el mismo trabajo fue de 54 a 1.
¿Agente liviano o agente cargado?
Entonces, ¿la conclusión es «usá siempre el agente liviano»? No. Desde mi punto de vista, la conclusión es que la elección del harness es una decisión de arquitectura, con trade-offs que hay que conocer.
Un agente «cargado» (system prompt grande, muchas herramientas, subagentes) te compra autonomía: resuelve tareas largas y ambiguas sin que lo tengas que llevar de la mano. Yo lo uso todos los días y el costo extra se paga solo en tiempo mío ahorrado.
Pero para tareas acotadas y repetitivas (clasificar un ticket, resumir un documento, generar un snippet), pagar 33.000 tokens de contexto general en cada llamada es tirar plata. Ahí conviene un agente liviano con las tres herramientas que la tarea necesita, o directamente una llamada simple a la API sin harness.
Mi regla práctica: el overhead fijo se amortiza en tareas largas y se vuelve ridículo en tareas cortas. Si tu agente hace un solo request por tarea, el «peso de arranque» es casi todo tu costo.
Medí antes de optimizar
Nada de esto sirve si no medís. La buena noticia es que medir es fácil, porque la API te devuelve todo en cada respuesta. Lo que hago yo (y lo que le recomiendo a cualquier equipo):
- Loggeá el
usagede cada request: los camposinput_tokens,output_tokens,cache_creation_input_tokensycache_read_input_tokensvienen en cada respuesta de la API. Guardalos por tarea y por agente. - Vigilá el ratio de caché: si
cache_read_input_tokensda cero en requests repetidos, algo está invalidando tu prefijo (un timestamp, un ID aleatorio, herramientas que cambian). Es plata que se va en silencio. - Auditá tus servidores MCP y herramientas: cada uno suma tokens a cada request, lo uses o no en esa tarea. Conectá los que usás de verdad.
- Medí costo por tarea completada, no por request: como mostró el benchmark, dos configuraciones pueden lograr lo mismo con 3,7 veces de diferencia. La métrica que importa es tokens por resultado.
¿Sabés cuánto gasta tu agente antes de leerte?
Lo que me llevo de todo esto es un cambio de mentalidad: en la era de los agentes, el prompt que escribís es la punta del iceberg. Abajo hay system prompts, schemas de herramientas, scaffolding y subagentes que pagás en cada request, los leas o no.
No hace falta volverse obsesivo ni migrar de herramienta mañana. Hace falta medir, entender el caching y elegir el peso del agente según la tarea.
Te dejo la pregunta directa: ¿alguna vez loggeaste el usage de tus agentes y calculaste cuánto pagás de overhead por tarea? Si lo hiciste, me encantaría ver esos números. Te leo en los comentarios o en el próximo meetup del MUG.
