La primera vez que un agente de IA me sorprendió en coste no fue una tarea grande. Fue una pequeña que se atascó, se reintentó en bucle y corrió un modelo pesado en círculos hasta que me dio por mirar. El trabajo que produjo valía unos dos minutos de un motor barato. Los tokens que quemó, no.
Esa es la forma del problema. El gasto en tokens es invisible mientras ocurre y evidente un mes después, cuando llega la factura y la decisión que lo causó ya es historia. No puedes gestionar un coste que solo ves después de gastarlo.
Controlar el coste de la IA no va de buscar una suscripción más barata. Va de mover la decisión a donde le toca: la tarea concreta, con un número delante, antes de que los tokens se hayan ido.
El coste es un hecho por tarea, no del mes
Tu factura es un número. Tu trabajo son mil tareas, y son tremendamente desiguales. Un arreglo de copy de una línea y una migración de base de datos aparecen los dos como “uso de IA” en el extracto, pero uno debería costar un redondeo y el otro se gana su precio.
Cuando solo ves el total del mes, no puedes distinguirlos. No puedes encontrar la tarea que estuvo una hora en bucle. No puedes ver que la mitad de tu gasto se fue en ediciones triviales enrutadas, por defecto, a tu motor más caro. El agregado esconde justo la información que necesitarías para actuar.
Así que el primer movimiento no es un límite. Es visibilidad a nivel de tarea. Qué costó este run en tokens. Qué motor usó. Cuánto de eso fue el trabajo real y cuánto fueron reintentos. Hasta que no puedas responder eso por tarea, cada conversación sobre coste es una adivinanza.
Un presupuesto que la tarea no pueda superar a escondidas
Una vez ves el coste por tarea, puedes ponerle un tope.
Un presupuesto por tarea es una idea simple que casi ningún setup tiene. Antes de que arranque un run, decides el techo: este tipo de trabajo lleva un perfil ligero y un tope bajo, ese otro lleva un perfil fuerte porque se lo gana. La tarea corre dentro de ese sobre. Si lo revienta, se para y te avisa, en vez de gastarte el mes en silencio con un agente que se lió.
Esto importa por el modo de fallo con el que abrí. Los agentes no se pasan de gasto en las tareas que estabas mirando. Se pasan en la que se torció a las 2 de la mañana, se reintentó sola y no tenía techo contra el que chocar. Un presupuesto no está para exprimir los runs buenos. Está para cazar el run que perdió el hilo antes de que te cueste una cena fuera.
Los perfiles hacen esto vivible en vez de tedioso. No pones precio a cada tarea a mano. Defines unos pocos tramos, cheap, balanced, strong, y la tarea hereda un techo razonable de su tramo. La decisión manual ocurre una vez, en el tramo, no una vez por tarea.
El tope también cambia cómo se comporta un agente cuando se atasca, que es de lo que va todo esto. Sin techo, un run confundido sigue intentándolo, porque nada le dice que pare. Con techo, llegar al límite es una señal. Saca a la superficie la tarea que necesita un humano en vez de moler tu presupuesto a oscuras. Un presupuesto es tanto una alarma como una cartera.
Enruta el trabajo barato a motores baratos
La fuente de desperdicio más grande y más aburrida es mandar trabajo trivial a un modelo frontier porque es a lo que la herramienta apuntó por defecto.
Un retoque de copy no necesita tu motor más fuerte. Tampoco un rename, un comentario, un refactor pequeño que los tests ya cubren. Si todo eso va al mismo modelo caro que tus migraciones arriesgadas, estás pagando precio frontier por trabajo que un modelo ligero termina igual de bien. El routing por coste es el arreglo: el perfil de la tarea decide qué motor la recoge, y el trabajo barato aterriza en motores baratos por defecto.
Este es el mismo argumento que enrutar cada tarea al motor adecuado, leído con la lente del coste. Allí el punto era encaje y disponibilidad. Aquí es la factura. Es el mismo mecanismo. Una vez la unidad que enrutas es la tarea y no el modelo, el control de coste deja de ser una feature aparte y pasa a ser una propiedad de cómo se despacha el trabajo — que es lo que más importa cuando corres varias sesiones de agentes en paralelo y cada una gasta en silencio.
El motor que no pagas en absoluto es el local. El trabajo que puede correr en un modelo open source a través de Ollama te cuesta electricidad y nada más. Para una buena parte de las tareas rutinarias esa es la respuesta correcta, y una fábrica que trata los motores locales como de primera te deja tomarla.
El coste que olvidas contar
El coste obvio es el precio en tokens de un run que sale bien. El que se come los presupuestos es todo lo que hay alrededor.
Reintentos. Un agente que falla, reintenta, vuelve a fallar y lo hace tres veces antes de que nadie se dé cuenta ha pagado cuatro veces por una tarea. Deriva. El trabajo que se salió de la spec sin avisar y hay que rehacer no es un descuento, es un segundo run completo. Bucles de verificación que re-ejecutan todo para comprobarlo. Contexto que reenvías en cada turno porque la herramienta no tiene memoria y recarga el mundo cada vez.
Nada de eso aparece como una línea llamada “desperdicio”. Aparece como uso normal, que es justo por lo que sobrevive. La forma de encontrarlo es la misma visibilidad de antes: si puedes ver que una tarea se corrió cuatro veces, o que un run costó el triple que sus vecinos, puedes ir a arreglar la causa. Si solo tienes el total del mes, el desperdicio es estructural, invisible, y se queda.
Aquí también se cruzan el control de coste y la verificación. Un agente que demuestra de forma creíble que terminó es un agente que no vuelves a correr para asegurarte. Barato y correcto no están en tensión aquí. El sistema que obliga a un modelo a demostrar que terminó es el mismo que te evita pagar dos veces por el mismo trabajo.
Dónde encaja PaellaDoc
PaellaDoc trata el coste como una propiedad de la tarea, no como una sorpresa a final de mes. Cada tarea lleva un perfil, cheap, balanced, strong, frontier, y ese perfil decide el motor y el techo. El trabajo barato se enruta a motores baratos, o a un modelo local a través de Ollama por el precio de la electricidad, y el motor caro queda reservado para la tarea que se lo gana.
Como la fábrica local de software es local y el trabajo está acotado, puedes ver qué costó de verdad un run y cuánto de eso fueron reintentos o recuperación en vez de trabajo a la primera. Y como una tarea se cierra solo cuando la evidencia lo dice, no estás pagando otra vez solo para convencerte de que funcionó. La ventaja no es un modelo más barato. Es un sistema que gasta a propósito y te deja verlo hacerlo.
¿Sabes cuánto costaron tus últimas diez tareas, una a una? Si la respuesta de verdad es “el total del mes, más o menos”, esa es la brecha que conviene cerrar primero.
Preguntas frecuentes
¿Cómo controlo el coste de la IA en programación?
Mueve la decisión de la factura del mes a la tarea concreta. Primero consigue visibilidad a nivel de tarea: qué costó un run en tokens, qué motor usó, cuánto fueron reintentos. Después ponle un tope con un presupuesto por tarea y enruta el trabajo barato a motores baratos por defecto. El coste deja de ser una sorpresa a final de mes y pasa a ser una propiedad de cómo se despacha cada tarea, con el número delante mientras todavía puedes actuar.
¿Por qué mi agente de IA quemó tantos tokens?
Normalmente no es la tarea que estabas mirando. Los agentes se pasan en la que se torció: se atascó, se reintentó en bucle y corrió un modelo frontier en círculos sin un techo contra el que chocar. El resto se esconde en costes que olvidas contar: reintentos, deriva que hay que rehacer, bucles de verificación y contexto reenviado en cada turno porque la herramienta no tiene memoria. Nada aparece como “desperdicio”; parece uso normal.
¿Cómo pongo un presupuesto de tokens por tarea?
Define unos pocos tramos —cheap, balanced, strong, frontier— en vez de poner precio a cada tarea a mano. Cada tarea hereda un techo y un motor razonables de su tramo, así que la decisión manual ocurre una vez, en el tramo. Cuando un run revienta su tope, se para y te avisa, en vez de gastarte el mes en silencio. El presupuesto es tanto una alarma que saca a la superficie un run confundido como una cartera.
¿Debería enrutar las tareas baratas a modelos más baratos?
Sí; es la fuente de desperdicio más grande y más aburrida. Un retoque de copy, un rename, un comentario o un refactor pequeño que los tests ya cubren no necesitan tu motor más fuerte. Deja que el perfil de la tarea decida qué motor la recoge, para que el trabajo barato aterrice en motores baratos por defecto. El trabajo rutinario que puede correr en un modelo local open source a través de Ollama cuesta solo electricidad, que suele ser la respuesta correcta.