Tokenmaxxing ha muerto, larga vida al tokenmaxxing
(12gramsofcarbon.com)- En las primeras etapas de adopción de IA en las empresas, el uso de tokens vinculado a la evaluación del desempeño generó costos sin sentido, pero también ayudó a imponer el uso de herramientas de IA dentro de las organizaciones
- En Meta, cuando el uso individual de tokens se vinculó a las evaluaciones, incluso aparecieron usos meramente formales para inflar las métricas, como poner a dos agentes a conversar entre sí todo el día
- Antes, ejecutar agentes durante mucho tiempo era riesgoso por el error acumulativo (compounding error), donde pequeños fallos se iban sumando, pero recientemente está surgiendo una dinámica de corrección acumulativa (compounding correctness), en la que más tokens producen mejores resultados
- En seguridad ya aparecieron enfoques que asignan grandes presupuestos de tokens a modelos como Mythos para encontrar vulnerabilidades, creando una estructura en la que el defensor debe usar más cómputo que el atacante
- En adelante, en vez de gastar sin límite en modelos premium muy costosos, el centro práctico del tokenmaxxing podría pasar por ejecutar más veces en bucle modelos abiertos más baratos
Tokenmaxxing: comenzó como consumo inútil de tokens
- tokenmaxxing se refiere al fenómeno en el que ejecutivos incentivan a los empleados a usar muchos tokens, haciendo que se gasten incluso en tareas de poco valor real
- Un caso representativo es Meta, que recibió críticas por vincular las evaluaciones de desempeño al uso individual de tokens
- Un empleado de Meta contó que, para subir sus cifras de tokens, hizo que dos agentes hablaran entre ellos durante todo el día
- En la superficie, parecía que la gerencia solo estaba quemando costos sin generar ingresos, pero también puede verse como una política para forzar la expansión del uso de herramientas de IA
- Hasta hace pocos meses, dentro de las organizaciones había mucho personal senior que se resistía fuertemente a usar herramientas de IA, y aun cuando se lograba convencerlos, a veces las usaban de maneras extrañas o propensas a producir malos resultados
- En ese contexto, la presión desde arriba para usar tokens funcionó como una herramienta coercitiva y torpe para romper esa barrera
La primera política de uso ilimitado terminó por presión de costos
- La política de tokenmaxxing tuvo cierto efecto, y ahora casi todos los equipos al menos programan un poco con IA
- Muchos equipos todavía no han podido construir sistemas propios como Ramp Inspect o Stripe Minions, pero al menos ya llegaron al nivel básico de usar Cursor en la barra lateral
- A medida que el uso de tokens se disparó, OpenAI y Anthropic, en medio de sus planes de salida a bolsa, empezaron a limitar lo incluido en las suscripciones y a subir los precios de sus APIs
- Al reducirse también los subsidios de tokens, algunos equipos comenzaron a revertir sus políticas de uso ilimitado
- El tokenmaxxing ilimitado en su sentido original está cerca de un punto en el que ya no resiste una revisión de costos
Del error acumulativo a la corrección acumulativa
- La expectativa sobre las herramientas de IA es que puedan encargarse de tareas difíciles y tediosas sin requerir supervisión humana constante
- migraciones de código a gran escala
- investigación diaria de competidores cada mañana
- procesamiento de flujos inbound y outbound
- Antes, cuanto más tiempo se dejaba correr a una IA, más se acumulaban dentro del proyecto los pequeños errores y alucinaciones del modelo, y más difícil era revertirlos
- A este fenómeno se le llamó error acumulativo (compounding error), y como requería mucha supervisión humana, había poco motivo para dejar agentes corriendo 24 horas
- Ahora el entorno está cambiando hacia uno de corrección acumulativa (compounding correctness), donde usar más tokens eleva la probabilidad de obtener la respuesta correcta
- Si el gasto en tokens se conecta directamente con la calidad del resultado, reaparece el incentivo a gastar muchos tokens
La competencia por presupuestos de tokens ya se ve primero en seguridad
- En ciberseguridad ya están apareciendo casos en los que el gasto en tokens se conecta directamente con el desempeño
- Cybersecurity is Proof of Work Now pone como ejemplo a Mythos de Anthropic y sostiene que, para endurecer un sistema, hay que gastar más tokens en encontrar vulnerabilidades que los que gastaría un atacante en explotarlas
- AISI fijó un presupuesto de 100M tokens por intento con Mythos, lo que equivale a $12,500 por intento y $125,000 por 10 ejecuciones
- Los modelos con presupuestos de 100M tokens no mostraron señales de rendimientos decrecientes, y AISI dijo que, dentro del rango de presupuestos probado, los modelos siguieron avanzando a medida que aumentaba el presupuesto
- En esta estructura, importan más la carga de cómputo y el presupuesto de tokens que uno pueda pagar que la astucia
Bucles y ejecución prolongada de agentes
- El interés en los loops del que habló Boris Cherny en el escenario de Claude Code también se conecta con esta misma tendencia
- La estructura básica de los loops consiste en dejar que el agente ejecute hasta terminar su turno y, al finalizar, reiniciar el mismo prompt otra vez
- Esto permite dividir automáticamente especificaciones pesadas y hacer que el agente las vaya resolviendo por partes con el tiempo
- La idea no es nueva: existe desde julio del año pasado y en algún momento se le llamó “Ralph Wiggum loop”
- Antes hacía falta una comprensión profunda del diseño de prompts y del comportamiento de los agentes, pero gracias a la corrección acumulativa ahora es más fácil esperar resultados aproximados que mejoren con cada repetición
Modelos abiertos: más repeticiones por costo
- A largo plazo, los ganadores del tokenmaxxing podrían ser las plataformas de modelos abiertos
- La estrategia de gastar grandes cantidades de tokens en modelos de laboratorios líderes difícilmente pase una revisión de un CFO
- A medida que mejoren los modelos abiertos, se vuelve más atractivo ejecutar más veces en bucle modelos baratos
- Por ejemplo, si Claude ofrece una mejora de 1.1x por iteración y GLM 5.2 ofrece 1.05x pero cuesta aproximadamente una quinta parte, podría convenir más ejecutar un loop de GLM 5.2 cinco veces más
- En la sección “Other things” también se evalúa que GLM 5.2 no está en la punta absoluta del estado del arte, pero sí es mucho más barato que los modelos frontier
- GLM 5.2: alrededor de $1.4 por millón de tokens de entrada y $4 por millón de tokens de salida
- Serie Opus 4.X: $5 por millón de tokens de entrada y $25 por millón de tokens de salida
- Haiku 4.5: $1 por millón de tokens de entrada y $5 por millón de tokens de salida
- Se dice que GLM 5.2 es más fuerte que Haiku y que, en algunos benchmarks, incluso supera a GPT 5.5
Gasto para desarrolladores vs. gasto para pipelines
- El tokenmaxxing tiene dos formas distintas
- La primera es el gasto de tokens para desarrolladores
- Los desarrolladores usan herramientas como Claude Code, ejecutan loops y consumen muchos tokens
- Si eso aumenta la productividad de ingeniería, puede ser un buen gasto
- La segunda es el gasto de tokens para pipelines
- Los desarrolladores siguen escribiendo código a mano, y con ese código construyen agentes desechables para tareas específicas
- Estos agentes consumen muchos tokens mientras operan de forma no determinista y frágil
- Solo es un buen gasto cuando el pipeline realmente funciona, pero esos agentes no habían sido tan precisos como los pipelines deterministas
- Si se agrega un agente verificador de calidad para reducir el costo de las alucinaciones, y luego otro agente para detectar errores de ese verificador, el costo en tokens se triplica
- Cada vez gana más terreno la idea de tratar las herramientas tipo pipeline de un solo uso no como agentes para tareas específicas, sino como plataformas de propósito general con una capa adaptada a cada tarea
Fábricas de software y gasto extremo en tokens
- El punto de llegada natural es la fábrica de software, e incluso la fábrica oscura
- En esta estructura, el codebase genera código, lo revisa, corrige bugs y escribe tests sin supervisión humana
- El humano solo se encarga de ingresar la especificación y recibir la aplicación
- La fábrica de software de StrongDM se menciona como un caso que llevó esta dirección al extremo
- Desde StrongDM llegaron a sostener que los ingenieros deberían apuntar a gastar $1000 diarios en tokens, aunque se evalúa que eso tiene mucho de exageración y marketing
- Dicen que su propia fábrica de software gasta unos $600 al mes, y se considera excesivo destinar hoy a tokens, por cada ingeniero, un costo comparable al de un ingeniero senior de Google
- Aun así, el incentivo a gastar grandes sumas en tokens existe potencialmente y todavía está esperando expandirse
1 comentarios
Opiniones en Hacker News
Tokenmaxxing era simplemente una forma de obligar a los empleados a hacer la transición hacia un uso significativo de la IA.
Las empresas que medían el desempeño por el gasto en tokens ahora pueden bajar la intensidad. Los empleados aprendieron qué era posible y qué no probando la IA incluso en tareas donde antes no la habrían usado.
Nadie es tan tonto como para usar para siempre el gasto en tokens como criterio de desempeño y dar un presupuesto ilimitado. Creo que desde el principio fue una medida temporal para trasladar a los empleados a un nuevo entorno.
La gerencia sentía que los empleados no estaban adoptando la IA lo suficientemente rápido, y por eso en 2025 hubo muchos artículos mainstream sobre CEOs que presionaban diciendo que despedirían a quienes no usaran IA. Tokenmaxxing fue el extremo opuesto, y las empresas terminarán encontrando un punto de equilibrio.
No hace falta pensarlo demasiado.
Además, una respuesta citó este post en X como ejemplo de por qué la gerencia tuvo que tomar medidas así. Cambiar empresas de cientos, miles o decenas de miles de personas es difícil, y hay que enviar un mensaje simple a la vez. https://x.com/danluu/status/1487228574608211969?lang=en
En realidad, parece más bien una capa gerencial excesivamente remunerada, demasiado alejada del lugar donde se crea valor como para entender las desventajas de los LLM, siguiendo ciegamente una moda.
En la mayoría de las empresas, en el mejor de los casos era “lo hacemos porque los demás lo hacen”, y en el peor, algo más parecido a “veamos si el desarrollador Joe puede ser tan productivo como todo el equipo y despidamos al resto”.
De hecho, muchas empresas despidieron a empleados en masa con el argumento de que “su desempeño era insuficiente porque el gasto en tokens era bajo”.
Puede que aplique tal cual a este caso específico de estupidez directiva, pero, en términos más generales, es una escritura bellísima.
Ojalá pudiera tener una creencia tan desviada a favor de algún ser humano, ni hablar de un CEO.
Una persona que en ese momento era junior contaba que en su empresa habían introducido para las pruebas A/B un sistema tipo “Tokenmaxxing”. Cuantas más pruebas hacías, mejor te iba en la evaluación de desempeño; en ese momento le pareció tonto, pero al final logró que todos se familiarizaran con qué es un experimento y cómo ejecutarlo.
Pero es mucho más probable que un gerente de una gran empresa haya recibido presión de un VP para hacer IA, y que el VP la haya recibido de la plana ejecutiva. La plana ejecutiva seguramente recibía presión para presentar una estrategia de IA creíble y casi mágica que permitiera escalar la empresa infinitamente mientras reducía costos.
En ese entorno, parece más plausible copiar y pegar gráficos de Gartner, mezclar buzzwords escuchadas en conferencias y esperar que alguien, en algún lugar y en algún momento, convierta eso en algo que parezca avance.
Llevo al menos un año escuchando “ahora es distinto, los agentes acumulan éxitos, no errores”, pero todavía no lo veo.
Tuve la suerte de recibir una capacitación en IA de una semana de esas personas, a USD 50.000 por persona, y una de las pocas recomendaciones concretas que sirvieron fue vaciar el contexto con frecuencia para que el trabajo no se descarrilara.
Aunque quizá eso no importe para encontrar vulnerabilidades de seguridad. Tokenmaxxing definitivamente funciona para ese uso. La industria ahora está adoptando una forma muy cara y compleja de fuzzing continuo.
Zed, una herramienta que antes tenía esa función, y Text Threads, que recibió ese nombre después, ahora eliminaron esa funcionalidad.
Me intriga quién era para que alguien pudiera pensar que esa inversión valía la pena.
Lo de “imagina a un líder empresarial serio, por ejemplo alguien como Mark Zuckerberg, anunciando que Meta va a quemar dinero” se parece, por ejemplo, a declarar una transición al metaverso y hasta cambiar el nombre de la empresa para demostrar seriedad.
La parte que dice “usar más tokens generalmente produce mejores resultados. A esto lo llamamos ‘interés compuesto de la precisión’” es rara.
¿De verdad ya entramos en esa fase? ¿En general es cierto que cuanto más tokens usas, mejores resultados obtienes? Esta opinión me parece tan extraña que me hace pensar que el autor tiene algún interés económico en Tokenmaxxing.
Esto es infernal. Si el infierno fuera estar atrapado para siempre en una montaña rusa incómoda y pésimamente mantenida, se sentiría exactamente así.
Un título más acorde con el contenido habría sido “Los reportes sobre la muerte de Tokenmaxxing fueron muy exagerados”.
Personalmente odio el uso de ese modismo de título absurdo de “x ha muerto, larga vida a x”.
¿Qué significa aquí loop? ¿Repetir el mismo prompt hasta obtener el resultado deseado? ¿Los resultados repetidos no son demasiado parecidos entre sí?
https://github.com/topics/loop-engineering
Ese criterio a menudo no es más que una lista de pendientes actualizada. Uno de estos “harnesses” extremadamente simples llegó incluso a llamarse Ralph Wiggum Loop[1], en alusión al Tokenmaxxing descerebrado pero persistente que produce.
[1] https://awesomeclaude.ai/ralph-wiggum
Este tipo de cosas parece repetirse durante los primeros años de adopción de la mayoría de las grandes tecnologías.
Durante el boom del big data a principios de la década de 2010, los ejecutivos también empezaron comprando clústeres Spark y data lakes sin casos de uso analítico claros ni gobernanza.
“Casi nunca he oído a un líder empresarial decir que va a quemar dinero para sentirse bien”; ¿en serio?
Hace unos 4 años, nuestro CEO hizo venir en avión a consultores varias veces para ejercicios de team building. No podemos pagar la renovación de servidores cada 3 años, pero el costo de esos consultores se pagó sin problema.
Más recientemente, también trajeron consultores de branding y gastamos miles de dólares en AWS para rebrandear todas las fotos. Operamos en un mercado cautivo. Para vender en nuestro mercado, una suscripción a nuestro servicio es obligatoria, y fuera de ese mercado ni siquiera se puede contratar. Al final, el branding aumentó los ingresos en exactamente 0.
En una empresa donde trabajé antes, una de las primeras cosas que hizo el nuevo CTO al llegar fue imponer una convención para renombrar servidores. Usaba nombres de ciudades de todo el mundo poco familiares para empleados centrados en EE. UU.: los servidores de base de datos eran ciudades suizas, los web servers de Dinamarca, el almacenamiento de Finlandia, etc. Pasamos de nombres tipo ganado a nombres tipo mascotas, y ese CTO duró unos 6 meses.
En mi experiencia, el liderazgo corporativo no es tan austero como este artículo cree.
Es difícil imaginar trabajar en un entorno corporativo y no haber visto nunca ejemplos evidentes de este tipo de despilfarro. Los consultores demasiado bien pagados y los presupuestos que hay que gastar sí o sí son casos típicos.
La película Office Space salió hace 27 años y tiene una trama que se burla de los “consultores de eficiencia” sobrepagados cuya única función es decirle a la gerencia que despida gente.
Más precisamente, suele ser algo como “esto ayuda a mi carrera”.