Source: https://aiprimetech.io/es/blog/agent-cost-control/ Jun 25, 2026 · 6 min · Agentes # Cómo evitar que los bucles de agentes agoten tu presupuesto de API A Por [AI Prime Tech](https://aiprimetech.io/es/) · Con asistencia de IA Redactaré el artículo directamente, con tácticas de ingeniería concretas, una tabla comparativa y ejemplos prácticos. Lo mantendré centrado en el comportamiento real de los bucles y los controles de costes, y me aseguraré de que termine con conclusiones que se puedan aplicar.## La forma más rápida de agotar un presupuesto de API Una vez vi cómo un agente de programación «sencillo» convertía una solicitud de usuario de 400 tokens en una partida de factura de 28,000 tokens en menos de dos minutos. El patrón resultaba dolorosamente familiar: el agente invocaba una herramienta de búsqueda, resumía los resultados, releía su propio resumen, volvía a consultar la misma herramienta con una formulación ligeramente distinta y luego ampliaba el contexto hasta que cada turno incluía toda la conversación, la mitad del repositorio y un rastro de planes fallidos. El modelo no tenía ningún problema. El diseño del bucle era el problema. Ese es el problema central de los sistemas basados en agentes: el coste no crece en función de los prompts del usuario, sino del comportamiento del bucle. Un solo bucle mal diseñado puede multiplicar: - los tokens de entrada debido a un contexto cada vez mayor, - los tokens de salida debido a un «razonamiento» prolijo, - el gasto en herramientas debido a las llamadas repetidas, - y la latencia debido a los reintentos en serie. Si estás desarrollando agentes para producción, el verdadero trabajo no es «hacer que el modelo sea más inteligente». Es «hacer que el bucle sea más barato, más corto y más difícil de descontrolar». ## Por qué los bucles de agentes disparan los costes Un turno de chat normal tiene una entrada y una salida. Un bucle de agente sigue una secuencia como esta: - el usuario hace una pregunta, - el modelo planifica, - el modelo invoca una herramienta, - la herramienta devuelve datos, - el modelo lee los datos, - el modelo decide el siguiente paso, - se repite. Cada iteración añade nuevos tokens al prompt de la siguiente. Si sigues añadiendo las salidas completas de las herramientas y los razonamientos anteriores, el prompt crece aproximadamente de forma escalonada. En la práctica, esto genera tres factores que multiplican los costes: - Acumulación de contexto: cada paso arrastra los pasos anteriores. - Llamadas redundantes a herramientas: se invoca la misma herramienta con argumentos ligeramente distintos. - Reintentos descontrolados: el modelo sigue «probando una cosa más» cuando ya ha hecho suficiente. Un problema habitual es que el desperdicio de tokens suele ser invisible hasta que examinas las trazas de cada ejecución. La respuesta final puede ser concisa, pero la cadena oculta puede ser 10x mayor que la salida visible para el usuario. ### Un modelo de costes sencillo Si un bucle ejecuta N pasos, cada uno con: - C tokens de contexto arrastrado, - I tokens de salida de herramientas reintroducidos en el contexto, - O tokens de salida del modelo, entonces el total aproximado es: ``` total_tokens ≈ N * (C + I + O) ``` Esa estimación es optimista, porque C suele crecer a medida que continúa el bucle. En un agente real, los últimos turnos suelen ser los más caros. ## Los mecanismos de control que realmente importan Hay varios puntos sobre los que puedes actuar. La clave está en combinarlos. | Control | Qué reduce | Caso de uso ideal | Contrapartida | Límites de pasos | Bucles descontrolados | Cualquier agente con herramientas | Puede detenerse antes de tiempo en tareas difíciles | Recorte del contexto | Tokens de entrada | Tareas de larga duración | Riesgo de perder historial útil | Subagentes más baratos | Gasto en trabajo rutinario | Búsqueda, extracción, clasificación | Sobrecarga de coordinación | Caché de resultados de herramientas | Gasto en llamadas repetidas a herramientas | Fuentes estables, consultas repetidas | Datos obsoletos e invalidación | Observabilidad del gasto | Facturas inesperadas | Sistemas en producción | Requiere trabajo de instrumentación | Condiciones de parada del bucle | Bucles infinitos o casi infinitos | Agentes poco fiables | Hay que definir qué es «suficientemente bueno» Las configuraciones de producción más eficaces los utilizan todos. ## 1) Limita los pasos de forma estricta Esta es la solución más sencilla y más infravalorada: si no estableces un máximo estricto, estás confiando en que el modelo se detenga por sí solo. Suelo empezar con: - 3–5 pasos para tareas acotadas, - 6–8 pasos para tareas de complejidad moderada, - más solo cuando hay una razón de peso. Un buen límite no es solo una válvula de seguridad. Obliga a descomponer mejor la tarea. Si el agente solo dispone de cuatro movimientos, tiende a: - solicitar antes la herramienta adecuada, - evitar desvíos exploratorios, - y converger más rápido hacia una respuesta útil. ### Ejemplo de controlador de bucle ``` MAX_STEPS = 5 for step in range(MAX_STEPS): action = model.next_action(state) if action.type == "final": return action.final_answer observation = run_tool(action.tool_name, action.arguments) state = update_state(state, action, observation) raise RuntimeError("Agent stopped after step cap") ``` Un problema habitual: los límites de pasos deben aplicarse a todo el plan, no a cada subrutina de forma independiente. De lo contrario, trasladas la explosión de costes del agente principal a los auxiliares anidados. ## 2) Recorta el contexto en cada turno La mayoría de los agentes arrastran demasiado historial. No necesitan todas las respuestas anteriores de las herramientas, especialmente si una respuesta era extensa y solo importaba un detalle. En la práctica, he obtenido los mejores resultados con una política de memoria por capas: - Conservar literalmente: solicitud del usuario, objetivo actual, decisiones finales, restricciones pendientes de resolver. - Resumir: razonamiento anterior, intentos de vías alternativas, salidas extensas de herramientas. - Descartar: hipótesis sin salida, resultados de herramientas duplicados, borradores intermedios antiguos. ### Qué conservar Un objeto de estado compacto funciona mejor que reproducir la transcripción sin procesar: ``` { "goal": "Find the failing endpoint and propose a fix", "constraints": [ "No schema changes", "Must preserve backward compatibility" ], "known_facts": [ "500s started after deploy 1842", "Only /v1/search is affected" ], "open_questions": [ "Is the new cache layer returning stale payloads?" ], "step": 3 } ``` Esto es mucho más barato que proporcionar al modelo 20 turnos de «pensar en voz alta». ### Patrón práctico de recorte Usa tres búferes: - working_set: turno actual, resultados de herramientas y plan activo. - summary_memory: historial comprimido. - archive: cualquier información que puedas necesitar para auditorías, pero no para el contexto del prompt. El agente solo ve working_set + summary_memory. Cuando working_set crece demasiado, resúmelo en summary_memory. El problema aquí es la desviación del resumen. Si tu resumidor pierde información, puede borrar restricciones y hacer que el agente repita errores. Prefiero conservar los hechos estructurados por separado de los resúmenes de formato libre para que el modelo no tenga que inferirlos a partir de la prosa. ## 3) Usa subagentes más baratos para tareas sencillas No todos los pasos requieren tu mejor modelo. Si la tarea consiste en: - extraer campos de JSON, - clasificar un ticket, - comprobar si un archivo ha cambiado, - o generar una consulta de búsqueda breve, a menudo basta con un modelo más pequeño y barato. Reserva el modelo caro para la planificación, la síntesis y la resolución de ambigüedades. ### Reparto habitual - Agente principal: razona sobre la tarea y decide cuándo detenerse. - Subagente: realiza tareas acotadas, como búsquedas, extracción o normalización. - Verificador: comprueba el formato, la integridad y los errores evidentes de los resultados. Una arquitectura práctica: ``` User -> Orchestrator (strong model) -> Search agent (cheap model) -> Extract agent (cheap model) -> Final synthesis (strong model) ``` ### Por qué funciona El modelo principal se centra en el flujo de control en lugar de hacerlo todo por sí mismo. Al subagente se le pueden imponer restricciones mediante el prompt y un límite estricto de tokens. Ejemplo de prompt para un subagente de búsqueda: ``` Return only: 1. the best search query, 2. 3 likely source categories, 3. no explanation. ``` Ese tipo de contrato acotado mantiene los resultados breves y predecibles. Si tu plataforma te ofrece acceso asequible a varios modelos, aquí es donde compensa: un modelo potente para la orquestación, otro más barato para las subtareas repetitivas y ningún motivo para gastar tokens prémium en análisis sintácticos rutinarios. ## 4) Tómate en serio la caché de resultados de herramientas Los bucles de agentes suelen pagar varias veces por la misma información: - lecturas repetidas de archivos, - consultas repetidas a bases de datos, - búsquedas web repetidas, - llamadas repetidas de generación de embeddings o recuperación de información. Almacenar en caché los resultados de las herramientas es uno de los cambios con mayor retorno de la inversión que puedes hacer. ### Usa claves semánticas para la caché, no texto sin procesar Una caché basada en el prompt sin procesar no encuentra coincidencias si la redacción cambia ligeramente. Las mejores claves se basan en la intención normalizada: ``` def cache_key(tool_name, args): normalized = normalize_args(args) return f"{tool_name}:{hash(normalized)}" ``` Ejemplo de entrada de caché: ``` { "tool": "repo_search", "query": "auth middleware rate limit bug", "result": { "files": ["src/middleware/auth.py", "src/api/routes.py"], "ts": 1710001123 } } ``` ### Cuándo resulta más útil la caché - Agentes de inspección de repositorios, - búsqueda de documentos, - bases de conocimiento estables, - transformaciones deterministas, - recuperación repetida de información en flujos de trabajo de varios turnos. ### Cuándo puede perjudicar la caché - datos que cambian rápidamente, - resultados específicos de cada usuario, - cualquier información que deba estar actualizada en un momento concreto. El problema habitual es almacenar en caché los resultados de las herramientas sin informar al agente de su vigencia. Si el modelo cree que ha recibido datos en tiempo real cuando en realidad proceden de la caché, puede tomar malas decisiones. Incluye marcas de tiempo o intervalos de validez en los metadatos de la herramienta. ## 5) Incluye el gasto en el panel Si solo supervisas la latencia y la tasa de éxito, pasarás por alto el verdadero modo de fallo: el éxito costoso. Necesitas observabilidad por ejecución de: - tokens de entrada, - tokens de salida, - llamadas a herramientas, - latencia de las herramientas, - gasto total, - número de pasos, - motivo de detención. ### Esquema mínimo de eventos ``` { "run_id": "r_8f2c", "step": 4, "model": "gpt-5.5", "input_tokens": 1842, "output_tokens": 221, "tool_name": "repo_search", "tool_latency_ms": 312, "estimated_cost_usd": 0.087, "stop_reason": "step_cap" } ``` ### Qué supervisar en la práctica - Tokens por tarea completada con éxito: el indicador de coste más claro. - Tokens por paso: permite detectar prompts sobredimensionados. - Llamadas repetidas a herramientas: suelen indicar un fallo de planificación. - Distribución de los motivos de detención: si muchas ejecuciones terminan por alcanzar el límite, tu agente no planifica lo suficiente. Uno de los gráficos más útiles es el coste por tipo de tarea. Algunas categorías serán costosas por naturaleza. Eso está bien. Lo que interesa detectar es la tarea que debería ser barata, pero no lo es. ## 6) Detén pronto los bucles descontrolados Un bucle debería detenerse por más motivos que «he alcanzado el límite de pasos». Entre las condiciones de detención útiles se incluyen: - el modelo ha producido una respuesta final, - la misma llamada a una herramienta se repite sin aportar información nueva, - el incremento de confianza o utilidad está por debajo del umbral, - la tarea está resuelta según un verificador, - el plan se ha estancado. ### Ejemplo de interrupción de bucles ``` seen_calls = set() for step in range(MAX_STEPS): action = model.next_action(state) signature = (action.tool_name, canonicalize(action.arguments)) if signature in seen_calls: return fail("repeated tool call with no new information") seen_calls.add(signature) observation = run_tool(action.tool_name, action.arguments) state = update_state(state, action, observation) if verifier_says_done(state): return finalize(state) ``` Esto permite detectar un modo de fallo muy común: el modelo «quiere ser útil» y se limita a reformular la misma consulta. ### Otro mecanismo de protección útil: condicionar la continuación a la utilidad Si un paso no cambia lo suficiente el estado, no sigas adelante. Puede ser tan sencillo como: - no se han encontrado archivos nuevos, - no se han extraído entidades nuevas, - no ha mejorado la confianza en la respuesta, - no se han añadido pruebas nuevas. La métrica exacta depende de la tarea, pero es esencial contar con alguna noción de ganancia marginal. ## Qué ocurre realmente cuando ajustas bien todo esto Una vez que optimizas el bucle, el agente suele mejorar de formas que al principio pueden pasar desapercibidas: - Se vuelve menos locuaz y más resolutivo. - Solicita antes la herramienta adecuada. - Produce menos ciclos de «sigo investigando». - Se vuelve más barato y más rápido porque menos turnos implican menos contexto y menos latencia. La contrapartida importante es que los límites estrictos y los recortes agresivos pueden volver frágil el sistema ante tareas realmente difíciles. Así que no finjas que el agente está «resolviendo» problemas cuando en realidad solo está agotando el tiempo disponible. Refleja esa situación con honestidad en los registros y en los mensajes dirigidos al usuario. Mi regla general: optimizar para lograr una competencia acotada en lugar de una exploración sin fin. ## Una configuración práctica para producción Si fuera a poner un agente en producción mañana, empezaría con: - MAX_STEPS = 5 - estado estructurado, en lugar de volver a enviar toda la transcripción - memoria resumida después de cada turno - subagentes económicos para búsqueda y extracción - caché de resultados de herramientas con metadatos de vigencia - registro de tokens y costes por ejecución - detector de llamadas repetidas - motivos explícitos de parada Esa configuración no es glamurosa, pero es lo que evita que la factura crezca más rápido que el producto. ## Conclusiones prácticas - Limita primero los pasos; es la protección más barata contra los bucles descontrolados. - Recorta el contexto de forma agresiva y mantén el estado estructurado separado de los resúmenes. - Usa subagentes más económicos para tareas específicas en lugar de gastar tokens de modelos de gama alta en todo. - Almacena en caché las salidas de herramientas que puedan reutilizarse, pero indica su vigencia para que el modelo no confíe ciegamente en datos obsoletos. - Registra el gasto por ejecución, por paso y por llamada a herramienta para detectar de inmediato los aumentos de costes. - Detén los bucles cuando haya repetición, estancamiento o una finalización verificada, no solo cuando se agoten los recursos. - Diseña para una competencia acotada: una solución suficientemente buena, rápida y predecible siempre supera a una ingeniosa pero cara. [Agentes](/es/blog/tag/agents/)[Ingeniería](/es/blog/tag/engineering/)[API](/es/blog/tag/api/) A [AI Prime Tech](https://aiprimetech.io/es/) AI Prime Tech publica este blog. Los artículos se redactan con asistencia de IA; comprueba los detalles específicos de cada versión, como los identificadores de modelos, los precios y los límites, en la documentación oficial antes de basarte en ellos. Obtén acceso más económico a la API de Claude Una sola clave de API para Claude Opus 5.5, Sonnet 5, Haiku 4.5 y Fable 5.1, además de GPT-6 modelos. Pago por uso, sin suscripción. [Obtén tu clave de API →](/register) AI Prime Tech es una pasarela de API independiente de terceros. Claude™ y Anthropic® son marcas comerciales de Anthropic, PBC. No se implica ninguna afiliación ni respaldo.