C贸mo reducir tokens en agentes de programaci贸n - Claude, Codex, Cursor
Los agentes de programaci贸n investigan repositorios, modifican archivos, ejecutan comandos y corrigen errores. Esa autonom铆a acelera el desarrollo, pero hace crecer el contexto: lecturas, resultados de herramientas y turnos anteriores pueden reenviarse al modelo. Para reducir tokens en agentes de programaci贸n hay que decidir qu茅 informaci贸n necesita cada agente y durante cu谩nto tiempo.
Bai et al. (2026) estudiaron ocho modelos de frontera en SWE-bench Verified y encontraron que la programaci贸n con agentes consume 贸rdenes de magnitud m谩s tokens que el razonamiento o el di谩logo sobre c贸digo. El costo proviene sobre todo de la entrada, var铆a mucho entre ejecuciones y no produce autom谩ticamente mayor precisi贸n. La oportunidad est谩 en dise帽ar mejor el flujo de contexto.
Este art铆culo compara un agente monol铆tico con una arquitectura formada por Planner, Researcher, Implementer, Reviewer y Tester. La hip贸tesis es que la calidad depende m谩s de entregar el contexto correcto a cada agente que de compartir el repositorio completo.
Por qu茅 el consumo de tokens crece tan r谩pido
En un flujo monol铆tico, el mismo agente investiga, planifica, implementa, revisa y prueba. La tarea, conversaci贸n, archivos, b煤squedas, registros, cambios y pruebas se acumulan aunque una parte deje de ser 煤til.
Bai et al. (2026) relacionan el costo con el crecimiento de la entrada y la reutilizaci贸n del contexto. Las ejecuciones m谩s costosas mostraron m谩s lecturas y ediciones repetidas, mientras la precisi贸n se estabiliz贸 en niveles intermedios. Gastar m谩s puede indicar exploraci贸n improductiva, no mejor razonamiento.
Conviene distinguir cuatro fuentes de consumo:
路 Contexto inicial: instrucciones, arquitectura, convenciones y archivos.
路 Contexto acumulado: respuestas anteriores y resultados de herramientas.
路 Exploraci贸n: b煤squedas, lecturas y relecturas que no terminan influyendo en el cambio.
路 Razonamiento y salida: planificaci贸n, explicaci贸n, c贸digo y reportes.
Esta separaci贸n cambia la pregunta. En vez de preguntar cu谩nto contexto cabe, el equipo pregunta qu茅 evidencia m铆nima permite tomar la siguiente decisi贸n sin perder seguridad.
Para analizar el rendimiento, se ejecut贸 la siguiente instrucci贸n con un agente monol铆tico basado en GPT-5.6 Sol con nivel de razonamiento xHigh.
Resultado de la ejecuci贸n monol铆tica con GPT-5.6 Sol y razonamiento xHigh
Instrucci贸n utilizada
Arquitectura para reducir tokens en agentes de programaci贸n
La alternativa divide el trabajo por responsabilidad. Cada etapa recibe un paquete compacto y entrega un resultado expl铆cito, sin arrastrar el historial completo de los dem谩s agentes.
Planner y Researcher
El Planner interpreta la tarea, identifica restricciones, divide el trabajo y define criterios de aceptaci贸n. Puede usar el modelo de mayor capacidad, pero su salida debe centrarse en la investigaci贸n necesaria y la evidencia aceptable.
El Researcher responde preguntas dirigidas. Consulta el mapa del proyecto, busca s铆mbolos concretos y entrega un paquete con archivos, contratos, restricciones, comandos y riesgos relevantes.
Implementer
El Implementer recibe la tarea, el plan, el paquete de contexto y los archivos afectados. Produce el cambio m铆nimo y devuelve las ambig眉edades sin reiniciar una exploraci贸n general.
Reviewer y Tester
El Reviewer analiza requisitos, cambios y contexto m铆nimo en busca de regresiones, riesgos y trabajo innecesario. El Tester valida el comportamiento y s贸lo ampl铆a la cobertura cuando aparece una se帽al de riesgo.
Los motores basados en grafos materializan este patr贸n mediante secuencias, enrutamiento, tareas paralelas, ciclos, concurrencia e historiales aislados. As铆 hacen visibles los traspasos, reintentos y puntos de aprobaci贸n humana (Klopfenstein & Maddula, 2026).
Diagrama del flujo Planner, Researcher, Implementer, Reviewer y Tester
Contexto, aislamiento y traspasos compactos
Tambi茅n es fundamental un 铆ndice de contexto que documente arquitectura, convenciones, comandos, restricciones y rutas. No reemplaza la lectura del c贸digo: dirige la b煤squeda y evita redescubrir la misma estructura.
Un paquete de contexto 煤til deber铆a contener:
路 Objetivo y decisi贸n que debe tomar el siguiente agente.
路 Archivos y s铆mbolos relevantes, con una frase sobre su funci贸n.
路 Contratos que no pueden romperse y criterios de aceptaci贸n.
路 Riesgos, incertidumbres y preguntas todav铆a abiertas.
路 Comandos de validaci贸n y salida esperada.
El paquete transfiere decisiones y evidencia, no registros completos ni todo el razonamiento. Un contrato de salida estable reduce el retrabajo y permite medir qu茅 contexto result贸 煤til.
Evidencia real sobre compresi贸n activa
La compresi贸n activa complementa el aislamiento entre subagentes. Verma (2026) compar贸 un agente de referencia con Focus, que conserva aprendizajes y elimina exploraciones ya resumidas. En cinco casos de SWE-bench Lite con Claude Haiku 4.5, Focus redujo el consumo un 22,7 %, de 14.920.555 a 11.526.418 tokens, y mantuvo el mismo 茅xito: 3 de 5 tareas, o 60%.
Focus realiz贸 6,0 compresiones y descart贸 70,2 mensajes por tarea. Ahorr贸 entre 18% y 57% en cuatro casos. En matplotlib-26020, ambos agentes aprobaron las pruebas y el consumo baj贸 de 4,0 a 1,7 millones de tokens (Verma, 2026).
El beneficio no fue universal. En pylint-7080, Focus consumi贸 un 110 % m谩s: 4,3 millones frente a 2,1 millones de tokens, porque elimin贸 informaci贸n que luego debi贸 explorar otra vez. El estudio usa cinco casos y un modelo; no demuestra que toda arquitectura multiagente sea m谩s eficiente (Verma, 2026).
Extracto de 铆ndice de contexto.
Experimento reproducible: monol铆tico frente a subagentes
Las variantes deben usar el mismo repositorio, rama, tarea, entorno, criterios de aceptaci贸n y pruebas. Dado que el consumo var铆a entre ejecuciones, conviene repetir cada variante y comparar la distribuci贸n, no s贸lo el promedio.
Variantes
- Agente monol铆tico: investiga, planifica, implementa, revisa, prueba y corrige dentro del mismo historial.
- Arquitectura orquestada: Planner, Researcher, Implementer, Reviewer y Tester reciben contexto aislado.
- Variante opcional: la arquitectura orquestada consulta el 铆ndice de contexto antes de hacer b煤squedas dirigidas.
M茅tricas
Registrar por etapa tokens de entrada, salida, cach茅 y razonamiento; costo, tiempo, lecturas, b煤squedas, comandos y pruebas. Tambi茅n conviene contar archivos sin efecto en los cambios y operaciones repetidas.
La m茅trica principal es tokens por tarea correctamente resuelta. La r煤brica debe ser id茅ntica para todas las variantes e incluir correctitud, pruebas, regresiones, mantenibilidad y cambios innecesarios.
Criterios de interpretaci贸n
Una arquitectura no gana si ahorra tokens pero incumple los criterios. Bai et al. (2026) muestran que el costo es dif铆cil de anticipar; Verma (2026) registra ahorros de 18 % a 57 % y un caso con 110 % de sobrecosto. Por eso hay que informar repeticiones, dispersi贸n, configuraci贸n, pruebas y limitaciones.
Para continuar la comparaci贸n pr谩ctica, se ejecut贸 la misma instrucci贸n con una arquitectura multiagente. GPT-5.6 Sol con razonamiento xHigh actu贸 como orquestador y cada subagente utiliz贸 GPT-5.6 Luna con razonamiento xHigh, un modelo de menor costo.
Resultado de la misma instrucci贸n con la arquitectura multiagente y GPT-5.6 Luna xHigh
C贸mo interpretar los resultados y evitar la sobre arquitectura
Resumen de los resultados obtenidos
En la comparaci贸n local, el agente monol铆tico proces贸 656.120 tokens y la arquitectura multiagente proces贸 474.285. La diferencia fue de 181.835 tokens, equivalente a una reducci贸n del 27,7 %. El cambio m谩s importante ocurri贸 en la entrada no almacenada en cach茅: baj贸 de 244.390 a 71.847 tokens, un 70,6 % menos. Al mismo tiempo, el aprovechamiento de cach茅 subi贸 de 62,6 % a 84,8 %.
La salida aument贸 de 2.418 a 3.078 tokens y los tokens de razonamiento pasaron de 232 a 253\. Este incremento fue peque帽o frente al ahorro de entrada y sugiere que los subagentes produjeron respuestas algo m谩s extensas mientras reutilizaban mucho mejor el contexto. La reducci贸n total no provino de razonar menos, sino de reenviar menos informaci贸n nueva al modelo.
La revisi贸n cualitativa tambi茅n fue favorable. Ambos enfoques identificaron las pruebas principales, la integraci贸n continua antes del despliegue, la limpieza del repositorio, las versiones de Node.js y el registro de eventos. La arquitectura multiagente destac贸 adem谩s la revisi贸n est谩tica del backend, los scripts de PostgreSQL y el comando npm verify; el agente monol铆tico, por su parte, se帽al贸 marcadores TODO y FIXME. Con una sola ejecuci贸n por variante, estos resultados son evidencia del caso analizado, no una garant铆a general.
Los resultados son coherentes con la t茅cnica descrita: el mayor beneficio apareci贸 al aislar y reutilizar el contexto, no al reducir la calidad del an谩lisis. Sin embargo, el informe debe separar el consumo por etapa para identificar qu茅 decisi贸n produjo la mejora y repetir la prueba antes de generalizar.
La coordinaci贸n tambi茅n cuesta. Si los traspasos son ambiguos, el siguiente agente repetir谩 la investigaci贸n; si el contexto se recorta demasiado, perder谩 restricciones cr铆ticas. Usar un modelo de alta capacidad en cada funci贸n s贸lo fragmenta el gasto.
Una regla operativa razonable es escalar la orquestaci贸n con la incertidumbre:
路 Tarea simple y localizada: un agente con pruebas claras.
路 Tarea media: Planner, Implementer y Tester.
路 Tarea compleja o transversal: Planner, Researcher, Implementer, Reviewer y Tester.
Antes de a帽adir una funci贸n, conviene preguntar qu茅 contexto aislar谩, qu茅 decisi贸n tomar谩 y qu茅 riesgo reducir谩. Si no existe una respuesta verificable, probablemente a帽adir谩 costo de coordinaci贸n sin aportar valor. A continuaci贸n, se presentan la comparaci贸n de resultados obtenidos, tanto el uso de tokens como los resultados del prompt utilizado.
Comparaci贸n del uso de tokens
Comparaci贸n cualitativa de los resultados \- 驴Qu茅 sugerencias identific贸 cada prueba?
Aplicaci贸n en empresas
En una organizaci贸n, optimizar tokens permite asignar presupuestos por etapa, reservar el modelo m谩s capaz para decisiones dif铆ciles y usar alternativas econ贸micas en tareas deterministas. Tambi茅n mejora la trazabilidad de archivos, decisiones y pruebas.
El aislamiento facilita controles de seguridad: lectura para el Researcher, edici贸n limitada para el Implementer, ejecuci贸n controlada para el Tester y aprobaci贸n humana antes de acciones sensibles.
Para operar este enfoque conviene versionar el 铆ndice, definir contratos de traspaso, registrar m茅tricas por funci贸n y auditar el contexto no utilizado sin perder informaci贸n necesaria.
Conclusi贸n
La estrategia para reducir tokens en agentes de programaci贸n, independiente del entorno codex, claude o cursor, no consiste en imponer instrucciones m铆nimas a cualquier costo. Consiste en tratar el contexto como un recurso arquitect贸nico: seleccionar, aislar, resumir, transferir y medir. El Planner define el plan, el Researcher encuentra evidencia, el Implementer modifica el c贸digo, el Reviewer revisa los cambios y el Tester valida el comportamiento.
La evidencia disponible advierte que m谩s tokens no garantizan m谩s calidad y que el gasto real puede variar entre ejecuciones (Bai et al., 2026). Tambi茅n muestra que consolidar aprendizajes y retirar historial obsoleto puede reducir un 22,7 % el consumo total sin cambiar la exactitud en un conjunto peque帽o de tareas, aunque una tarea iterativa present贸 un 110 % de sobrecosto (Verma, 2026). El experimento local refuerza esa direcci贸n con una reducci贸n del 27,7 %, pero debe repetirse antes de convertir el resultado en una regla general.
En Kranio dise帽amos soluciones de IA aplicadas a procesos de ingenier铆a con foco en eficiencia, seguridad y resultados verificables. Si tu empresa quiere evaluar y optimizar flujos de agentes de programaci贸n, puedes contactarnos en [www.kranio.io.](www.kranio.io.)
Referencias
Bai, L., Huang, Z., Wang, X., Sun, J., Mihalcea, R., Brynjolfsson, E., Pentland, A., & Pei, J. (2026). How do AI agents spend your money? Analyzing and predicting token consumption in agentic coding tasks \[Preprint\]. arXiv. https://arxiv.org/abs/2604.22750
Klopfenstein, T., & Maddula, S. K. (2026, June 30). Build reliable multi-agent applications with ADK Go 2.0: Discover our new graph-based workflow engine, built-in human-in-the-loop, and dynamic orchestration. Google Developers Blog.
Verma, N. (2026). Active context compression: Autonomous memory management in LLM agents \[Preprint\]. arXiv. https://arxiv.org/abs/2601.07190
Entradas anteriores
Arquitectura de chatbot: gu铆a imparcial para empresas
Gu铆a imparcial para elegir la arquitectura de chatbot correcta en 2026. Compara RAG, fine-tuning, Agentic RAG y MCP seg煤n costo, riesgo y caso de uso.
Prompt Injection en IA: c贸mo asegurar tu infraestructura
Descubre qu茅 es el Prompt Injection en IA, c贸mo funcionan los ataques m谩s recientes y qu茅 estrategias implementar para proteger agentes, copilotos y sistemas basados en LLMs.
