Esta semana Peter Steinberger publicó una captura de pantalla que LinkedIn entero compartió antes de leerla bien. La imagen, tomada desde su propia app CodexBar, muestra $1,305,088.81 en tokens de OpenAI consumidos en 30 días. Steinberger es el fundador de OpenClaw, la startup que OpenAI absorbió a inicios de 2026, y ese gasto es parte de su trabajo diario codeando con IA. Linas Beliūnas reposteó la imagen con un cálculo viral: “$1.3M equivale a 7 ingenieros senior en EE.UU., 16 en Lituania, o 26 en India por un año completo.”

La traducción funciona como anzuelo viral. No funciona como economía.

Riaz Khan, CTO con paso por Thomson Reuters y AWS, lo dijo más adelante en el mismo hilo, palabra por palabra: “Comparing token spend to engineer salaries is the wrong framing. The real question is what output velocity $1.3M in tokens generates versus $1.3M in fully-loaded engineering cost. At $200K fully-loaded per senior engineer, that’s ~6-7 engineers. If those tokens accelerated shipping timelines by 6 months on a revenue-critical product, the ROI is trivial.” (Comparar gasto de tokens contra salarios es el marco equivocado. La pregunta real es qué velocidad de envío te dan $1.3M en tokens contra $1.3M en costo total de ingeniería. La métrica que importa es tokens por funcionalidad enviada, no tokens por mes.)

La tesis de este post es la versión completa de la observación de Riaz, llevada al lugar donde un CFO la puede usar el lunes: el KPI de IA empresarial en 2026 no es el costo mensual en tokens. Es tokens por funcionalidad enviada. Y la diferencia entre los dos números es la disciplina operativa que separa al equipo que escala IA con margen del que la quema con dignidad.

La pregunta correcta no aparece en el debate viral

El gasto absoluto en tokens es la métrica equivalente a “cuántos kilovatios consume mi fábrica este mes.” Sirve para pagar la factura. No sirve para decidir nada. Lo que decide es producción por kilovatio.

Linas Beliūnas, el mismo que reposteó la captura de pantalla de Steinberger, publicó un artículo más serio en su Substack el 8 de mayo que se vendió como “sistema para no chocar contra los límites de Claude” y que en realidad es una autopsia clínica del problema de fondo. Su diagnóstico, exactamente: “most users are burning the majority of their allocation on architecture mistakes, not actual work.” (La mayoría de los usuarios quema su asignación en errores de arquitectura, no en trabajo real.)

El número que pone arriba: más del 80% del presupuesto se va en tres errores concretos. Conversaciones largas que re-tokenizan miles de palabras de historia en cada mensaje. Lecturas de archivo amplias cuando solo importaba una función. Usar Opus por defecto cuando Sonnet habría resuelto el mismo problema con la misma calidad. La tasa de fricción que paga el CFO no viene del modelo. Viene de cómo el equipo lo está usando.

Esto cambia la conversación del proveedor al cliente. El precio de Anthropic, OpenAI o Google ya no es lo que mueve la aguja. Lo que la mueve es la disciplina interna con la que tu equipo arma cada llamada. Si esa disciplina falta, el costo por funcionalidad enviada se dispara aunque el modelo te baje el precio en cada nueva versión.

Lo que el paper de PwC midió esta semana

El 14 de mayo cinco investigadores de PricewaterhouseCoopers publicaron “Is Grep All You Need? How Agent Harnesses Reshape Agentic Search”. El nombre suena académico pero la conclusión es presupuestaria: grep (búsqueda léxica simple, la herramienta de línea de comandos de hace 50 años) envuelto en un buen agent harness iguala o supera a la búsqueda vectorial en tareas de agentes de código. El paper midió esto en seis categorías del benchmark LongMemEval, con Claude Code, Codex y Gemini CLI como envoltorios.

La frase del abstract que importa para el presupuesto: “overall scores still depend strongly on which harness and tool-calling style is used, even when the underlying conversation data are the same.” (Los puntajes finales dependen fuertemente del harness y del estilo de invocación de herramientas, incluso cuando los datos subyacentes son los mismos.)

Para un CFO que está mirando una propuesta de su equipo de plataforma con una línea presupuestaria de “base de datos vectorial,” la traducción es exacta. Si la propuesta arranca con el supuesto de que IA agéntica necesita una base vectorial por defecto, está construyendo arquitectura que el paper acaba de medir como innecesaria para una categoría grande de casos. Esa línea presupuestaria es arquitectura que no se envía a producción. Es tokens por funcionalidad enviada subiendo silenciosamente porque el equipo eligió la herramienta sofisticada antes de probar la simple.

Eso no significa que las bases vectoriales no sirvan nunca. Sirven cuando los corpus son enormes y la búsqueda léxica se rompe por falta de cobertura semántica. Lo que significa es: el reflejo de comprarlas por defecto, sin medir contra grep primero, es exactamente el tipo de gasto que tu KPI nuevo va a detectar.

Cómo se calcula tokens-per-funcionalidad-enviada

La fórmula es vergonzosamente simple. Tomas el gasto total en tokens del trimestre y lo divides entre el número de pull requests fusionados a producción en ese trimestre. Esa es tu línea base. La primera vez que lo calculas, vas a descubrir que el número está más alto de lo que pensabas, porque incluye todo el gasto exploratorio (educación del equipo, pruebas exploratorias, prototipos descartados) mezclado con el gasto productivo. Eso es información, no defecto.

El segundo paso es separar las dos columnas. Gasto productivo es lo que se atribuye a un pull request fusionado. Gasto exploratorio es lo que se atribuye a una sesión de aprendizaje, una prueba de concepto, un fin de semana de un ingeniero leyendo cómo funciona la nueva versión de Sonnet. Las dos columnas tienen distintas reglas de gobernanza: el exploratorio tiene un techo trimestral aparte; el productivo tiene una compuerta por pull request.

Un ejemplo concreto, redondeando para que se lea limpio. Un equipo de seis ingenieros con un gasto de ~$80K/mes en tokens cerró 24 funcionalidades en el trimestre. Tokens por funcionalidad enviada: ~$10K. Otro equipo, mismo tamaño, mismo modelo, gastó ~$40K/mes y cerró 6 funcionalidades. Tokens por funcionalidad enviada: ~$20K. La factura del segundo equipo es la mitad. El costo unitario es el doble. Si solo miras el total mensual, estás premiando al equipo equivocado y dándole presupuesto al que más lo va a quemar.

Llevo 36 años en computación, desde 1990, a mis 15 años, sentado frente a una Commodore 64 con 64KB de memoria que había que defender byte por byte. He visto a la industria pasar cuatro veces de “el precio del recurso” a “valor producido por el recurso” como métrica de gobernanza. En 1995 el departamento de TI medía ciclos de CPU por mes y aprendió, después de quemarse, que la métrica que sí movía la conversación era transacciones por segundo. En 2008 medía dólares por GB-mes en cualquier proveedor de nube y tuvo que migrar a dólares por evento de negocio para entender qué del costo era productivo. En 2026 está midiendo tokens por mes porque es lo que la factura del proveedor le muestra. La siguiente versión va a ser tokens por funcionalidad enviada. Cada ola tarda alrededor de tres trimestres en cambiar. El equipo que cambia primero protege margen durante esos tres trimestres.

La disciplina que IQ Source instala para que el KPI no quede en tablero

Un KPI sin disciplina operativa es un número en una pantalla que nadie mira el segundo lunes. Si el harness que cubrimos la semana pasada es la capa que envuelve al modelo, este KPI es el termómetro que mide si esa capa está bien apretada. La disciplina opera en cinco lugares concretos cuando trabajamos con un cliente en Socio Tecnológico.

Presupuesto trimestral en tokens por funcionalidad enviada, no en total mensual. El número se fija al inicio del trimestre como ratio, no como techo absoluto. Si el equipo cierra el doble de funcionalidades, el gasto absoluto puede subir y el KPI baja. Si el equipo cierra la mitad, el gasto absoluto puede mantenerse plano y el KPI sube. La conversación cambia de “estamos sobre presupuesto” a “estamos bajo margen.”

Compuerta de pull request con delta de tokens reportado. Cada PR fusionado lleva un campo con los tokens consumidos durante su construcción. Al final del sprint, el equipo ve el ratio del sprint sin tener que extraer datos manualmente. Sin esa visibilidad, el cálculo llega al final del trimestre y ya es tarde para corregir.

Disciplina de selección de modelo. Sonnet por defecto para todo lo que no requiera razonamiento extendido. Opus solo cuando el problema lo pide y el equipo lo justifica por escrito en el PR. El default importa porque la mayoría de los ingenieros no piensan en costo al elegir modelo; piensan en “el más capaz disponible.” Esa única regla suele bajar 30-40% del consumo de tokens sin tocar calidad.

Sesiones cortas con conocimiento persistente en archivos. Cada sesión nueva arranca con el contexto necesario cargado desde CLAUDE.md (u otro archivo persistente) en vez de re-tokenizar una conversación de cien mensajes. Es exactamente lo que recomienda Linas en su artículo del 8 de mayo. Es la diferencia entre re-leer un libro entero cada vez que vas a citar una frase y tener un índice al que vuelves.

Separación entre gasto exploratorio y productivo con presupuestos distintos. El gasto exploratorio se administra como un fondo de educación con techo trimestral. El gasto productivo se administra como costo de envío con ratio por funcionalidad. Mezclados, el equipo termina justificando experimentos como producción y el KPI deja de medir lo que tiene que medir.

Las cinco son aburridas. Esa es la característica. La disciplina operativa que sostiene un KPI no es un marco de cien páginas; son cinco reglas escritas en una página que el equipo aplica todos los días.

Las cuatro preguntas que un CFO sí debería hacer este trimestre

Si estás del lado del presupuesto, no del lado del commit, estas cuatro preguntas son lo único que necesitas tener listo para la próxima conversación con tu equipo técnico.

¿Cuál es nuestro ratio de tokens por funcionalidad enviada actual, y quién, con nombre y apellido, lo mide cada lunes? Si la respuesta es “no lo medimos todavía” o “el equipo lo tiene de cabeza,” el KPI no existe. Existe como intuición.

¿Qué porcentaje del gasto del mes pasado se fue en re-tokenización innecesaria, lecturas amplias, o uso de Opus por defecto? Si nadie ha hecho la cuenta, la respuesta es algún número entre 40% y 80%, según la honestidad de la auditoría. Hacer la cuenta es trabajo de un día. El número resultante es lo que va a defender el siguiente presupuesto.

Si el precio del modelo cae 50% el próximo trimestre, ¿qué cambia en nuestra factura y qué no? Si todo cambia, el equipo no tiene disciplina; está montado sobre el precio del proveedor. Si solo cambia un porcentaje pequeño, el equipo está apoyado en arquitectura propia. Los dos casos son legítimos. Saber en cuál estás es lo que un CFO está obligado a entender antes de firmar la próxima renovación.

Si cancelo el contrato del proveedor X mañana, ¿qué artefactos quedan de mi lado y cuáles se van? Esta pregunta importa porque tokens por funcionalidad enviada solo es un KPI útil si lo que produces es portable. Si tu equipo construyó toda la lógica adentro del entorno de pruebas de un solo proveedor, el ratio baja en el papel pero el costo de salida cuando el proveedor cambia condiciones es altísimo.

Cuatro preguntas. Una hoja de papel. El equipo que las responde con seguridad este trimestre paga IA con margen el siguiente año. El que no las responde paga lo mismo y aprende tarde por qué su competidor lo está haciendo más barato.

Conversemos sobre cómo medirlo en tu empresa