# ¿Cómo se establece un límite de gasto estricto para una tarea de un agente de programación? > Un límite de gasto estricto debe aplicarse antes de cada llamada a un modelo o herramienta de pago mediante una puerta de enlace que controle el presupuesto de la tarea. Reserve el coste máximo, concilie el uso real, rechace llamadas que no quepan y detenga el agente con un punto de control útil. # ¿Cómo se establece un límite de gasto estricto para una tarea de un agente de programación? Un presupuesto estricto es un problema de control de admisión. Antes de cualquier llamada facturable, una puerta de enlace fiable debe demostrar que el peor coste permitido cabe en el saldo restante. Las alertas posteriores no pueden detener un exceso ya producido. El diseño debe incluir entrada, salida máxima, reintentos, fallbacks, subagentes, embeddings, búsquedas, sandboxes y cualquier herramienta de pago. ## Separe límites estrictos de objetivos flexibles Use tres valores: | Control | Propósito | Comportamiento | |---|---|---| | Objetivo | Coste esperado | Avisar o elegir un plan más barato | | Límite flexible | Umbral de escalado | Pedir aprobación o degradar calidad | | Límite estricto | Gasto máximo autorizado | Rechazar antes de iniciar la siguiente llamada | Por ejemplo: objetivo de $0.60, aprobación a $0.90 y parada a $1.00. El límite estricto debe estar en el servidor, no solo en el prompt. ## Pase toda acción de pago por una puerta de enlace Entregue al agente credenciales breves que solo llamen a su gateway. Este añade `task_id`, consulta el presupuesto, estima la acción y reserva fondos o rechaza. No exponga una clave que permita evitar la contabilidad. Aplique lo mismo a búsqueda, sandboxes, ejecución y recuperación de pago. ## Reserve antes y concilie después Calcule el máximo con tokens de entrada conocidos y salida máxima. Reserve atómicamente, haga la llamada y sustituya la reserva por el uso real. ```text remaining = hard_limit - committed_cost - open_reservations worst_case = input_cost + max_output_cost + tool_allowance if worst_case > remaining: reject("task_budget_exceeded") else: reserve(worst_case) call_provider() reconcile(actual_cost) ``` La reserva atómica impide que dos subagentes gasten el mismo saldo. ## Tarifique con una tabla versionada Guarde la tarifa usada en cada estimación. Los precios cambian y un informe posterior no debe recalcular el pasado con la tarifa actual. Si el proveedor devuelve el coste definitivo, conserve estimación y cargo final. Si solo devuelve tokens, use la versión de tarifa elegida antes de la llamada. Añada margen para herramientas inciertas o rechace lo que no pueda acotarse. ## Haga seguro el streaming Reserve toda la salida permitida antes de abrir el stream. Concilie el uso cuando exista, pero no presuponga que cerrar el cliente detiene de inmediato la facturación. La cancelación es una optimización, no la frontera de control. Añada límites por llamada y timeout. El límite total sigue cubriendo streams, reintentos y fallbacks. ## Incluya reintentos y subagentes Cada intento carga el mismo libro mayor principal. Un reintento con presupuesto nuevo anula el límite. Use presupuestos jerárquicos: | Libro mayor | Límite | Regla | |---|---:|---| | Tarea principal | $1.00 | Techo absoluto | | Subagente de implementación | $0.55 | No supera el saldo principal | | Subagente de pruebas | $0.25 | Devuelve la reserva no usada | | Revisión final | $0.20 | Solo se ejecuta si queda saldo | Los límites secundarios son asignaciones, no dinero adicional. ## Deténgase con un punto de control útil Cuando una acción no quepa, devuelva un error tipado. El agente no debe reintentar indefinidamente. Genere con el contexto existente un punto de control que incluya: * cambios completados y pruebas; * trabajo pendiente y acción bloqueada; * estado actual del repositorio; * presupuesto adicional estimado; * token de reanudación o ID de tarea. Así la parada se convierte en un traspaso controlado. ## Use controles del proveedor como respaldo Los límites de cuenta reducen el radio de impacto, pero rara vez son precisos por tarea. Pueden mezclar repositorios, actualizarse tarde u omitir herramientas. Con una puerta multimodelo como Atlas Cloud, mantenga el libro mayor autoritativo en su orquestación y registre los ID de uso para conciliación. El límite seguirá vigente aunque cambie el modelo. ## Pruebe el límite como control financiero Pruebe concurrencia, streams largos, timeouts, uso ausente, reintentos, fallbacks y fallos del libro mayor. Si el servicio presupuestario falla, rechace por defecto. La suma de costes y reservas nunca debe superar el límite. ## En resumen Un límite real se aplica antes del gasto, con reservas atómicas y un libro mayor para toda acción facturable. Si el sistema solo avisa después, es monitorización, no un límite estricto. ## FAQ ### ¿max_tokens es un límite monetario estricto? No. Limita la longitud de una respuesta, no el coste total, los tokens de entrada, los reintentos, los cambios de modelo ni las herramientas. Un límite monetario requiere un libro mayor alrededor de toda acción facturable. ### ¿Dónde debe aplicarse el presupuesto de un agente? En una puerta de enlace o capa de orquestación del servidor por la que deban pasar todas las llamadas a modelos y herramientas de pago. Los contadores del cliente pueden omitirse o sufrir carreras con concurrencia. ### ¿Cómo se presupuesta una respuesta en streaming? Reserve el coste máximo permitido antes de abrir el stream y concilie el uso informado al cerrarlo. Cancele en el proveedor cuando sea posible, pero no dependa solo de la cancelación. ### ¿Los reintentos deben compartir el presupuesto original? Sí. Reintentos, alternativas, subagentes y evaluaciones deben cargar el mismo libro mayor salvo que el usuario apruebe un presupuesto separado. ### ¿Qué ocurre si el presupuesto restante es insuficiente? Rechace la siguiente llamada facturable y pida al agente un punto de control con el contexto disponible. Debe indicar trabajo completado, pendientes y presupuesto adicional necesario. ### ¿Pueden los límites de cuenta del proveedor sustituir un límite por tarea? Normalmente no. Protegen toda la cuenta y pueden actualizarse de forma asíncrona. Una puerta de enlace por tarea aísla de inmediato; el control de cuenta sirve como respaldo.