Módulo 5 — Presupuesto y control: costo, tiempo y contexto

1. Introducción: los tres presupuestos que administras

Siguiente →

Descripción

Al terminar esta lección vas a poder nombrar los tres presupuestos que gastas cada vez que delegas una tarea a un agente de código —tokens, tiempo de reloj y atención humana—, explicar con el mecanismo concreto por qué optimizar uno solo casi siempre degrada los otros dos, y reconocer los tres patrones típicos de desequilibrio la primera vez que los veas en tu propio trabajo: barato pero interminable, rápido pero irrevisable, cómodo pero carísimo. También vas a poder ubicar, en un solo vistazo, qué vas a medir en cada una de las siete lecciones que siguen y cómo se conecta ese trabajo con la línea base que ya mediste en el Módulo 1.

Esto importa porque la mayoría de los equipos que adoptan agentes de código terminan gestionando un solo número —casi siempre el que aparece primero en pantalla: el costo en dólares de la API— y tratan a los otros dos como si no existieran, hasta que se manifiestan de la peor forma posible. Un ingeniero que elige siempre el modelo más barato porque "así ahorramos" puede terminar gastando tres veces más tiempo en iteraciones que un modelo más caro habría resuelto a la primera. Un equipo que lanza diez agentes en paralelo para "ir más rápido" puede terminar con una atención humana tan repartida que nadie revisa ningún diff con el cuidado que exige el Módulo 4, y una falla silenciosamente destructiva pasa sin que nadie la note hasta semanas después. Nombrar los tres presupuestos por adelantado, antes de que un desequilibrio te cueste caro, es lo que separa a quien administra su trabajo con agentes de quien simplemente lo sufre.

Conexión con el módulo: los cuatro módulos anteriores te dieron el oficio completo —triage e intención (Módulo 1), especificación ejecutable (Módulo 2), un harness que verifica solo (Módulo 3), un procedimiento explícito para revisar lo que el agente entrega (Módulo 4)—. Este módulo abre la última fase de la guía, Escala: presupuesto y gobierno, y responde la pregunta que ninguno de los anteriores tocó todavía: ¿cuánto te cuesta ejercer todo ese oficio, en las tres monedas que en verdad gastas? La línea base que registraste en el proyecto del Módulo 1 —tiempo de reloj, iteraciones, sesiones y si el cambio llegó a main— sigue siendo válida, pero medía solo dos de los tres presupuestos de esta lección, sin separar cuánto de ese tiempo era del agente trabajando solo y cuánto era tuyo revisando. El proyecto de este módulo (lección 8) vuelve a esa misma línea base, la completa con el presupuesto que faltaba —el dinero— y separa la atención humana del tiempo de reloj total, para comparar con el mismo rigor con el que mides todo lo demás en esta guía.

Tres presupuestos, no uno

Imagina que te mudas de casa y tienes que decidir cómo contratar el servicio de mudanza. La empresa más barata del catálogo cobra por camión, no por hora: cuesta poco, pero solo tiene un camión chico, así que hace tres viajes en dos días, y en cada viaje tienes que estar tú presente indicando qué va en cada caja, porque nadie del equipo conoce tu inventario. La empresa exprés, en cambio, manda seis personas y termina todo en una sola mañana, pero empacan tan rápido que no alcanzas a revisar cada caja mientras la sellan; te enteras dos semanas después, al desempacar, de que faltan dos platos y una lámpara llegó con la base rota, sin que nadie te avisara en el momento. Y existe una tercera opción, la mudanza "todo incluido": un coordinador se encarga de todo, tú no decides ni supervisas nada, firmas y te vas a trabajar — pero la factura al final del mes te deja pensando si en verdad hacía falta pagar tanto por algo que, con un poco más de tu propio tiempo revisando, habrías resuelto por una fracción del precio.

Ninguna de las tres opciones es "la mudanza barata" sin más: cada una gasta menos en un recurso —dinero, tiempo del calendario, tu propia atención— a cambio de gastar más en otro. Delegar trabajo a un agente de código tiene la misma estructura, con tres presupuestos que se comportan igual de acoplados:

  • Tokens (dinero). Lo que cobra la API por cada llamada: entrada, salida, y los multiplicadores de caché que la lección 3 detalla con números reales. Es el número que aparece primero en /usage, y por eso el que más equipos confunden con "el" costo completo.
  • Tiempo de reloj. Cuánto dura la tarea de principio a fin: desde el primer prompt hasta que aceptas, corriges o rechazas el resultado. Incluye el razonamiento del agente, sus llamadas a herramientas, y cualquier pausa entre una sesión y la siguiente.
  • Atención humana. Los minutos que tú —o quien revisa— gastas leyendo el diff, decidiendo si el plan tiene sentido, corriendo pruebas manuales, corrigiendo el rumbo. A diferencia de los otros dos, no escala con más hardware ni con una tarjeta de crédito: es finito porque la persona que revisa es finita.

El motivo por el que no puedes optimizar solo uno sin pagar en los otros dos no es una casualidad contable: es un mecanismo. Si eliges el modelo más barato para una tarea que en verdad requería más razonamiento, ahorras en tokens por llamada, pero un modelo que entiende peor el problema necesita más idas y vueltas para llegar al mismo resultado —cada iteración adicional es, a la vez, más minutos de reloj y más minutos tuyos corrigiendo el rumbo—. El ahorro en dólares termina convertido, turno por turno, en gasto de los otros dos presupuestos. Si en cambio lanzas varias tareas en paralelo para bajar el tiempo de reloj total, el trabajo que hay que revisar no desaparece: se multiplica al mismo ritmo que las tareas paralelas, y como la atención humana no se puede paralelizar de la misma manera que las llamadas a la API, ese presupuesto es el que se rompe primero —normalmente en forma de una revisión más superficial de lo que el Módulo 4 exige—. Y si aceptas cada sugerencia del agente sin fricción porque se siente cómodo no tener que pensar, esa comodidad no es gratis: la sesión se estira sin que nadie ponga un límite, el costo en tokens crece de forma no lineal a medida que la conversación se alarga —la lección 3 explica exactamente por qué—, y el costo de revisar con cuidado simplemente se pospuso, no desapareció.

Ejemplo trabajado: la misma semana, tres desequilibrios distintos

Veamos cómo se ven estos tres patrones en la práctica, con una semana de trabajo real y sus tres tareas.

Lunes — barato pero interminable. La tarea es corregir el mensaje de error de la validación de un cupón en el checkout: hoy dice "Error de validación", y el ticket pide un mensaje específico por cada motivo de rechazo (vencido, ya usado, monto mínimo no alcanzado). Para ahorrar, el desarrollador delega la tarea con el modelo más barato del catálogo, Claude Haiku 4.5. El primer intento cambia el mensaje pero rompe la prueba del texto genérico anterior. El segundo corrige eso, pero olvida el caso "monto mínimo no alcanzado" porque el modelo no conectó ese caso con la validación en coupon_service.py. El tercero lo agrega, pero con el orden de parámetros invertido ("mínimo de $50, tu monto es $30"). Recién en el sexto intento el diff queda completo y las pruebas pasan. Al cerrar la sesión, /usage muestra un costo total de apenas $0.09, pero el reloj marca 52 minutos desde el primer prompt, con 6 iteraciones de corrección.

Miércoles — rápido pero irrevisable. El mismo desarrollador tiene cuatro bugs pequeños e independientes en su backlog y lanza cuatro sesiones en paralelo, cada una con Claude Opus 4.8 en un archivo distinto. Las cuatro terminan en 14 minutos de reloj —el tiempo de la más lenta, porque corrieron a la vez—, con pruebas en verde. Para no perder el ritmo, revisa los cuatro diffs en bloque, dedicando apenas 3 minutos a cada uno: mira que las pruebas pasen y que el archivo tocado sea el esperado, y aprueba. Uno de los cuatro diffs —el que corrige un cálculo de descuento— también elimina, "para simplificar", una validación que impedía aplicar el mismo cupón dos veces en el mismo pedido; ninguna prueba existente cubría ese caso, así que nadie lo nota en esos 3 minutos. Aparece diez días después, cuando un cliente aplica el mismo cupón tres veces en una sola compra. Es exactamente la clase de falla silenciosamente destructiva del Módulo 4 —solo que aquí la causa no fue no tener un procedimiento de revisión, sino no tener el tiempo de atención para aplicarlo a las cuatro tareas por igual.

Viernes — cómodo pero carísimo. La última tarea es un refactor amplio: mover la lógica de cálculo de impuestos, dispersa en tres archivos, a un módulo único. El desarrollador abre una sesión con Opus 4.8 y, como el modelo propone cambios razonables uno tras otro, deja de escribir instrucciones detalladas y se limita a responder "sí, dale" a cada propuesta, sin pausar a revisar el plan de fondo. La sesión sigue abierta toda la tarde —la lección 3 explica por qué cada turno nuevo de una conversación así de larga paga por releer todo lo que ya se dijo antes—, y al cerrarla, /usage marca $4.85 de costo total. El desarrollador dedicó apenas 8 minutos a revisar el resultado final, porque sintió que ya lo había ido aprobando en el camino.

Puesta en una sola tabla, la semana se ve así:

DíaPatrónCosto (tokens)Tiempo de relojAtención humana
LunesBarato pero interminable$0.0952 min52 min (todo de corrección)
MiércolesRápido pero irrevisable~$0.60 (4 tareas)14 min12 min (3 min × 4, insuficiente)
ViernesCómodo pero carísimo$4.85~3 h8 min

Ninguna de las tres filas es "la mala": las tres entregaron un resultado que pasó sus pruebas ese mismo día. Lo que las distingue es cuál de los tres presupuestos absorbió el costo que las otras dos filas dejaron afuera: el lunes, tiempo de reloj y atención; el miércoles, atención humana que no se notó hasta diez días después; el viernes, tokens, sin que nadie lo decidiera a propósito. El resto del módulo —lecciones 2 a 7— te da el criterio para elegir, cada vez, cuál de los tres te conviene gastar más, en vez de que la elección la haga por default la comodidad del momento.

Qué vas a medir en este módulo, y cómo se compara con tu línea base del Módulo 1

Cuando cerraste el proyecto del Módulo 1, tu bitácora quedó con cuatro números por tarea —tiempo de reloj, iteraciones, sesiones y si el cambio llegó a main— y de ahí destilaste tres números-resumen de línea base: tiempo promedio, iteraciones promedio y tasa de llegada a main. Esos números siguen siendo válidos, y este módulo no los descarta: los completa. Fíjate en lo que esa línea base todavía no separaba: el tiempo de reloj mezclaba, en un solo número, el tiempo que trabajó el agente solo y el tiempo que tú pasaste revisando —dos de los tres presupuestos de esta lección, fundidos en una sola columna—. Y el presupuesto de tokens ni siquiera aparecía, porque en el Módulo 1 todavía no tenías criterio para saber si el costo en dólares de una tarea era razonable o no.

Este módulo hace tres cosas con esos huecos: te da un instrumento para separar tiempo de reloj de atención humana (lección 2), te enseña a leer el presupuesto de tokens con criterio propio en vez de mirarlo como un número aislado (lecciones 3 y 4), y te da reglas explícitas para decidir cuándo un desequilibrio —como los tres del ejemplo de arriba— vale la pena o cuándo hay que cortarlo (lecciones 5 y 6). El proyecto de la lección 8 cierra el módulo volviendo, literalmente, a dos tareas de tu bitácora del Módulo 1: las vuelves a medir con el criterio completo de este módulo —separando dinero, tiempo y atención— y comparas el resultado contra tu línea base original, nombrando cualquier sesgo que la comparación tenga (por ejemplo, que ya sabes especificar y revisar mejor que en el Módulo 1, así que parte de cualquier mejora no viene del presupuesto en sí, sino del oficio ya aprendido en el camino).

Así se reparte el resto del módulo:

#LecciónQué vas a poder hacer al terminarla
2Medir el costo real por tareaInstrumentar cualquier tarea con los cinco componentes de su costo real —tokens, iteraciones, tiempo de reloj, revisión y retrabajo— sin que registrar se vuelva una segunda carrera
3Economía de la ventana de contextoCalcular por qué una sesión larga cuesta más turno tras turno, y decidir con números si conviene compactar, reiniciar o seguir
4Elegir el modelo según la tareaDistinguir con tus propios datos cuándo un modelo caro se paga solo y cuándo es desperdicio puro
5Paralelismo: cuándo varias tareas a la vez sí convieneReconocer qué se puede paralelizar sin que la atención humana se rompa como el miércoles del ejemplo, y qué no
6Condiciones de parada y límites de gastoDefinir, antes de empezar, los límites duros —iteraciones, tiempo, gasto— que evitan que un desequilibrio como el del viernes se coma la tarde
7Velocidad real contra velocidad percibidaPresentar el costo total, con los tres presupuestos integrados, sin caer en la promesa vacía del multiplicador de productividad
8Proyecto: flujo instrumentado con presupuestoInstrumentar cinco tareas reales con los tres presupuestos, definir tu política de modelo y de cortes, y comparar contra tu línea base del Módulo 1

No vas a memorizar un número universal de "cuánto debería costar una tarea": vas a construir tu propio criterio, con tus propios datos, del mismo modo en que ya construiste tu línea base en el Módulo 1.

Errores comunes

Tratar el número en dólares como si fuera "el" presupuesto (conceptual). Qué pasa: alguien mira /usage al final de una sesión, ve un costo bajo, y concluye que la tarea salió barata, sin mirar cuántas iteraciones ni cuántos minutos de corrección tomó llegar ahí —el patrón del lunes del ejemplo, donde $0.09 escondían 52 minutos de reloj y de atención—. Por qué pasa: el dólar es el único de los tres presupuestos que una herramienta te muestra sin que se lo pidas; los otros dos exigen que tú los midas o los notes, así que es fácil que el número visible se vuelva, sin decisión consciente, el único que cuenta. Cómo detectarlo: si al comparar dos tareas solo puedes decir cuál costó menos en dólares, pero no cuál tomó menos tiempo tuyo, te falta la mitad de la cuenta. Cómo corregirlo: antes de decidir si una tarea "salió barata", pregúntate cuántas iteraciones tomó y cuántos minutos propios de revisión o corrección le dedicaste —los tres números juntos, nunca uno solo, son el presupuesto real; la lección 2 te da el instrumento exacto para registrarlos.

Confundir "más rápido en total" con "cada parte se revisó igual de bien" (conceptual). Qué pasa: un equipo lanza varias tareas en paralelo, ve que el tiempo de reloj total bajó, y celebra la ganancia de velocidad sin notar que la atención humana disponible para revisar cada una se dividió en la misma proporción —el patrón del miércoles, donde cuatro tareas en paralelo dejaron 3 minutos de revisión para cada una—. Por qué pasa: el tiempo de reloj se puede paralelizar corriendo varias sesiones a la vez, pero la atención humana no —sigue siendo una sola persona con los mismos minutos disponibles—, y esa asimetría es fácil de pasar por alto porque las dos cosas se sienten como "velocidad" en el momento. Cómo detectarlo: si el tiempo que dedicas a revisar cada tarea paralela bajó en la misma proporción en que subió el número de tareas paralelas, no ganaste velocidad de revisión: la repartiste más fina, y alguna va a recibir menos de lo que necesita. Cómo corregirlo: antes de paralelizar, pregúntate si tienes minutos de atención suficientes para revisar cada resultado con el mismo cuidado que le darías si fuera la única tarea del día —la lección 5 te da la regla práctica para esa decisión.

Confundir "se sintió cómodo" con "salió barato" (práctico). Qué pasa: una sesión donde vas aprobando cada sugerencia del agente sin fricción, sin pausar a pensar el plan completo, se siente productiva mientras ocurre —como el viernes del ejemplo, donde decir "sí, dale" a cada paso terminó en una factura de $4.85 y apenas 8 minutos de revisión real—. Por qué pasa: la comodidad y el costo real no tienen ninguna relación directa; una sesión cómoda pospone el trabajo de revisar y de decidir, no lo elimina, y en el camino la conversación se alarga —con el costo no lineal que la lección 3 explica— sin que nadie haya puesto un límite explícito. Cómo detectarlo: si terminas una sesión larga sin recordar en qué momento revisaste el plan completo por última vez, y solo recuerdas haber ido aprobando pasos sueltos, probablemente pagaste en tokens lo que no pagaste en atención. Cómo corregirlo: define, antes de empezar una sesión que se ve larga, un límite explícito de tiempo o de iteraciones para forzar una pausa de revisión real —la lección 6 te da el criterio para poner esos límites antes de que la comodidad decida por ti.

Ejercicios

Ejercicio 1 — Clasifica el desequilibrio. Para cada uno de estos tres escenarios, di cuál de los tres patrones de esta lección aplica (barato pero interminable, rápido pero irrevisable, cómodo pero carísimo) y en una frase explica cuál de los tres presupuestos terminó absorbiendo el costo que los otros dos no mostraron.

a. Un equipo agrega diez sesiones de agente en simultáneo para cerrar el sprint antes del viernes. El viernes a las 5pm todas las tareas están "hechas", pero el lunes siguiente aparecen tres bugs de tareas que nadie alcanzó a revisar con cuidado esa semana.

b. Un desarrollador deja correr una sola sesión larga con el modelo más caro del catálogo durante toda una mañana, sin cortar ni una vez a revisar el plan, porque el agente iba proponiendo cambios razonables uno tras otro. Al mediodía, /usage marca $6.40 por una tarea que, medida a mano, no debería haber tomado más de $1.

c. Un desarrollador insiste en usar siempre el modelo más económico, incluso para una migración de esquema de base de datos compleja. La tarea toma nueve iteraciones a lo largo de dos horas antes de llegar a un resultado correcto.

Ver solución

a. Rápido pero irrevisable. El tiempo de reloj bajó porque las diez tareas corrieron en paralelo, pero la atención humana disponible para revisar cada una no se multiplicó junto con ellas — se repartió más fina, y al menos tres tareas recibieron menos revisión de la que necesitaban. El presupuesto que absorbió el costo fue la atención humana, solo que el costo apareció después, el lunes siguiente, no el viernes cuando todo "se veía terminado".

b. Cómodo pero carísimo. La sesión se sintió productiva porque cada paso individual parecía razonable, pero nadie puso un límite de tiempo ni una pausa de revisión de plan completo, y el costo en tokens creció sin que nadie lo notara hasta el corte de /usage. El presupuesto que absorbió el costo fue el de tokens, exactamente al revés del escenario (a).

c. Barato pero interminable. El costo en dólares por llamada es bajo porque el modelo es económico, pero una migración de esquema compleja necesitó nueve idas y vueltas para llegar a un resultado correcto — cada una de esas iteraciones es tiempo de reloj y atención humana que el ahorro en tokens no compensa.

Por qué funciona: en los tres casos, el error no es haber elegido mal una herramienta puntual —paralelizar, usar un modelo caro, usar uno barato— sino no haber anticipado en qué otro presupuesto se iba a pagar la elección. Nombrar el patrón exacto (no solo "algo salió mal") es lo que te permite, en las lecciones que siguen, corregir la causa y no solo el síntoma.

Ejercicio 2 — Decide con los tres presupuestos, no con uno. Un compañero te muestra estos tres registros de la misma tarea —agregar validación de formato a un campo de teléfono en un formulario—, cada uno resuelto de una forma distinta, y te pregunta cuál de las tres fue "la mejor" manera de hacerlo.

EnfoqueCosto (tokens)Tiempo de relojAtención humana
A — modelo barato, sola$0.0438 min35 min
B — modelo caro, en paralelo con otras 5 tareas$0.306 min2 min
C — modelo caro, sesión enfocada solo en esta tarea$0.289 min6 min

¿Cuál recomendarías, y qué información adicional —de la que no está en esta tabla— necesitarías antes de decidir con confianza?

Ver solución

De los tres, C es el candidato más sólido con la información disponible: cuesta casi lo mismo que B, toma poco más de tiempo de reloj, y le dedicó una atención humana enfocada (6 minutos) proporcional al tamaño real de la tarea —ni tan poca como B (2 minutos, sospechosamente bajo para un cambio de cara al usuario) ni tan alta como A (35 minutos para una validación de un solo campo sugiere que el enfoque barato tuvo que iterar de más). B es tentador por su costo y su tiempo de reloj, pero 2 minutos de atención es exactamente el patrón "rápido pero irrevisable" del miércoles del ejemplo trabajado.

Lo que falta es si B de verdad recibió una revisión completa o solo una mirada rápida porque compitió por atención con las otras cinco tareas paralelas — la tabla no distingue "2 minutos porque la tarea era trivial" de "2 minutos porque no había más tiempo disponible", y esa diferencia decide si B fue eficiente o irrevisable.

Por qué funciona: la tabla, por sí sola, no dice cuál enfoque es mejor — dice cuánto costó cada uno en cada presupuesto. Decidir con criterio exige mirar los tres números juntos y preguntarte si el más barato en dos de ellos lo es porque de verdad fue así, o porque el tercero se sacrificó sin que nadie lo decidiera a propósito.

Ejercicio 3 — Ubica tu propia duda en el mapa del módulo. Piensa en una decisión real de presupuesto que tengas pendiente hoy —algo como "¿me conviene correr estas tres tareas en paralelo o una por una?", "¿vale la pena pagar el modelo caro para este refactor?" o "¿cuánto tiempo más le doy a esta sesión antes de cortarla?". Usando la tabla de "Qué vas a medir en este módulo", indica en qué lección vas a encontrar el criterio para resolverla.

Ver solución

Depende de tu propia pregunta, pero como referencia: dudas sobre paralelizar apuntan a la lección 5; dudas sobre si pagar un modelo más caro se justifica, a la lección 4; dudas sobre cuánto tiempo más darle a una sesión antes de cortarla, a la lección 6, aunque si ya lleva un buen rato abierta, la lección 3 también aplica, porque el costo de seguir no es el mismo que el de reiniciarla. Si tu pregunta no encaja en ninguna fila, puede que necesites primero el instrumento de la lección 2 —muchas dudas de presupuesto son, en realidad, dudas de "no tengo el dato" antes que dudas de criterio.

Por qué funciona: ubicar tu propia pregunta en el mapa confirma que entendiste qué resuelve cada lección, no solo que memorizaste sus títulos — y de paso te deja sabiendo a cuál volver cuando la necesites.

Resumen y siguiente paso

Lo que aprendiste aquí es que cada tarea que delegas a un agente gasta de tres presupuestos distintos —tokens, tiempo de reloj y atención humana— y que ninguno se puede optimizar de forma aislada sin empujar el costo hacia los otros dos: el modelo barato que necesita más iteraciones, el paralelismo que reparte la atención más fina de lo que alcanza para revisar bien, la sesión cómoda que pospone el costo de pensar hasta que la factura lo hace visible. Los tres patrones del ejemplo trabajado —barato pero interminable, rápido pero irrevisable, cómodo pero carísimo— no son casos raros: son la forma normal en que se ve un presupuesto desequilibrado cuando nadie lo mide con los tres números a la vez.

Antes de avanzar a la lección 2 deberías poder: nombrar los tres presupuestos sin mirar apuntes, describir de memoria los tres patrones de desequilibrio y decir cuál presupuesto absorbe el costo en cada uno, y explicar en una frase cómo se conecta este módulo con la línea base de tiempo, iteraciones y llegada a main que ya mediste en el Módulo 1.

La siguiente lección te da el instrumento que esta introducción solo describió con ejemplos: cómo medir, con tus propios números y no con una tabla inventada como esta, los cinco componentes del costo real de cualquier tarea —incluidos los dos que ninguna herramienta mide por ti: los minutos de revisión y el retrabajo posterior—. Sin ese instrumento, todo lo que viste aquí sigue siendo una intuición razonable; con él, se convierte en un criterio que puedes aplicar desde mañana.

Recursos

← Anterior8. Proyecto: pasar tres cambios generados por el procedimientoSiguiente →2. Medir el costo real por tarea