El impuesto oculto de tokens en los agentes de código con IA

La discusión más útil de la semana sobre agentes de código no fue qué herramienta parece más inteligente. Fue qué envía el agente al modelo antes de leer la tarea.

El 12 de julio, Systima publicó una medición de Claude Code y OpenCode en el límite de la API. El número que se volvió viral fue claro: en una tarea trivial que pedía responder exactamente "OK", Systima midió unos 32.800 tokens de primer turno para Claude Code y unos 6.900 para OpenCode. Para el 14 de julio, el hilo de Hacker News rondaba 687 puntos y 378 comentarios.

No fue solo una pelea de fans. El post tocó una molestia real: los agentes de código ya son útiles para trabajo diario, pero su coste y su comportamiento siguen siendo opacos. El prompt que escribe el desarrollador es solo una parte de la factura. El harness añade instrucciones de sistema, tool schemas, reglas del repositorio, descripciones de servidores MCP, recordatorios, subagentes, cache writes e historial.

La pregunta práctica no es "Claude Code malo, OpenCode bueno". Los propios resultados de Systima son más matizados. La pregunta es si el equipo puede ver qué manda su stack de agentes, por qué lo manda y si la calidad justifica esa carga de tokens.

Qué midió Systima

Systima dice que colocó un logging proxy entre el coding harness y el endpoint del modelo, y comparó Claude Code 2.1.207 y OpenCode 1.17.18 en la misma máquina, tareas y familia de modelo. El estudio incluyó una tarea mínima, una tarea con una herramienta y una tarea multi-step de escribir, ejecutar, probar y corregir.

La tarea mínima fue la famosa. Pedía responder exactamente "OK". En esa configuración, Claude Code rozó 33k tokens antes de trabajo útil y OpenCode unos 7k.

Según los payloads, la causa no era el prompt del usuario. Era el wrapper. Systima afirma que los tool schemas dominaban el baseline: Claude Code exponía 27 tools y unas 99.778 characters de tool schemas, frente a 10 tools y unas 20.856 characters en OpenCode. Incluso sin tools, el system prompt de Claude Code tenía unas 26.891 characters, cerca de 6,5k tokens, frente a 8.811 characters y unos 2k tokens en OpenCode.

Ese es el impuesto oculto de las interfaces agentic. En la terminal parece un solo comando. Por debajo, puede estar enviando un manual pequeño al modelo en cada turno.

Menor no siempre es mejor

Un baseline ligero es atractivo. Cuesta menos, ocupa menos context window y suele añadir menos latencia. Pero Systima también encontró un caso donde el harness más pesado de Claude Code no perdió claramente.

En la tarea multi-step, Claude Code agrupó varias tool calls en menos model requests. OpenCode hizo más llamadas de una herramienta por turno. Como el baseline vuelve a pagarse con cada request, menos requests pueden compensar un baseline mayor. En ese run con Sonnet, Systima midió unos 121k cumulative metered input tokens para Claude Code y unos 132k para OpenCode.

La salvedad importa. Una herramienta pesada al inicio puede ser eficiente si resuelve en menos turnos. Una herramienta ligera puede salir cara si serializa demasiado. El coste de tokens debe medirse por tarea útil, no solo por primer request.

Los comentarios de Hacker News también cuestionaron metodología: Meridian gateway, versión fijada del modelo, impacto del envelope del gateway y si toggles como extended thinking sobrevivían al camino. Systima reconoció varias caveats y los reruns con Fable cambiaron parte del resultado.

Conclusión honesta: el overhead del harness puede ser enorme y muy dependiente de la herramienta. No demuestra que un agente sea siempre más barato que otro.

Por qué ahora importa el overhead de tokens

Para un desarrollador, el overhead aparece como límite de suscripción que se consume rápido, sesiones lentas o contexto que se llena antes de tiempo. Para una empresa, se convierte en presupuesto.

La propia documentación de costes de Claude Code lo dice: cobra por consumo de tokens API, y los costes por desarrollador varían según modelo, tamaño del codebase y patrones como múltiples instancias o automatización. También recomienda pilotos, tracking de uso, límites de gasto, analítica de organización, OpenTelemetry y métricas vía gateway.

Anthropic da referencias de empresa: unos 13 dólares por desarrollador por día activo y 150-250 al mes, con 90% de usuarios por debajo de 30 dólares por día activo. Puede ser razonable. Pero los promedios esconden outliers.

Forbes enmarcó recientemente el token spend como una nueva métrica de gestión después de la fase de "tokenmaxxing". Es el ciclo típico de infraestructura: primero entusiasmo, luego factura, luego governance.

Los agentes de código están entrando en esa segunda fase.

De dónde sale el coste oculto

El prompt visible rara vez es lo más caro. Lo caro es estructural.

Primero están los tool schemas. Cada herramienta expuesta necesita nombre, descripción y schema de parámetros. Si el harness expone archivos, búsqueda, shell, navegador, planificación, tareas y MCP tools, el modelo recibe un menú grande antes de la tarea real. Eso puede mejorar autonomía. También consume contexto y dinero.

Luego están las instrucciones del proyecto. Un AGENTS.md o CLAUDE.md grande puede ser útil si contiene reglas reales. También puede convertirse en un vertedero de preferencias viejas, advertencias repetidas y estilo vago. Systima midió que un instruction file real de 72KB añadía algo más de 20k tokens por request.

Los servidores MCP añaden su propio coste. Cada servidor trae descripciones y schemas. Systima midió alrededor de 1.000 a 1.400 tokens por servidor público pequeño, por request. Los servidores de producción con APIs ricas pueden ser bastante más grandes.

Los subagentes multiplican el problema. Si un orchestrator lanza varios agentes y cada uno recibe las mismas instrucciones, tools y setup, el equipo puede pagar el baseline muchas veces antes de mejorar código.

Por último crece el historial. Una sesión larga gasta cada vez más contexto en scaffolding y estado viejo. Los descuentos de cache ayudan a la factura, pero no liberan context window.

Qué medir antes de discutir herramientas

Un rollout práctico empieza midiendo en el boundary. Si no ves payload size, cache writes, cache reads, output tokens y request count, estás discutiendo sensaciones.

Separa model cost y harness cost. Un modelo premium es una decisión. Un wrapper pesado es otra. El equipo debe saber si la factura viene de reasoning, tool schemas, instruction files repetidos, metadata MCP, subagent fan-out o demasiados turnos.

Mide por tarea, no solo por sesión. Un refactor de 300k tokens puede ser buen negocio si ahorra dos horas de senior engineer. Un rename de 80k tokens porque el agente cargó todas las herramientas e instrucciones, probablemente no.

Mide por proyecto y repositorio. Algunos repos necesitan contexto pesado. Otros cargan instrucciones hinchadas porque nadie las limpió. La diferencia debe verse.

Mide por modo de agente. Planning, implementación, test repair, code review, dependency updates y documentación tienen perfiles distintos. Enviar todo al mismo setup caro es como ejecutar todos los cron jobs en la instancia cloud más grande.

Las reglas de prompt no sustituyen proceso

Un subhilo de Hacker News tocó algo práctico: si en el prompt dices al agente que siempre ejecute tests, puede gastar tokens una y otra vez razonando sobre test policy y ejecutando checks amplios. A veces sirve. A menudo eso pertenece en hooks, CI o scripts específicos.

Lo mismo aplica a style rules, security checks y release steps. Si una regla es determinista, ponla donde el software la aplique barato. Pre-commit hooks, pre-push hooks, CI jobs y scripts del repo son aburridos, pero reducen la necesidad de que el modelo recuerde la misma política en cada turno.

Usa instrucciones para juicio. Usa automatización para repetición.

Así el agente queda para lo que necesita lenguaje y razonamiento: entender el cambio, elegir el enfoque, navegar el codebase, explicar trade-offs y corregir fallos que no salen de una regla estática.

Gobernar el coste sin matar la adopción

La mala reacción es prohibir agentes potentes porque un benchmark parece caro. La otra mala reacción es dar acceso ilimitado y esperar que la factura coincida con la demo.

Un rollout sano se parece más a FinOps para desarrollo con AI.

Empieza con un pilot group. Mide trabajo real, no toy prompts. Incluye fixes pequeños, code review, test repair, migraciones y cambios multi-file. Compara token spend con outcomes: tiempo ahorrado, bugs encontrados, PR cycle time y satisfacción.

Pon budgets y alerts. Un developer debe saber cuándo una sesión quema contexto o límites. Los managers deben ver tendencias por proyecto y equipo sin convertir el tracking en vigilancia.

Routea tareas. Usa el mejor modelo cuando haga falta. Usa modelos más baratos o harnesses más pequeños para edits rutinarios, explicación, formato y tareas de búsqueda. Si hay subagentes, deberían poder bajar a modelos más baratos cuando el trabajo es estrecho.

Audita instruction files. Quita reglas viejas. Divide instrucciones gigantes en skills o guías específicas si el harness lo permite. Las reglas del repo deben ser concisas y verificables.

Audita MCP servers. No conectes todos los servidores a todas las sesiones por defecto. Una herramienta de base de datos, navegador, ticket tracker o cloud admin puede ser valiosa. No todas hacen falta en cada prompt de código.

Observa cache behavior. Cache writes, cache reads y context window use son cosas distintas. Un cache read descontado puede seguir llenando contexto.

Más allá del código

Los coding agents solo hacen visible el problema antes que otros. El mismo patrón aparecerá en agentes de ventas, legal research, soporte, data analysis y bots internos.

Cada framework lleva overhead: role instructions, tool schemas, memory, policies, examples, retrieved context e historial. Parte mejora reliability. Parte es cargo cult. Sin observabilidad, el equipo no distingue.

El mercado está pasando de "demos más contexto" a "demuestra que este contexto vale la pena". Es un buen cambio. No hace menos útiles a los agentes. Los convierte en infraestructura.

La lección práctica

El post de Systima se volvió viral porque puso nombre a un coste que muchos sentían pero no veían. Treinta y tres mil tokens antes del prompt es un ejemplo fuerte. La lección es más amplia: los agentes AI tienen bill of materials.

Incluye modelo, harness, tools, instruction files, servers, subagentes y hábitos de la organización. Si un agente caro produce mejores resultados, úsalo. Si quema tokens en scaffolding que nadie entiende, arregla el scaffolding.

La siguiente fase madura de AI Practice no es menos AI. Es AI medible. Los equipos deberían responder preguntas simples: qué envió el agente, cuánto costó, qué logró y qué parte del stack marcó la diferencia.