Cómo limitar el costo de un agente de IA por ejecución con OpenAI Responses API
OpenAI publicó un patrón oficial para asignar un presupuesto independiente a cada ejecución de un agente construido con Responses API. En lugar de confiar únicamente en límites generales del proyecto, la aplicación calcula cuántos tokens podría consumir la siguiente llamada, reserva ese costo máximo antes de ejecutarla, registra el costo real cuando recibe la respuesta y detiene el workflow si el siguiente paso superaría el dinero disponible. El ejemplo oficial utiliza precios ficticios deliberadamente, por lo que en producción deben cargarse siempre las tarifas actuales del modelo elegido.
Cómo construir un controlador de presupuesto para agentes y evitar que un workflow consuma más de lo permitido
Cómo limitar el costo de cada ejecución de un agente de IA
OpenAI propone un controlador que asigna un presupuesto individual a cada run, estima el costo antes de la siguiente llamada y detiene el agente antes de superar el dinero disponible.
Limitar el costo de OpenAI API se vuelve más importante cuando una aplicación evoluciona desde una respuesta sencilla hasta convertirse en un agente capaz de realizar varias llamadas para completar una sola tarea.
Un agente puede razonar, consultar herramientas, analizar resultados y regresar nuevamente al modelo. Por ello, una sola solicitud del usuario puede producir múltiples llamadas a Responses API antes de obtener el resultado final.
El 17 de agosto de 2026, OpenAI publicó en su Cookbook un patrón denominado “Build a per-run spending controller with the Responses API”. Su objetivo es proporcionar a cada ejecución un presupuesto propio y decidir antes de cada llamada si todavía puede permitirse continuar.
Por qué un límite mensual no resuelve el costo de cada agente
Los límites generales de una organización o proyecto sirven para administrar consumo agregado. Sin embargo, no responden necesariamente una pregunta operacional importante: ¿esta tarea concreta puede permitirse una llamada adicional?
Imagina un agente de soporte al que asignas una cantidad máxima para resolver cada ticket. El sistema puede haber gastado poco durante el primer paso, aunque la siguiente llamada potencial ya sea mayor que el dinero disponible.
Límite de organización
Controla gasto agregado, pero no necesariamente el presupuesto de una tarea específica.
Límite de proyecto
Ayuda a separar aplicaciones, aunque varias ejecuciones comparten el mismo consumo.
Presupuesto por ejecución
Permite decidir si una tarea concreta puede continuar antes de gastar más.
Además, OpenAI advierte que los project spending limits pueden no aplicarse inmediatamente. Las alertas tampoco funcionan como un interruptor sincrónico antes de cada solicitud.
Qué es un per-run spending controller
El controlador propuesto por OpenAI es lógica que vive
dentro de tu propia aplicación. No es un parámetro
max_dollars integrado directamente en Responses API.
Antes de cada solicitud, el sistema calcula el consumo potencial. Si todavía cabe dentro del presupuesto, reserva temporalmente esa cantidad y realiza la llamada.
Ejemplo conceptual de una ejecución
Supongamos que una tarea comienza con un presupuesto máximo de US$0.02. Después del primer paso, el costo real acumulado es US$0.01.
Si la siguiente solicitud puede llegar a costar US$0.0146 en el escenario de precios ficticios utilizado por OpenAI, el controlador no la envía porque existe solamente US$0.01 disponible.
Cómo funciona el controlador de gasto paso a paso
quiere ejecutar otro paso
estima + reserva
ejecuta o se detiene
Define un presupuesto máximo
Cada tarea, usuario, cliente o workflow recibe una cantidad máxima de gasto.
Cuenta tokens de entrada
Antes de ejecutar la respuesta, la aplicación calcula cuántos tokens utilizará la entrada correspondiente.
Estima el peor caso
Combina tokens de entrada con el máximo de tokens de salida permitido para reservar suficiente presupuesto.
Comprueba el saldo
Si la reserva potencial excede el dinero restante, el agente se detiene antes de enviar la llamada.
Ejecuta Responses API
Solamente después de reservar el presupuesto se realiza la solicitud real.
Liquida el costo real
Cuando llega la respuesta,
response.usage permite calcular
el consumo observado.
Devuelve lo no utilizado
Si la respuesta costó menos que la reserva, la diferencia regresa al presupuesto disponible.
Responses API puede contar tokens antes de generar una respuesta
OpenAI proporciona el endpoint
POST /responses/input_tokens
para obtener el número de tokens de entrada
que utilizaría una solicitud compatible.
Este paso es útil para un controlador porque permite estimar el consumo antes de generar realmente la respuesta.
from openai import OpenAI
client = OpenAI()
request = {
"model": MODEL,
"input": user_request
}
token_count = client.responses.input_tokens.count(
**request
)
input_tokens = token_count.input_tokensSi la solicitud incluye instrucciones, imágenes, archivos, historial, schemas de herramientas u otro contexto, esos elementos también pueden afectar los tokens de entrada.
Por ello, el conteo y la ejecución deberían utilizar configuraciones coherentes para evitar que la estimación subestime lo que finalmente se envía.
Por qué debes reservar el costo antes de hacer la llamada
Comprobar únicamente cuánto dinero queda no es suficiente. También necesitas evitar que dos llamadas simultáneas gasten el mismo saldo disponible.
Por eso, el patrón de OpenAI utiliza una reserva temporal. El presupuesto mantiene dos cantidades diferentes: dinero realmente gastado y dinero pendiente asociado con solicitudes todavía en curso.
Si la operación no cumple esta condición, la siguiente llamada no debería enviarse.
Cuando una aplicación utiliza varios workers, esa reserva debe coordinarse mediante almacenamiento compartido para evitar que procesos diferentes consuman el mismo presupuesto.
Cómo calcular el costo real después de recibir la respuesta
Las respuestas de Responses API incluyen información de
usage con tokens de entrada, salida,
total y detalles adicionales.
| Dato | Qué representa | Uso en el controlador |
|---|---|---|
input_tokens | Tokens procesados como entrada. | Calcula costo de entrada. |
cached_tokens | Parte de la entrada recuperada mediante caché. | Aplica la tarifa correspondiente cuando exista. |
cache_write_tokens | Tokens relacionados con escritura de caché cuando el modelo los reporta. | Deben contemplarse si tienen una tarifa propia. |
output_tokens | Tokens utilizados en la salida. | Calcula el costo de generación. |
total_tokens | Total reportado por la respuesta. | Sirve para comprobar coherencia del consumo. |
El controlador debe utilizar la tarifa verificada del modelo y modalidad de procesamiento que realmente utilizó la solicitud.
Cómo convertir tokens en costo
La lógica general consiste en multiplicar cada tipo de token por su tarifa correspondiente.
Las tarifas dependen del modelo, modalidad, región y otras condiciones vigentes. Consulta siempre el pricing oficial de OpenAI antes de utilizar valores en producción.
Además, los reasoning tokens ya forman parte del total de output correspondiente en el accounting descrito por el ejemplo oficial.
Responses API ofrece otros límites que complementan el presupuesto
Un controlador monetario no debería ser la única protección. Responses API dispone de parámetros adicionales que pueden reducir cuánto trabajo puede realizar una sola solicitud.
Estos límites controlan diferentes dimensiones.
max_output_tokens, por ejemplo,
no es equivalente a un presupuesto en dólares,
aunque ayuda a limitar el peor caso de salida.
Ejemplo simplificado de un controlador de presupuesto
El Cookbook oficial incluye una implementación de referencia más completa. El siguiente ejemplo resume el patrón sin copiar esa implementación.
from openai import OpenAI
client = OpenAI()
BUDGET = 0.05
spent = 0.0
def run_step(prompt, rates):
global spent
request = {
"model": rates["model"],
"input": prompt
}
count = client.responses.input_tokens.count(
**request
).input_tokens
estimated_max = (
count * rates["input"]
+ rates["max_output_tokens"] * rates["output"]
) / 1_000_000
remaining = BUDGET - spent
if estimated_max > remaining:
return {
"status": "stopped",
"reason": "budget_exceeded"
}
response = client.responses.create(
**request,
max_output_tokens=rates["max_output_tokens"],
store=False
)
usage = response.usage
actual_cost = (
usage.input_tokens * rates["input"]
+ usage.output_tokens * rates["output"]
) / 1_000_000
spent += actual_cost
return {
"status": "completed",
"text": response.output_text,
"spent": spent,
"remaining": BUDGET - spent
}El ejemplo de producción necesita algo más que una variable spent
Si varias llamadas pueden ejecutarse al mismo tiempo, comprobar simplemente el saldo antes de cada solicitud introduce una condición de carrera.
Dos workers podrían ver US$0.02 disponibles, ejecutar cada uno una operación potencial de US$0.015 y superar juntos el presupuesto.
Proceso único
- Lock alrededor de la reserva
- Saldo gastado
- Saldo pendiente
- Liquidación después de respuesta
Varios workers
- Store compartido
- Operación atómica de reserva
- Idempotencia
- Estado persistente del presupuesto
En producción, Redis, una base de datos transaccional u otro mecanismo compartido pueden utilizarse para coordinar reservas entre procesos.
Cómo aplicar el presupuesto a un agente con varios pasos
El patrón resulta especialmente útil cuando un agente ejecuta un loop donde cada respuesta puede decidir si necesita otra llamada.
Ejemplo: agente que investiga un ticket de soporte
Antes de cada nueva llamada al modelo, el controlador vuelve a comprobar el saldo. Si no existe suficiente presupuesto para cubrir el peor caso de la siguiente solicitud, el workflow se detiene.
Puedes asignar diferentes presupuestos según cliente o tarea
No todas las ejecuciones tienen el mismo valor. Una clasificación simple puede justificar menos gasto que una investigación empresarial compleja.
| Tipo de workflow | Política posible | Objetivo |
|---|---|---|
| FAQ simple | Presupuesto pequeño. | Evitar loops innecesarios. |
| Lead qualification | Presupuesto por prospecto. | Mantener costo comercial controlado. |
| Investigación | Presupuesto más amplio. | Permitir varios pasos justificables. |
| SaaS multiusuario | Budget según plan del cliente. | Proteger margen unitario. |
Esta política la define tu aplicación. OpenAI no asigna automáticamente un presupuesto monetario individual por cliente final.
El controlador del ejemplo oficial no cubre todos los cargos posibles
Esta limitación es especialmente importante. El patrón publicado por OpenAI se concentra en costos de tokens del modelo.
Por tanto, un agente que utiliza herramientas adicionales puede necesitar un ledger más completo.
Hosted tools
Herramientas alojadas pueden tener cargos propios además de tokens relacionados.
Web Search
Las búsquedas pueden generar cargos por herramienta además del consumo del modelo.
Storage
Almacenamiento u otros servicios asociados pueden requerir accounting independiente.
Regional pricing
El precio puede variar cuando existen modalidades regionales específicas.
Processing tiers
Modalidades distintas al procesamiento contemplado por el ejemplo necesitan reglas propias.
Background runs
Solicitudes asincrónicas requieren seguimiento diferente porque pueden terminar posteriormente.
Background mode necesita un controlador diferente
El ejemplo oficial se concentra en solicitudes síncronas y no streaming dentro del processing tier contemplado por la receta.
Una respuesta ejecutada en background puede regresar
inicialmente como queued o
in_progress.
En ese caso, no puedes liquidar inmediatamente el presupuesto como si la operación hubiese terminado. Debes mantener la reserva mientras esperas el estado final y el usage definitivo.
Los reintentos también pueden afectar el presupuesto
Una solicitud puede fallar desde la perspectiva del cliente aunque el proveedor ya haya recibido y comenzado a procesar la operación.
Si la aplicación reintenta automáticamente, existe la posibilidad de producir gasto adicional. Por ello, la implementación de referencia de OpenAI trata con cuidado los reintentos y los casos donde el costo final es incierto.
Respuesta conocida
El sistema puede liquidar la reserva utilizando el usage reportado.
Costo incierto
Es más seguro bloquear el run que asumir que una solicitud interrumpida no generó ningún cargo.
Casos de uso para empresas de México y Latinoamérica
El presupuesto por ejecución puede ser especialmente útil para empresas que venden servicios de IA o manejan gran cantidad de workflows.
Agencias
Asignar un presupuesto máximo a cada agente o cliente.
SaaS
Relacionar límites de consumo con diferentes planes comerciales.
Soporte
Evitar que un ticket individual consuma demasiadas iteraciones.
Investigación
Dar más presupuesto a tareas donde varios pasos sí generan valor.
Automatización
Limitar loops que utilizan modelos y herramientas repetidamente.
Multiagente
Compartir un presupuesto global entre varios agentes o subagentes.
El verdadero beneficio está en conocer el costo por trabajo realizado
Un presupuesto por run también mejora la capacidad para medir unit economics.
En lugar de mirar únicamente la factura mensual, puedes registrar cuánto cuesta resolver un ticket, analizar un documento, calificar un lead o completar una investigación.
Esta fórmula es un marco empresarial de ejemplo. No forma parte del controlador oficial de OpenAI.
Cuando conoces ese número puedes comparar modelos, prompts y arquitecturas por resultado económico en lugar de mirar solamente el precio por millón de tokens.
Tres niveles de control de gasto que conviene combinar
Por ejecución
Evita que una sola tarea consuma más de lo permitido.
Por cliente
Controla el consumo acumulado según contrato o plan.
Por proyecto
Mantiene una protección financiera adicional sobre todo el sistema.
Estas capas no se sustituyen entre sí. Cada una responde a un nivel distinto de riesgo económico.
Mejores prácticas para controlar costos de agentes
Antes de la ejecución
- Define el presupuesto máximo
- Verifica precios actuales
- Cuenta tokens de entrada
- Limita output máximo
- Reserva el peor caso
- Define límite de tools
Después de cada paso
- Lee response.usage
- Calcula el costo real
- Libera reserva no utilizada
- Actualiza saldo restante
- Registra la operación
- Detén el run si existe incertidumbre
Errores frecuentes al implementar un límite de gasto
Usar precios antiguos
Las tarifas pueden cambiar. Verifica siempre el pricing oficial.
Mirar solo output
La entrada, caché y otras modalidades también pueden afectar el costo.
No reservar antes
La concurrencia puede hacer que dos llamadas gasten el mismo saldo.
Ignorar tool costs
El presupuesto de tokens no incluye automáticamente todos los cargos adicionales.
Reintentar sin control
Un timeout no demuestra necesariamente que la operación anterior no produjo gasto.
Poner el límite en el prompt
El modelo no debería decidir cuánto dinero puede gastar. La política debe estar fuera del agente.
Preguntas frecuentes sobre límites de costo en OpenAI API
¿Responses API tiene un parámetro para indicar un máximo de dólares?
El patrón oficial utiliza un controlador implementado en la aplicación. No depende de un simple parámetro monetario dentro de cada llamada a Responses API.
¿Puedo limitar los tokens de salida?
Sí. Responses API dispone de max_output_tokens para establecer un límite superior de tokens generados, incluyendo los tokens correspondientes contemplados por esa métrica.
¿Puedo limitar las llamadas a herramientas?
Responses API dispone de max_tool_calls para limitar el total de llamadas a herramientas integradas procesadas durante la respuesta.
¿Puedo saber cuántos tokens tendrá la entrada antes de llamar al modelo?
Sí. OpenAI proporciona el endpoint /responses/input_tokens para contar tokens de entrada antes de generar una respuesta.
¿La respuesta devuelve cuántos tokens utilizó?
Sí. El objeto response incluye información de usage con tokens de entrada, salida y detalles adicionales.
Más dudas sobre presupuestos de agentes de IA
¿El ejemplo oficial utiliza precios reales?
No. OpenAI indica expresamente que los precios, nombres de modelos y límites del ejemplo son ficticios y no representan tarifas actuales.
¿El controlador cubre Web Search?
El ejemplo oficial cubre costos de tokens del modelo. Herramientas alojadas como Web Search pueden generar cargos adicionales que necesitan accounting separado.
¿Qué ocurre si la siguiente llamada supera el saldo?
El controlador debería detener el run antes de enviar esa solicitud.
¿Por qué se reserva dinero antes de llamar a la API?
Porque la aplicación todavía no conoce el costo exacto final y debe proteger el presupuesto contra el peor caso permitido.
¿Qué ocurre con el dinero reservado que no se utilizó?
Después de conocer el costo real, la diferencia entre la reserva y el gasto puede regresar al saldo disponible.
¿Puedo utilizar un presupuesto diferente por cliente?
Sí. La lógica del presupuesto pertenece a tu aplicación, por lo que puedes definir políticas diferentes por cliente, tarea o workflow.
¿Sirve para sistemas con varios agentes?
Sí, aunque el presupuesto compartido debe coordinarse de forma atómica para evitar que agentes paralelos reserven el mismo saldo.
Conclusión: el agente puede decidir qué hacer, pero no cuánto puede gastar
Los agentes introducen un problema económico diferente al de una llamada tradicional a un modelo. Una sola tarea puede generar varias iteraciones, herramientas y nuevos pasos.
Por ello, un presupuesto por ejecución coloca una frontera financiera alrededor del workflow. Antes de cada solicitud, la aplicación calcula si puede permitirse continuar.
Además, reservar el costo potencial protege contra concurrencia y permite liquidar posteriormente el gasto real utilizando la información de usage.
El patrón no sustituye presupuestos de proyecto, límites de tokens ni monitoreo global. Más bien, añade una capa de control en el punto donde se ejecuta cada tarea.
Para empresas de México y Latinoamérica que están construyendo agentes, SaaS o automatizaciones con OpenAI, este diseño puede ayudar a convertir un costo variable y difícil de prever en una política medible por cliente, tarea y resultado.
Fuentes oficiales
¿Quieres construir agentes de IA sin perder control de los costos?
En Zadrig Technology podemos ayudarte a diseñar agentes, automatizaciones y aplicaciones con OpenAI API, incorporando límites de consumo, métricas, herramientas y controles por cliente para que cada workflow tenga una estructura económica predecible.
Diseñar mi agente con control de costos →
