Todo el mundo discute si un agente de IA vale la pena. Casi nadie publica la cuenta.

Yo tengo una. La fundación de este blog —requisitos, arquitectura, diez ADRs, los mockups y el contrato de contenido— fue construida por un ciclo multiagente con un comité de siete revisores automáticos y nota de corte 9,5. Fueron tres rondas y cerca de 6,67 millones de tokens, con el consumo anotado por etapa en el propio repositorio mientras eso ocurría.

Esta publicación abre esa planilla. No es un benchmark de modelo ni una promesa de que su número vaya a ser ese: es una medición de un caso, con el método declarado y los números reproducidos en este texto. El repositorio del proyecto es privado; por eso, los marcadores citados no se abren para el lector.

El número, y de dónde viene

Los valores se anotaron al final de cada ronda en los marcadores versionados en docs/testes/: los mismos archivos que registran las notas del comité. Son valores reportados por los subagentes, no una factura extraída del panel de cobro. Esa distinción importa y vuelve al final de la publicación.

Lo que compraron los 6,67 millones: 21 artefactos de fundación (documento de requisitos, documento de arquitectura, diez ADRs, la especificación del pipeline, cinco mockups, el archivo de design tokens y el componente de anuncio), revisados por siete lentes independientes —arquitectura de software, arquitectura de datos, desarrollo, diseño, QA, seguridad e innovación— más un auditor de proceso, hasta que todas superaron 9,5.

Dónde fueron los tokens, ronda por ronda

Dónde fueron los tokens, ronda por ronda
RondaConsumoResultado
R1≈ 1,97Mreprobada
R2≈ 2,04Mreprobada (promedio +1,55)
R3≈ 2,66Maprobada — las siete lentes ≥ 9,5

El detalle por etapa es más interesante que el total. En la R2:

  • correcciones de los hallazgos de la ronda anterior: ≈ 785k
  • compuerta de humo + corrección barata: ≈ 236k
  • las siete lentes en modo delta: ≈ 922k
  • auditor de proceso: ≈ 101k

En la R3:

  • correcciones: ≈ 919k
  • compuerta de humo + correcciones previas a la revisión: ≈ 393k
  • las siete lentes en verificación estricta: ≈ 652k
  • reverificaciones: ≈ 359k
  • correcciones posteriores a la revisión (cuatro, en modelo pequeño): ≈ 186k
  • auditor: ≈ 147k

Observe lo que muestra la tabla: la revisión no es el ítem más caro. Sumando correcciones y reverificaciones, el trabajo de arreglar lo señalado costó más que señalarlo. Quien solo mira el precio del revisor está mirando la mitad barata de la cuenta.

La compuerta barata pagó; el modo “delta” no

Se probaron dos cambios de proceso con la intención explícita de abaratar. Uno funcionó, el otro no, y el que no funcionó es el más instructivo.

Funcionó: la compuerta de humo antes de las lentes. Una comprobación rápida y mecánica (¿existen los archivos declarados?, ¿el texto coincide con el código?, ¿hay un enlace muerto?) que corre antes de los revisores caros. En la R1, sin esa compuerta, defectos triviales fueron redescubiertos por tres lentes distintas, cada una gastando contexto para llegar a la misma conclusión. En la R2, con la compuerta, una corrección se cerró por 34 mil tokens en un modelo pequeño. El mismo defecto, por el camino anterior, se pagaba tres veces en un modelo grande.

No funcionó: revisar solo el diff. La idea era obvia: si la ronda anterior ya leyó todo, la siguiente solo necesita mirar lo que cambió. En la práctica, las siete lentes en modo delta costaron 922k, prácticamente lo mismo que una evaluación completa. No usaron el ahorro para terminar antes; usaron el margen para atacar el diff con más profundidad. El resultado fue bueno; solo que no fue barato. Un ahorro que el modelo puede gastar en calidad no es un ahorro: es una reasignación.

Lo que realmente recortó el costo de la revisión fue cambiar la instrucción, no el alcance: en la R3, las lentes corrieron en modo de verificación estricta (revise estas pendientes específicas, no reevalúe el mundo) y costaron 652k, cerca de un 30% menos que el modo delta.

Y el ítem de mayor retorno de todo el ciclo: el par corrección barata + reverificación con el contexto preservado. Cuatro pendientes se cerraron por ≈ 545k sumados, lo que evitó una cuarta ronda completa. Una ronda costaba más de 2 millones de tokens. Gastar 545 mil para no gastar 2 millones es el tipo de decisión que solo aparece si usted está midiendo.

El desperdicio tiene nombre: 378 mil tokens

El ítem del registro que más me gusta es el que salió mal.

Dentro de los 919k de correcciones de la R3 hay ≈ 378 mil tokens en dos reintentos duplicados, disparados por un diagnóstico apresurado: concluí que internet se había caído y mandé rehacer. No se había caído. El trabajo ya estaba en curso y se rehizo encima de sí mismo, dos veces.

Eso es el 5,7% de todo el ciclo quemado en una suposición errónea sobre infraestructura. No fue el modelo el que se equivocó, no fue el prompt: fue el operador reaccionando a un silencio. Un agente que tarda no es un agente atascado, y la diferencia entre las dos cosas cuesta dinero real.

La corrección es tediosa y funciona: antes de mandar rehacer, confirme que de verdad se detuvo.

Y en dólares, ¿cuánto fue?

Aquí la respuesta honesta es un intervalo, no un número, y el motivo es la lección más útil de esta publicación.

A los precios de lista publicados hoy por Anthropic, Claude Opus 5 cuesta US$ 5 por millón de tokens de entrada y US$ 25 por millón de salida. Aplicando eso a los 6,67 millones:

  • si todo fuera entrada: ≈ US$ 33
  • si todo fuera salida: ≈ US$ 167

El número real está en algún lugar de ese intervalo de cinco veces, y no puedo señalar dónde. Porque anoté el total, no la división entre entrada y salida, ni cuánto corrió en modelo pequeño. Parte del ciclo corrió en Haiku, que cuesta un quinto de Opus en la entrada, así que el piso verdadero es todavía más bajo; y nada de esto considera la caché de prompt, que descuenta buena parte de la lectura repetida.

Es decir: instrumenté lo suficiente para saber dónde fue el esfuerzo, y no lo suficiente para saber cuánto costó. Con lo que tengo se puede decidir el proceso. No se puede cerrar un presupuesto.

Si usted va a medir un agente, mida en dinero desde el primer día: entrada y salida separadas, por modelo, por etapa. El token es unidad de esfuerzo; el dinero es unidad de decisión. Convertir de uno al otro después solo funciona si usted guardó la división, y yo no la guardé.

Lo que yo cambiaría antes del próximo ciclo

  1. Registrar entrada, salida y modelo por etapa. Tres columnas más en la misma anotación que yo ya hacía, y el intervalo de cinco veces se vuelve un número.
  2. Compuerta mecánica antes del revisor caro. Lo que un script puede reprobar no debe llegar al modelo grande.
  3. Instrucción estrecha en lugar de alcance estrecho. Decir “verifique estas pendientes” recorta costo; decir “mire solo el diff” no lo recorta.
  4. Corrección barata con reverificación contextual. Es más barato arreglar y volver a revisar que abrir otra ronda completa.
  5. No reaccionar al silencio. Confirmar que se trabó antes de mandar rehacer: el reintento duplicado fue el gasto más caro y más evitable del ciclo.

Ninguno de estos puntos trata de elegir el modelo correcto de forma aislada, aunque arquitecturas recientes diseñadas para enjambres de agentes y caché agresiva de contexto comienzan a mitigar este obstáculo económico desde la propia infraestructura. Todos tratan del proceso que lo rodea, que es donde la cuenta realmente se forma.

Fuentes

  • Consumo de la R2 por etapa (785k correcciones · 236k compuerta + corrección barata · 922k lentes en delta · 101k auditor; total ≈ 2,04M) y la lección registrada de que el modo delta no abarató las lentes — marcador del comité, ronda 2 (registro interno del proyecto), verificado el 2026-08-10.
  • Consumo de la R3 por etapa (incluidos los ≈ 378k de reintentos duplicados), el acumulado del ciclo en ≈ 6,67M y las mediciones de −30% de la verificación estricta y de los ≈ 545k que evitaron una cuarta ronda — marcador del comité, ronda 3 (registro interno del proyecto), verificado el 2026-08-10.
  • Precio por millón de tokens de entrada y salida de los modelos actuales — descripción general de los modelos, Anthropic (documentación oficial), verificado el 2026-08-10.
  • Metodología declarada: los números de tokens son valores reportados por los subagentes y anotados al final de cada ronda, no una extracción del panel de cobro. La conversión a dólares es un intervalo calculado por mí a partir de los precios de lista de arriba, no una factura.