Coste de contexto en agentes IA: cómo medir prompts y llamadas a herramientas

Al desarrollar agentes de IA (Claude Code, Cline, Roo Code o pipelines propios de varios pasos), el uso de la API puede aumentar a medida que se acumula el contexto. La composición concreta de cada solicitud depende del cliente: puede incluir el prompt del sistema, los esquemas de herramientas disponibles, el historial de mensajes y los resultados de llamadas a funciones.

Para controlar el presupuesto sin perder funcionalidad, establezca una baseline con una tarea fija, localice la fuente principal de tokens innecesarios y optimice el entorno del agente cambiando una sola variable cada vez.

Anatomía del contexto de un agente IA: por qué se cobran tokens en cada paso

Para medirlo, divida el contexto enviado al modelo en cuatro componentes observables:

1. Instrucciones y reglas del sistema (System Prompt): requisitos básicos de estilo, límites de seguridad y contexto del repositorio.
2. Esquemas de herramientas (Tool Schemas): descripciones JSON de funciones conectadas, parámetros y tipos de datos, cuando el cliente los incluye en una solicitud.
3. Historial de mensajes (Message History): mensajes anteriores del usuario y respuestas del agente que se acumulan durante la tarea.
4. Resultados de herramientas (Tool Outputs): contenido de archivos leídos, registros de comandos de terminal y volcados de API.

No multiplique a ciegas el tamaño de la primera solicitud por el número de pasos. Exporte el usage de cada llamada: el historial puede crecer, el cliente puede truncar datos y el proveedor puede contabilizar los cached tokens por separado.

Tabla comparativa de fuentes de contexto y sus optimizaciones

Componente de contexto	Qué medir	Riesgo principal de sobrecoste	Cambio para una prueba aislada
Tool Schemas	Tamaño de la lista que se envía realmente	Herramientas no utilizadas en el conjunto común	Dejar solo las tools necesarias para la tarea
Tool Outputs	Tamaño de cada resultado	Leer archivos completos en vez de fragmentos concretos	Limitar rangos de líneas y volumen de logs
Historial de pasos	Crecimiento del input de llamada a llamada	Se acumulan resultados que ya no hacen falta	Comprobar la reducción de historial que admite el cliente
System Prompt	Tamaño y estabilidad del prefijo	Instrucciones repetidas	Eliminar duplicados sin perder reglas obligatorias

Guía paso a paso: medir una baseline y reducir el gasto

Primero, registre las tarifas actuales del modelo. Para calcular la baseline, use los precios actuales de BetterToken, no valores de ejemplos antiguos. Ver los precios actuales de BetterToken

Para una optimización objetiva, aplique una metodología de medición de una sola variable:

Paso 1. Fijar una tarea de control para la prueba

Elija un escenario de ingeniería reproducible, por ejemplo: «buscar una función de validación en un repositorio, añadir el manejo de un caso límite y ejecutar pruebas unitarias». La tarea debe tener un criterio de finalización claro, como código de salida 0 en pytest o bun test.

Paso 2. Medir la baseline (Input, Output, Cache)

Ejecute la tarea con la configuración estándar del agente. Registre en logs o en el panel de monitorización:

• número de pasos ejecutados;
• volumen total de input tokens;
• volumen total de output tokens;
• volumen de tokens almacenados en caché (cached tokens);
• coste económico según las tarifas actuales.

Consulte las tarifas actuales del modelo elegido en la página de precios de BetterToken. En Workspace, para una solicitud aceptada puede revisar el modelo, hora y estado, input/output tokens, cached tokens cuando el modelo los admite y el coste de la llamada. Si un paso del agente genera varias solicitudes, no presente un registro a nivel de solicitud como un desglose terminado por paso: relaciónelos por tiempo y por los datos de su propio cliente.

Paso 3. Cambiar una variable de contexto

Realice pruebas aisladas cambiando estrictamente un parámetro en cada iteración:

• Experimento A (Tool Filtering): Deje solo las herramientas necesarias para la tarea de control y mida la diferencia de input tokens.
• Experimento B (Output Truncation): Limite la salida del terminal a las primeras 50 líneas de un error en lugar de un volcado completo de 2.000 líneas.
• Experimento C (Prefix Stability): Si el modelo y el endpoint admiten prompt caching, mantenga sin cambios el orden del prompt del sistema y de los esquemas de herramientas, y después compruebe los datos reales de cached tokens.

Paso 4. Evaluar la economía y la calidad de la solución

Compare las métricas finales con la baseline original. Mantenga un cambio solo si la tarea de control sigue cumpliendo el mismo criterio de calidad y el tiempo o gasto medido mejora en su conjunto de ejecuciones.

Recomendaciones para configurar entornos de agentes

1. Reduzca el conjunto de herramientas por rol: un agente de lectura no necesita funciones de escritura; compruebe si esto reduce el input real sin perjudicar el resultado.
2. Conserve un prefijo estable: si se admite caching, no cambie el orden de las reglas comunes sin necesidad y compruebe los cached tokens en vez de asumir un descuento.
3. Ponga límites al ciclo: establezca un número finito de intentos y una condición de parada explícita adecuada para la tarea concreta.

Casos límite y errores habituales

• Error: desactivar esquemas de validación críticos. Si se recorta demasiado la descripción de un esquema de herramienta, el modelo puede enviar JSON no válido y provocar una cadena de solicitudes repetidas.
• Error: confiar ciegamente en afirmaciones de ahorro de redes sociales. El efecto de optimizar el contexto depende de la estructura del repositorio y del tamaño medio de los archivos.
• Error: falta de telemetría transparente. Si el endpoint no devuelve estadísticas separadas de input/cache tokens, no estime el uso de caché a partir de supuestos; marque el valor como desconocido.