Los agentes de codificación de IA queman decenas de miles de tokens antes siquiera de leer tu prompt
Antes de que un agente de codificación de IA lea una sola palabra de lo que escribes, ya ha gastado miles de tokens presentándose: system prompts, tool schemas, bloques de scaffolding. Una comparativa independiente reciente entre dos harness populares de agentes, Claude Code y OpenCode, midió directamente esta sobrecarga utilizando un proxy de logging que capturó los payloads JSON exactos enviados a la API del modelo. La diferencia fue lo suficientemente grande como para cambiar la forma en que cualquiera que ejecute estas herramientas a escala debería pensar en los costes.
En una tarea baseline de primer turno sobre Claude Sonnet 4.5, Claude Code envió aproximadamente 32.800 tokens antes de que se procesara el prompt real del usuario. OpenCode envió unos 6.900 tokens para la misma tarea — una diferencia de 4,7x. La brecha se reduce a 3,3x en modelos más nuevos, pero no desaparece. Esta sobrecarga es invisible en el uso normal: escribes un prompt, obtienes una respuesta y nunca ves el payload que se envió por debajo. Pero se factura igual que todo lo demás, y se acumula de formas que importan una vez que superas los ejemplos simples.
Dónde van realmente los tokens
La sobrecarga se divide en tres componentes medibles. Los system prompts representan la parte más pequeña, pero sigue siendo real: el system prompt de Claude Code tiene 27.344 caracteres (aproximadamente 6.500 tokens), frente a los 9.324 caracteres (~2.000 tokens) de OpenCode. Los tool schemas suponen un coste mayor: Claude Code envía 27 tool definitions que abarcan unos 99.778 caracteres (~24.000 tokens), mientras que el conjunto de herramientas más ligero de OpenCode, con 10 tools, suma 20.856 caracteres (~4.800 tokens). El resto es scaffolding: Claude Code inyecta bloques de recordatorios, catálogos de agentes y encuadres de contexto antes del mensaje real del usuario; OpenCode no añade nada de esto por defecto.
Nada de esto es desperdicio en el sentido de ser inútil: más herramientas y un scaffolding más rico generalmente permiten que el agente haga más sin tener que hacer preguntas aclaratorias. Es una compensación de diseño real entre capacidad por solicitud y coste por solicitud, y es una que la mayoría de los usuarios nunca llegan a ver, y mucho menos a elegir.
La brecha empeora con una configuración realista
Los números baseline subestiman lo que realmente cuestan las configuraciones de producción. Añade un archivo típico de instrucciones del proyecto de 72KB (el tipo de archivo CLAUDE.md o AGENTS.md que ahora mantienen la mayoría de los codebases serios) y ambos harness suman aproximadamente 20.000 tokens adicionales por solicitud — esta parte está impulsada por la configuración, no por el harness, por lo que afecta a ambas herramientas por igual. Agrega cinco servidores MCP (Model Context Protocol), una configuración común para equipos que conectan Slack, Jira, bases de datos o APIs internas, y cada servidor añade entre 4.900 y 6.967 tokens por solicitud solo para anunciar sus herramientas disponibles.
Junta todo esto y una configuración de producción realista alcanza entre 75.000 y 85.000 tokens antes de que el usuario haya escrito una sola palabra de su solicitud real. En una ventana de contexto de 200.000 tokens, eso supone más del 40% del espacio disponible consumido por scaffolding antes de que se escriba o lea cualquier código.
El comportamiento de caché es donde realmente diverge el coste
La diferencia más relevante no es el recuento baseline de tokens, sino lo que sucede con esa sobrecarga a lo largo de una sesión. OpenCode mantiene un prefijo de solicitud byte-idéntico entre turnos, lo que significa que el prompt caching funciona casi de manera ideal: los mismos tokens se reutilizan de la caché turno tras turno con reescrituras mínimas.
El scaffolding de Claude Code, por el contrario, se reescribe a mitad de sesión — nuevos bloques de recordatorios, contexto actualizado, tool state refrescado — lo que obliga a invalidar y reconstruir la caché repetidamente. El volumen medido de cache-write para Claude Code osciló entre 5,9x y 54x el de OpenCode, dependiendo de lo “caliente” que estuviera la caché en el momento de la medición. Las escrituras de caché no son gratuitas: se facturan con una prima del 1,25x sobre la tasa base de entrada para un TTL estándar de 5 minutos. Un harness que reescribe constantemente su propia caché paga esa prima con mucha más frecuencia que uno que no lo hace.
Los subagentes multiplican el problema, no solo lo suman
El número más impactante de la comparativa involucra la delegación. Una tarea que costó 121.000 tokens acumulados cuando se ejecutó directamente costó 513.000 tokens cuando el mismo trabajo se distribuyó a dos subagentes — un aumento de 4,2x para lo que, en principio, debería ser la misma cantidad total de trabajo dividido. Cada subagente paga nuevamente la sobrecarga baseline completa (system prompt, tool schemas, scaffolding) de forma independiente; la delegación no comparte ese coste, sino que lo multiplica por el número de agentes generados.
Esto importa directamente para la forma en que los equipos deberían arquitecturar flujos de trabajo agentivos. Distribuir una tarea entre subagentes a menudo se plantea como una victoria de paralelismo puro: más agentes, menos tiempo de reloj. La contabilidad de tokens cuenta una historia diferente: es una compensación de coste real, y para tareas pequeñas o medianas, la multiplicación de la sobrecarga puede superar cualquier tiempo que ahorres.
Qué hacer realmente con esto
Curiosamente, en tareas complejas de varios pasos los harness convergen: Claude Code utilizó 121.000 tokens acumulados en 3 solicitudes (agrupación agresiva de tool-call), mientras que OpenCode utilizó 132.000 tokens en 9 solicitudes serializadas. Para trabajo verdaderamente complejo, la brecha baseline de sobrecarga importa menos porque se amortiza en más trabajo real por solicitud.
Las conclusiones prácticas: audita el tamaño de tu archivo CLAUDE.md/AGENTS.md — ese impuesto de 20.000 tokens afecta a cada solicitud independientemente del harness. Sé deliberado sobre cuántos servidores MCP mantienes activos; cada uno es un coste fijo por solicitud, lo uses o no en un turno determinado. Y trata el fan-out de subagentes como una decisión de coste, no solo de velocidad — resérvalo para tareas lo suficientemente grandes como para que valga la pena pagar el multiplicador de 4x por el paralelismo.